Reviewed-by: Bas Nieuwenhuizen
On Mon, Nov 28, 2016 at 8:04 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes:
> dEQP-VK.api.image_clearing.clear_color_image.3d*
>
> These were hitting an assert as the code wasn't taking the
> baseMipLevel into account when minify the image depth.
>
> S
From: Dave Airlie
This fixes:
dEQP-VK.api.image_clearing.clear_color_image.3d*
These were hitting an assert as the code wasn't taking the
baseMipLevel into account when minify the image depth.
Signed-off-by: Dave Airlie
Cc: "13.0"
---
src/amd/vulkan/radv_meta_clear.c | 2 +-
1 file changed,
On Thu, Nov 24, 2016 at 6:11 PM, Ilia Mirkin wrote:
> Instead of (incorrectly) biasing the snorm value to make it look like a
> unorm, just use signed integer math.
>
> This fixes arb_color_buffer_float-render GL_RGBA8_SNORM
>
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/drivers/swr/rasteriz
From: Dave Airlie
We don't set the push constants slot up unless
something will cause us to need it.
Signed-off-by: Dave Airlie
---
src/amd/common/ac_nir_to_llvm.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/
From: Dave Airlie
This only emits enough descriptor sgprs for the number
of sets in the layout, and only emits the descriptors
necessary for the current stage.
Signed-off-by: Dave Airlie
---
src/amd/common/ac_nir_to_llvm.c | 51 +
1 file changed, 26 inse
From: Dave Airlie
This just refactors out some common code to make future changes
easier to understand.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/src/amd/vulkan/radv_
From: Dave Airlie
I'll need this later rather than just the layout.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 7b9fed2..
From: Dave Airlie
This just moves this into a separate function.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cm
From: Dave Airlie
This isn't fully what we want yet, but is a good step on the way.
This allows the compiler to create the information structures
for the state setting side, however the state setting still expects
things to be pretty much in 2 sgpr wide register sets, and can't
handle the indire
From: Dave Airlie
This is another step towards having the compiler decide the
user sgpr layout.
This still emits the descriptors sets for all shader types, but
we will fix this later.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 24 ++--
src/amd/vulkan
From: Dave Airlie
This just splits some common code into a utility function.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vul
From: Dave Airlie
This just moves some common code into a utility function
to avoid having to change multiple places later.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/src/amd/vu
From: Dave Airlie
This copies the push constant code and only binds descriptor
sets to the stages that need them. It also now has to dirty
descriptors on pipeline binds.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 45 ++--
1 file change
On radeonsi hw we have 16 user defined sgprs we can use to feed
32-bit constant values to the shader, we've up until now statically
partitioned these, but this can be limiting going forward and also
leads to having unused sgprs.
Also radv has currently a limit of 4 descriptor sets, to raise that
a
On Sunday, November 27, 2016 12:17:52 PM PST Emil Velikov wrote:
> On 27 November 2016 at 02:31, Kenneth Graunke wrote:
> > On Thursday, November 24, 2016 8:30:39 PM PST Emil Velikov wrote:
> >> From: Emil Velikov
[snip]
> >> @@ -186,7 +208,14 @@ anv_physical_device_init(struct anv_physical_devic
This matches what NVIDIA and AMD hardware expose, as well as what Intel
hardware supports.
Signed-off-by: Ilia Mirkin
---
src/intel/vulkan/anv_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index cae2
This matches the capabilities of the hardware.
Signed-off-by: Ilia Mirkin
---
This passes the Intel Jenkins CI.
src/mesa/drivers/dri/i965/brw_context.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i
Offsets that don't fit into 4 bits need to force gather_po to be
selected. Adjust the logic so that this happens.
Signed-off-by: Ilia Mirkin
---
I've manually verified that offsets in range end up in gather4, while offsets
that are larger get stuck into gather4_po. Unfortunately I had to modify
https://bugs.freedesktop.org/show_bug.cgi?id=98831
--- Comment #11 from Michel Dänzer ---
It comes down to: Somebody who can reproduce the problem needs to track it
down, e.g. with valgrind. If valgrind memcheck can't catch the leak (not even
when killing the process with an appropriate signal?),
Yeah, so looks like the *implementation* tests do something like:
vec2 32 ssa_4 = intrinsic load_ubo (ssa_3, ssa_1) () ()
vec4 32 ssa_5 = tg4 ssa_2 (coord), ssa_4 (offset), 3
(gather_component), 0 (texture) 0 (sampler)
Which means that we don't hit the immediate path. I'll hack so
Ah OK. But presumably the gather4_po variant is chosen when the
constant offsets are outside the -8..7 range, since I didn't get any
failures, and the test suite has checks around impl-defined
min/maxes... Could be that all those were the non-const variants.
Looking through the brw_fs code, I indee
Remove duplicate .alphaToOne, add missing .shaderResourceMinLod, and
reorder a few entries to match their vulkan.h order. All the sparse
features are still left out entirely.
Signed-off-by: Ilia Mirkin
---
Wasn't 100% sure whether it was worth adding shaderResourceMinLod or not.
I don't think it
The HW limits here are -8/7 when using the gather4 message. [gather4_po
allows -32/31, and specified per channel]
On Mon, Nov 28, 2016 at 10:49 AM, Ilia Mirkin wrote:
> This matches what NVIDIA and AMD hardware expose.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> Not sure what the true HW limit is
This matches what NVIDIA and AMD hardware expose.
Signed-off-by: Ilia Mirkin
---
Not sure what the true HW limit is here. On NVIDIA, the true HW limit really
is -32/31 though. As an aside, according to vulkan.gpuinfo.org, the Intel
Windows driver also exposes -32/31.
With the updated limits on
These are all regularly available in desktop GL, so the backend fully
supports them.
Signed-off-by: Ilia Mirkin
---
There don't appear to be directed VK tests for these. However spirv_to_nir's
translate_image_format has all the formats. And VK doesn't add any new formats
over what's required for
The strategy is to do the same thing that the GLSL lower_offset_arrays
pass does - create 4 separate texture gather ops, one per offset, and
read in the results from each gather's w component to recreate the
desired result.
Signed-off-by: Ilia Mirkin
---
src/compiler/spirv/spirv_to_nir.c | 76 ++
Now that the SPIR-V -> NIR translation is in place, no additional logic
is required.
Signed-off-by: Ilia Mirkin
---
On a SKL, I get:
./deqp-vk --deqp-visibility=hidden --deqp-case='*texture_gather*'
Test run totals:
Passed:762/1524 (50.0%)
Failed:0/1524 (0.0%)
Not supporte
This appears to be fully supported already.
Signed-off-by: Ilia Mirkin
---
On a SKL:
./deqp-vk --deqp-visibility=hidden --deqp-case='*cube_array*'
Test run totals:
Passed:3255/4196 (77.6%)
Failed:0/4196 (0.0%)
Not supported: 941/4196 (22.4%)
Warnings: 0/4196 (0.0%)
The strategy is to just keep n anv_query_pool_slot entries per query
instead of one. The available bit is only valid in the last one.
Signed-off-by: Ilia Mirkin
---
I think this is in a pretty good state now. I've tested both the direct and
buffer paths with a hacked up cube application, and I'm
On 16-11-24 09:23:31, Jason Ekstrand wrote:
[snip]
Right, you are correct. This is actually a patch from really early days
when I
didn't know any better. We might want to drop this for now, there is the
0/1
color thing for sampler engine that we probably need to fix first
anyway.
Let's dr
---
src/gallium/state_trackers/clover/api/kernel.cpp | 92 +-
src/gallium/state_trackers/clover/core/module.cpp | 14
src/gallium/state_trackers/clover/core/module.hpp | 11 +++
.../state_trackers/clover/llvm/codegen/common.cpp | 11 +++
4 files changed, 125 insertion
---
src/gallium/state_trackers/clover/llvm/codegen/common.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
index 13ccd59..aa6ca50 100644
--- a/src/gallium/state_tracke
On Sun, Nov 27, 2016 at 2:44 AM, Kenneth Graunke wrote:
> On Tuesday, November 22, 2016 11:20:11 PM PST Ilia Mirkin wrote:
>> This was already piped through in the CmdDraw(Indexed)Indirect handling.
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> Passes the 2 vk-cts tests dedicated to it as well.
>
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #2 from Karol Herbst ---
mind doing a git bisect and checking which commit broke it?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=98869
Bug ID: 98869
Summary: Electronic Super Joy graphic artefacts (regression)
Product: Mesa
Version: 13.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #1 from cosiek...@o2.pl ---
Created attachment 128216
--> https://bugs.freedesktop.org/attachment.cgi?id=128216&action=edit
screen2
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact fo
On 27 November 2016 at 02:31, Kenneth Graunke wrote:
> On Thursday, November 24, 2016 8:30:39 PM PST Emil Velikov wrote:
>> From: Emil Velikov
>>
>> Inspired by a similar commit for radv.
>>
>> Rather than recomputing the timestamp on each make invocation, just
>> fetch it at runtime.
>>
>> Thus
On Tuesday, November 22, 2016 11:59:48 AM PST Matt Turner wrote:
> A function is necessary to handle immediate types.
> ---
> src/mesa/drivers/dri/i965/brw_disasm.c | 35
> src/mesa/drivers/dri/i965/brw_eu_emit.c | 58
> +++--
> src/mesa/drivers/d
On Sunday, November 27, 2016 12:42:49 AM PST Kenneth Graunke wrote:
> On Tuesday, November 22, 2016 11:59:43 AM PST Matt Turner wrote:
> > desc will always be non-NULL, because brw_validate_instructions() does
> > not attempt to validate any instructions that fail the
> > is_unsupported_inst() chec
On Tuesday, November 22, 2016 11:59:43 AM PST Matt Turner wrote:
> desc will always be non-NULL, because brw_validate_instructions() does
> not attempt to validate any instructions that fail the
> is_unsupported_inst() check.
> ---
> src/mesa/drivers/dri/i965/brw_eu_validate.c | 4 +---
> 1 file c
40 matches
Mail list logo
