On Mon, Apr 9, 2018 at 11:19 PM, Gert Wollny wrote:
> Am Montag, den 09.04.2018, 14:03 -0400 schrieb Marek Olšák:
> > On Mon, Apr 9, 2018 at 10:51 AM, Bas Vermeulen
> > wrote:
> Which solution is better depends on what is done more often: reading
> the index or writing to t
union and the
index in one struct, and use a function to
(re)calculate the index.
Which would you prefer?
Bas Vermeulen
On Tue, Mar 20, 2018 at 6:33 PM, Gert Wollny wrote:
> Am Dienstag, den 20.03.2018, 15:33 +0100 schrieb Nicolai Hähnle:
> > Nice, did you actually get it to work enti
sent through the rings.
Together, these patches allow me to execute OpenCL kernels correctly on the
T2080 mentioned above.
Bas Vermeulen
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
OpenCL program work correctly.
Signed-off-by: Bas Vermeulen
---
src/gallium/drivers/radeonsi/si_compute.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index
Using mesa OpenCL failed on a big endian PowerPC machine because
si_vgt_param_key is using bitfields and a 32 bit int for an
index into an array.
Fix si_vgt_param_key to work correctly on both little endian
and big endian machines.
Signed-off-by: Bas Vermeulen
---
src/gallium/drivers/radeonsi
are
mangled somehow.
My question is, does the radeonsi gallium driver process result buffers
somewhere in the code?
Pointers are more than welcome. I'm guessing the values are
processed/mangled some way,
and I would love to make this work correctly.
Bas Verm
Using mesa OpenCL failed on a big endian PowerPC machine because
si_vgt_param_key is using bitfields and a 32 bit int for an
index into an array.
Fix si_vgt_param_key to work correctly on both little endian
and big endian machines.
Signed-off-by: Bas Vermeulen
---
src/gallium/drivers/radeonsi
d of my own #if.
Bas Vermeulen
On Tue, Mar 20, 2018 at 3:33 PM, Nicolai Hähnle
wrote:
> Nice, did you actually get it to work entirely on a big endian machine?
>
> Bit fields aren't super portable, but this looks good enough. However, I
> think we should use the PIPE_ARCH_LITT
