On Sat, Jun 30, 2018 at 10:56 PM, Karol Herbst wrote:
> On Mon, Jun 11, 2018 at 5:10 PM, Marek Olšák wrote:
>> The series is OK with me, even though radeonsi can't support the new
>> opcodes.
>>
>
> How would you handle the case when a local variable might get a
> bindless or a non bindless
On Mon, Jun 11, 2018 at 5:10 PM, Marek Olšák wrote:
> The series is OK with me, even though radeonsi can't support the new
> opcodes.
>
How would you handle the case when a local variable might get a
bindless or a non bindless sampler value assigned? Meaning, how can a
compliant implementation
On Sat, Jun 30, 2018 at 4:05 PM, Karol Herbst wrote:
> On Sat, Jun 30, 2018 at 9:30 PM, Ilia Mirkin wrote:
>> Tes too, right? Also does the logic that forces recompiles work ok? I seem
>> to recall it was tied to vs.
>>
>
> well, I didn't want to touch stuff where we don't have a piglit test
>
On Sat, Jun 30, 2018 at 9:30 PM, Ilia Mirkin wrote:
> Tes too, right? Also does the logic that forces recompiles work ok? I seem
> to recall it was tied to vs.
>
well, I didn't want to touch stuff where we don't have a piglit test
yet, so everything else is untested. And as we don't start to
Tes too, right? Also does the logic that forces recompiles work ok? I seem
to recall it was tied to vs.
On Sat, Jun 30, 2018, 10:18 Karol Herbst wrote:
> this will be needed for compatibility profiles
>
> Signed-off-by: Karol Herbst
> ---
>
Fix build error after llvm-7.0svn r336028 ("[instsimplify] Move the
instsimplify pass to use more obvious file names and diretory.").
rasterizer/jitter/blend_jit.cpp:873:20: error: use of undeclared identifier
'createInstructionSimplifierPass'
this will be needed for compatibility profiles
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
it turned out that the failures with GATHER*O were the result of a faulty
optimization done by sb. So for consistensy I'll also add the offset for
GATHER4_O and GATHER4_C_O in the SET_TEXTURE_OFFSET call which alleviates the
problems with sb.
Apart from that I've just fixed some comments
From: Gert Wollny
The evaluation of the array layer index is "floor(z+0.5)", and the default
rounding mode doesn't correctly evaluate this. Therefore, set the rounding
mode to "trunc" and and z-filter mode to "point".
For other textures make sure the the default rounding mode and z-filter are
From: Gert Wollny
For texture array lookup the slice index is evaluated according to
idx = floor(z + 0.5)
This patch implements the first part by adding 0.5 to the according
texture coordinate when appropriate.
Fixes multi-sample tests out of:
Reviewed-by: Timothy Arceri
On 30/06/18 00:29, Alejandro Piñeiro wrote:
From: Antia Puentes
This will perform the CS shared lowering. See 8761a04d0d93
---
src/mesa/main/glspirv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
index
Reviewed-by: Timothy Arceri
On 30/06/18 00:29, Alejandro Piñeiro wrote:
From: Neil Roberts
---
src/mesa/drivers/dri/i965/brw_link.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp
b/src/mesa/drivers/dri/i965/brw_link.cpp
index
Reviewed-by: Timothy Arceri
On 30/06/18 00:29, Alejandro Piñeiro wrote:
That is the same gen requirement for ARB_shader_atomic_counters.
---
src/mesa/drivers/dri/i965/brw_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
On 30/06/18 00:29, Alejandro Piñeiro wrote:
From: Antia Puentes
From the SPIR-V specification, OpAtomicIDecrement:
"The instruction's result is the Original Value."
However, we were implementing it, for uniform atomic counters, as a
pre-decrement operation.
Renamed the former nir
patches 10-14 are:
Reviewed-by: Timothy Arceri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Patches 4-7:
Reviewed-by: Timothy Arceri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 30/06/18 00:28, Alejandro Piñeiro wrote:
From: Antia Puentes
When constructing NIR if we have a SPIR-V uint variable and the
storage class is SpvStorageClassAtomicCounter, we store as NIR's
glsl_type an atomic_uint to reflect the fact that the variable is an
atomic counter.
However, we
NAK this shouldn't be needed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 30/06/18 00:28, Alejandro Piñeiro wrote:
For the cases of uniforms that doesn't have an explicit
location. Under ARB_gl_spirv those are exceptions, like uniform atomic
counters.
---
src/compiler/glsl/gl_nir_link_uniforms.c | 31 +--
1 file changed, 17
On 30/06/18 00:28, Alejandro Piñeiro wrote:
This includes:
* Move the defition of empty_uniform_block to linker_util.h
* Move find_empty_block (with a rename) to linker_util.h
* Refactor some code at linker.cpp to a new method at linker_util.h
On 30/06/18 16:05, Timothy Arceri wrote:
On 30/06/18 00:28, Alejandro Piñeiro wrote:
ARB_gl_spirv points that uniforms in general need explicit
location. But there are still some cases of uniforms without location,
like for example uniform atomic counters. Those doesn't have a
location from
On 30/06/18 00:28, Alejandro Piñeiro wrote:
ARB_gl_spirv points that uniforms in general need explicit
location. But there are still some cases of uniforms without location,
like for example uniform atomic counters. Those doesn't have a
location from the OpenGL point of view (they are identified
22 matches
Mail list logo
