On 19.12.2017 02:14, Ian Romanick wrote:
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/mesa/drivers/common/meta.c | 43 ++---
src/mesa/drivers/common/meta.h | 2 +-
src/mesa/drivers/common/meta_blit.c | 8 ---
3 files changed, 36
series is
Reviewed-by: Tapani Pälli
On 19.12.2017 02:14, Ian Romanick wrote:
From: Ian Romanick
tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions. The GL spec
Fixes running piglits without -fbo. Probably lots of other stuff too.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/freedreno/freedreno_resource.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c
b/src/gallium/drivers/freedreno/freedren
Implements VK_KHR_display, VK_EXT_direct_mode_display and
VK_EXT_acquire_xlib_display using DRM/KMS.
This uses X leases to provide the same API as nVidia, allowing an
application to discover available display resources and acquire one
from the X server using RandR leases.
Because Linux DRM does n
Here's an implementation of a suite of extensions necessary to
directly drive displays from the mesa Vulkan implementation:
VK_KHR_display
Provides basic enumeration, control and display to directly
connected devices.
VK_EXT_direct_mode_display
VK_EXT_acquire_xlib_display
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
v2: Remove DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT flag. This has
been removed from the proposed kernel API.
Add NULL
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
v2: Thanks to kisak
Fix spelling of VkSurfaceCapabilities2EXT in wsi_common_wayland.c,
it was using ext instead of EXT.
Fix spelling of VK_STRUCTURE_TYPE_SUR
On 22 December 2017 at 12:14, Dave Airlie wrote:
> From: Dave Airlie
>
> If we are using tc compatible depth image as textures, it seems
> that we would need to make sure the depth/stencil clear registers
> are reloaded with the correct values before accessing the image.
Ignore me, I'm slowing w
From: Dave Airlie
If we are using tc compatible depth image as textures, it seems
that we would need to make sure the depth/stencil clear registers
are reloaded with the correct values before accessing the image.
This was a failed attempt to fix
dEQP-VK.renderpass.suballocation.formats.d32_sfloa
So the plan is for alloc_handle_t to not be sub-classed by the
implementations, but have all necessary information that an implementation
would need?
If so, how do we reconcile the implementation specific information that is
often in the handle:
https://github.com/intel/minigbm/blob/master/cros_
Patch #2 is a little large so it is stuck in the moderation queue. The
patch doesn't introduce any functionality changes, just renames fences
to semaphores.
[snip]
[PATCH 02/22] gallium: rename pipe fences to semaphores
Is being held until the list moderator can review it for approval.
The
Make sure memory is accessible to the external client, for the specified
memory object, before the signal/after the wait.
v2: fixed flush order with respect to wait/signal emission
Signed-off-by: Andres Rodriguez
---
src/mesa/main/dd.h | 14 ++-
src/mesa/main/ex
Bits to implement ServerWaitSemaphoreObject/ServerSignalSemaphoreObject
v2:
- corresponding changes for gallium fence->semaphore rename
- flushing moved to mesa/main
Signed-off-by: Andres Rodriguez
---
src/mesa/state_tracker/st_cb_semaphoreobjects.c | 27 +
1 file ch
Guarded by PIPE_CAP_SEMAPHORE_SIGNAL
v2: corresponding changes for PIPE_CAP_SEMAPHORE_SIGNAL rename
Signed-off-by: Andres Rodriguez
---
src/mesa/main/extensions_table.h | 2 ++
src/mesa/main/mtypes.h | 2 ++
src/mesa/state_tracker/st_extensions.c | 2 ++
3 files changed, 6
This fixes the piglit test:
spec/ext_semaphore/api-errors/usigned-byte-i-v-bad-value
Signed-off-by: Andres Rodriguez
---
src/mesa/main/get.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 34970b8..302cece 100644
--- a/src/mesa/main/get.c
+
Hook up importing semaphores of type PIPE_FD_TYPE_SYNCOBJ
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/radeonsi/si_fence.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_fence.c
b/src/gallium/drivers/rad
This allows the client to actually query the enums specified in the
ext_external_objects spec.
Signed-off-by: Andres Rodriguez
---
src/mesa/main/get.c | 3 +++
src/mesa/main/get_hash_params.py | 5 +
2 files changed, 8 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/m
This fixes the following piglit tests:
spec/ext_semaphore_fd/api-errors/import-semaphore-fd-bad-enum
spec/ext_memory_object_fd/api-errors/import-memory-fd-bad-enum
Signed-off-by: Andres Rodriguez
---
src/mesa/main/externalobjects.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Denotes that a fd is backed by a synobj. For example, radv shared
semaphores.
Signed-off-by: Andres Rodriguez
---
src/gallium/include/pipe/p_defines.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index e2e07ac..9
Expose the feature only when we have syncobj support available
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/radeonsi/si_get.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_get.c
b/src/gallium/drivers/radeonsi/si_get.c
index ed8
Memory synchronization is left for a future patch.
v2: flush vertices/bitmaps moved to mesa/main
Signed-off-by: Andres Rodriguez
---
src/mesa/main/dd.h | 14 ++
src/mesa/main/externalobjects.c | 38 ++
2 files changed, 52 insertions(+
When calling si_semaphore_server_sync(), the wait operation is associated
with the next kernel submission. Therefore, any unflushed work
submitted previous to semaphore_server_sync() will also be affected by
the wait.
To avoid adding the dependency to the unflushed work, we flush before
emitting t
Syncobj based waits or signals only happen at submission boundaries. In
order to guarantee that the requested signal event will occur when the
state tracker requested it, we must issue a flush.
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/radeonsi/si_fence.c | 37 +
Add the ability to signal a syncobj when a cs completes execution.
v2: corresponding changes for gallium fence->semaphore rename
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/radeon/radeon_winsys.h | 12 +
src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 83 +++
EXT_semaphore and EXT_semaphore_fd define no pnames. Therefore there
isn't much to do besides determining the correct error code.
v2: removed useless return
Signed-off-by: Andres Rodriguez
---
src/mesa/main/externalobjects.c | 22 ++
1 file changed, 22 insertions(+)
diff --
Add basic semaphore object operations.
Signed-off-by: Andres Rodriguez
---
src/mesa/Makefile.sources | 2 +
src/mesa/meson.build| 2 +
src/mesa/state_tracker/st_cb_semaphoreobjects.c | 55 +
src/mesa/state_tracker/st_cb_
An fd can potentially have different types of objects backing it.
Specifying the type helps us make sure we treat the FD correctly.
This is in preparation to allow importing syncobj fence FDs in addition
to native sync FDs.
Signed-off-by: Andres Rodriguez
---
src/gallium/auxiliary/util/u_tests.
Signed-off-by: Andres Rodriguez
---
src/gallium/auxiliary/util/u_threaded_context.c | 20
.../auxiliary/util/u_threaded_context_calls.h| 1 +
2 files changed, 21 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_threaded_context.c
b/src/gallium/auxiliary
Used by EXT_semmaphore and EXT_semaphore_fd
v2: Removed unnecessary dummy callback initialization
Signed-off-by: Andres Rodriguez
---
src/mesa/main/dd.h | 34 ++
src/mesa/main/externalobjects.c | 133 +++-
src/mesa/main/externalobjects.h
Calling this function will emit a semaphore signal operation into the
GPU's command stream.
Signed-off-by: Andres Rodriguez
---
src/gallium/docs/source/context.rst | 31 +++
src/gallium/include/pipe/p_context.h | 6 ++
2 files changed, 37 insertions(+)
diff --g
Kept separate from the symbol renames for review purposes.
Signed-off-by: Andres Rodriguez
---
src/gallium/docs/source/context.rst| 34 +++---
src/gallium/include/pipe/p_context.h | 33 +++--
src/gallium/include/pipe/p_screen.h
Protects semaphore signaling functionality required by GL_EXT_semaphore.
Signed-off-by: Andres Rodriguez
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
src/gallium/driver
Sorry for the long time to get this v2 out, past month has been
a bit hectic.
This incorporates the feedback I received from mareko and nha on
the previous iteration.
Some of the notable changes:
- Merged fences and semaphores at the gallium level
- Fixed latency due to delayed flushing
- M
On Thu, Dec 21, 2017 at 3:36 AM, Daniel Vetter wrote:
> On Thu, Dec 21, 2017 at 9:06 AM, James Jones wrote:
>> However, making some assumptions, I suspect it's probably going to come down
>> to yes we can fit what we need in some number of bits marginally less than
>> 56 now, with the current use
Just a stylistic nit.
On Thu, Dec 21, 2017 at 8:25 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> If we are doing a general->general transfer with HIZ enabled,
> we want to hit the tile surface disable bits in radv_emit_fb_ds_state,
> however we never get the current layout to know we are in gen
On Thu, Dec 21, 2017 at 2:50 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> looking at traces I noticed we'd set slice_max too large sometimes.
Too small? Otherwise patch 1,3,4 are also
Reviewed-by: Bas Nieuwenhuizen
>
> This should fix it.
>
> Signed-off-by: Dave Airlie
> ---
> src/amd/vul
Reviewed-by: Bas Nieuwenhuizen
On Thu, Dec 21, 2017 at 2:50 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> On GFX9 we must access 3D textures with 3D samplers AFAICS.
>
> This fixes:
> dEQP-VK.api.image_clearing.core.clear_color_image.3d.single_layer
>
> on GFX9 for me.
>
> v1.1: fix tex->sampl
Reviewed-by: Bas Nieuwenhuizen
for the series.
On Thu, Dec 21, 2017 at 5:53 PM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_nir_to_llvm.c | 64 +++-
> src/amd/common/ac_shader_util.c | 72
> ++
Assuming you tested with vega,
Reviewed-by: Bas Nieuwenhuizen
On Thu, Dec 21, 2017 at 5:45 PM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_image.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_image.c b/src
This patch doesn't apply to master as formatted.
I've reverted the bisected commit, since it disables testing on master.
Eero Tamminen writes:
> Fixes: 9702fac68e (spirv: consider bitsize when handling OpSwitch cases)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104359
> ---
> src
Series is
Reviewed-by: Ian Romanick
On 12/18/2017 03:26 PM, Francisco Jerez wrote:
> The weight_vector_type constructor was inadvertently assuming C++17
> semantics of the new operator applied on a type with alignment
> requirement greater than the largest fundamental alignment.
> Unfortunately
On 21 December 2017 at 19:52, Alex Smith wrote:
> Nice - this does fix the issue I was seeing, thanks.
>
> Can at least patches 2 and 3 go to stable?
Yes once I get some review I'll tag those two for stable.
Dave.
___
mesa-dev mailing list
mesa-dev@lis
Rb
On December 21, 2017 08:05:24 Lionel Landwerlin
wrote:
Reviewed-by: Lionel Landwerlin
On 21/12/17 13:53, Eero Tamminen wrote:
Fixes: 9702fac68e (spirv: consider bitsize when handling OpSwitch cases)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104359
---
src/compiler/spirv/
https://bugs.freedesktop.org/show_bug.cgi?id=104351
--- Comment #2 from Breno Souza ---
Same error on fresh install. I have installed the following packages:
base, base-devel, gnome, gnome-extra, freeglut, qt5-base, cower, pacaur,
google-chrome (from aur), mesa-demos
I also have lost access to
Eero Tamminen writes:
> Hi,
>
> I tested this on HSW GT2, BXT & SKL GT3e, and didn't see any significant
> regressions this time. I'll try it also on a machine with smaller
> variance than those (now that it became free), and send a note if that
> does show something.
>
You're not expected t
On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
wrote:
> Hi Robert,
>
> Thanks for looking into this! We need to decide if we want:
>
> (1) A common struct that implementations can subclass, i.e:
>
> struct blah_gralloc_handle {
> alloc_handle_t alloc_handle;
> int x, y, z;
>
>
Mesa 17.3.1 is now available.
In this release we have:
Multiple fixes and improvements of the GLSL shader cache. The RADV driver
no longer advertises VK_EXT_debug_report - there is no support for it.
The i965, radeonsi, nvc0 and freedreno drivers have received a few small
fixes each.
Last but n
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 3 ++-
src/amd/common/ac_llvm_build.h | 3 ++-
src/amd/common/ac_nir_to_llvm.c | 6 --
src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 3 ++-
4 files changed
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 64 +++-
src/amd/common/ac_shader_util.c | 72
src/amd/common/ac_shader_util.h | 6 +++
src/gallium/drivers/radeonsi/si_shader.c | 61 +
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index efd17e4889..15410f140e 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -
On Thu, Dec 21, 2017 at 5:32 PM, Ilia Mirkin wrote:
> Tgsi values should stay inside of from_tgsi. If there are leaks into the
> rest of codegen, let's plug them. I assume this is for assignslots?
>
the translateSysVal thing not directly, but I can translate the glsl
values to the tgsi ones with
Tgsi values should stay inside of from_tgsi. If there are leaks into the
rest of codegen, let's plug them. I assume this is for assignslots?
On Dec 21, 2017 11:26 AM, "Karol Herbst" wrote:
> On Thu, Dec 21, 2017 at 5:21 PM, Ilia Mirkin wrote:
> > On Thu, Dec 21, 2017 at 10:51 AM, Karol Herbst
On Thu, Dec 21, 2017 at 5:21 PM, Ilia Mirkin wrote:
> On Thu, Dec 21, 2017 at 10:51 AM, Karol Herbst wrote:
>> this is more or less a todo list of things I should move elsewhere. Not all
>> of
>> it should be actually moved, but...
>>
>> Signed-off-by: Karol Herbst
>> ---
>> src/gallium/driver
On Thu, Dec 21, 2017 at 10:51 AM, Karol Herbst wrote:
> this is more or less a todo list of things I should move elsewhere. Not all of
> it should be actually moved, but...
>
> Signed-off-by: Karol Herbst
> ---
> src/gallium/drivers/nouveau/Makefile.sources | 2 +
> .../nouveau/codegen/n
On Thu, Dec 21, 2017 at 10:51 AM, Karol Herbst wrote:
> Plans are to get SPIR-V support for Nouveau with a cheap way. Before that I
I'm not on board with this plan, as I'm sure you know. Cheap way is to
just support SPIR-V directly.
That said, as long as impact to surrounding code is minimal, ha
uhm, actually that should have been marked as a RFC, sorry for that.
On Thu, Dec 21, 2017 at 4:51 PM, Karol Herbst wrote:
> Plans are to get SPIR-V support for Nouveau with a cheap way. Before that I
> was looking into Pierres work on his direct SPIR-V to nvir pass and seemed
> much more complica
TODO: there is more
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 16
1 file changed, 16 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
i
we store those arrays in local memory and reserve some space for each of the
arrays. Tthe arrays are stored in a packed format, because we know quite easily
the context of each index. We don't do that in TGSI so far.
This causes various issues to come up in the MemoryOpt pass, because ld/st with
i
TODO: a lot of those fields are not valid for a lot of tex ops. Not quite sure
if it's worth the effort to check for those or just keep it like that. It seems
to kind of work.
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 192 +
1 file c
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index cf324a3e8f..4126
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 98cd73451e..bf21
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 896a02af96..009
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 412675fcb1..98c
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 427 +
1 file changed, 427 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 009f3df875..d1
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp| 17 +
1 file changed, 17 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index f13699a393..fe1
TODO: this is far from being complete, but at least this let the basics things
work already.
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_
TODO: move lowering code somewhere else. We do the same thing as from_tgsi for
a few ops and we could move that down a bit so the input IR doesn't have to
deal with a few things, like slct and min/max with 64bit dest types.
TODO: move DEFAULT_HANDLER into its own function
TODO: check if some code
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 5f0746055a..f13
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 43 ++
1 file changed, 43 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 9ccd84bc20..896
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp| 21 +
1 file changed, 21 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index d2b2236c17..9cc
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 116 +
1 file changed, 116 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 6516bd2d8f..c7
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 108 +
1 file changed, 108 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 4833da5914..65
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 255 -
1 file changed, 253 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
inde
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 37 ++
1 file changed, 37 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index bfaeb1ffd5..483
can't be turned on for release builds for now.
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.
not all those nir options are actually required, it just made the work a
little easier.
TODO:
there is a little memory leak, because the nir shader is duplicated twice.
this has to be done though, we just need to clean it up properly
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/M
this is more or less a todo list of things I should move elsewhere. Not all of
it should be actually moved, but...
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/Makefile.sources | 2 +
.../nouveau/codegen/nv50_ir_from_common.cpp| 145
.../driver
Plans are to get SPIR-V support for Nouveau with a cheap way. Before that I
was looking into Pierres work on his direct SPIR-V to nvir pass and seemed
much more complicated than doing NIR to nvir.
In the end we still plan to get Compute support through SPIR-V and my hope is
to get that piped throu
this makes debugging a little easier
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index 46a15d76df..0b305af316
Here's a quick proof of concept implementation of HDR support
for Wayland/Weston/Mesa.
I'm not posting this as patches right now because I'm not sure
that would do much good given how rough this is. But here are
all the repos/branches:
git://github.com/vsyrjala/wayland.git hdr_poc
git://github.com
Hi,
I tested this on HSW GT2, BXT & SKL GT3e, and didn't see any significant
regressions this time. I'll try it also on a machine with smaller
variance than those (now that it became free), and send a note if that
does show something.
- Eero
On 20.12.2017 21:27, Francisco Jerez wro
Reviewed-by: Lionel Landwerlin
On 21/12/17 13:53, Eero Tamminen wrote:
Fixes: 9702fac68e (spirv: consider bitsize when handling OpSwitch cases)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104359
---
src/compiler/spirv/vtn_cfg.c | 14 +++---
1 file changed, 7 insertions(+), 7
Fixes: 9702fac68e (spirv: consider bitsize when handling OpSwitch cases)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104359
---
src/compiler/spirv/vtn_cfg.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/sp
On Thu, Dec 21, 2017 at 02:01:22PM +0200, Topi Pohjolainen wrote:
> Here is a revision taking into account feedback from Andres and Fredrik.
> Many thanks for both, I hope I didn't miss anything.
My apologies, sent to the wrong list. Only realized too late after hitting
enter...
__
Signed-off-by: Topi Pohjolainen
---
CMakeLists.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 4259ec832..c90109907 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -173,6 +173,8 @@ ELSEIF(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
endif()
Here is a revision taking into account feedback from Andres and Fredrik.
Many thanks for both, I hope I didn't miss anything.
CC: Andres Rodriguez
CC: Fredrik Hoeglund
CC: Jason Ekstrand
Topi Pohjolainen (11):
framework: Check for vulkan availability
framework: HACK: Read glslc path from e
This stripped down version of glsl_scraper.py found in crucible.
Signed-off-by: Topi Pohjolainen
---
.../compile_and_dump_glsl_as_spirv.py | 139 +
1 file changed, 139 insertions(+)
create mode 100644
tests/spec/ext_memory_object/compile_and_dump_glsl_as_spirv.
Signed-off-by: Topi Pohjolainen
---
CMakeLists.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c90109907..767b90add 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -174,6 +174,7 @@ ELSEIF(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
ENDIF()
pkg_che
On 21/12/17 08:21, 吴畏 wrote:
> Hello,every
> I want to know why vertex shader and fragment shader are compiled to
> many shader binarys.
So many binaries? Do you mean the intermediate representations? AST, IR,
NIR, TGSI ...?
> When and where these bianrys are linked
flex/bison creates a AST repr
Nice - this does fix the issue I was seeing, thanks.
Can at least patches 2 and 3 go to stable?
On 21 December 2017 at 01:50, Dave Airlie wrote:
> This series fixes about 340 CTS tests on Vega that involve 3D images.
>
> The two main things are to use 3D samplers for copy paths sources that
> a
I think this needs to be backported to mesa-stable.
Thanks for fixing this, it makes sense.
Reviewed-by: Samuel Pitoiset
On 12/21/2017 05:05 AM, Dave Airlie wrote:
From: Dave Airlie
This fixes vmfaults seen on vega with:
dEQP-VK.pipeline.multisample_interpolation.sample_interpolate_at_singl
Nice catch!
Reviewed-by: Bas Nieuwenhuizen
On Thu, Dec 21, 2017 at 5:05 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes vmfaults seen on vega with:
> dEQP-VK.pipeline.multisample_interpolation.sample_interpolate_at_single_sample_.128_128_1.samples_1
>
> These were caused by the don't
Hello,every
I want to know why vertex shader and fragment shader are compiled to many
shader binarys. When and where these bianrys are linked and uploaded?
thanks___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailm
On Wed, Dec 20, 2017 at 3:44 PM, Ilia Mirkin wrote:
> On Tue, Dec 19, 2017 at 11:41 PM, Ilia Mirkin wrote:
>> This is parallel to the pre-SM50 change which does this. Adjusts the
>> shuffles / quadops to make the values correct relative to lane 0, and
>> then splat the results to all lanes for th
On Thu, Dec 21, 2017 at 9:06 AM, James Jones wrote:
> However, making some assumptions, I suspect it's probably going to come down
> to yes we can fit what we need in some number of bits marginally less than
> 56 now, with the current use cases and hardware, but we're very concerned
> about extens
On 12/20/2017 01:58 PM, Daniel Stone wrote:
Hi Miguel,
On 20 December 2017 at 16:51, Miguel Angel Vico wrote:
In the meantime, I've been working on putting together an open source
implementation of the allocator mechanisms using the Nouveau driver for
all to be able to play with.
Thanks for
On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen
wrote:
> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico
> wrote:
>>
>> Inline.
>>
>> On Wed, 20 Dec 2017 11:54:10 -0800
>> Kristian Høgsberg wrote:
>>
>> > On Wed, Dec 20, 2017 at 11:51 AM, Daniel Vetter wrote:
>> > > Since this also in
97 matches
Mail list logo
