On Mon, Mar 7, 2016 at 8:39 PM, Ben Widawsky
wrote:
> "Braswell" is a Cherryview based *thing*. It unfortunately requires extra
> information to determine its marketing name. Unlike all previous products, and
> hopefully all future ones, there is no unique 1:1 mapping of PCI device ID to
> brand s
On Tue, Mar 8, 2016 at 2:22 AM, Rob Herring wrote:
> On Sun, Mar 6, 2016 at 10:32 PM, Rob Clark wrote:
>> On Sun, Mar 6, 2016 at 9:29 PM, Chih-Wei Huang
>> wrote:
>>> 2016-03-05 3:53 GMT+08:00 Rob Clark :
On Fri, Mar 4, 2016 at 2:43 PM, Thomas Hellstrom
wrote:
> On 03/04/2016 07
On Sun, Mar 6, 2016 at 10:32 PM, Rob Clark wrote:
> On Sun, Mar 6, 2016 at 9:29 PM, Chih-Wei Huang
> wrote:
>> 2016-03-05 3:53 GMT+08:00 Rob Clark :
>>> On Fri, Mar 4, 2016 at 2:43 PM, Thomas Hellstrom
>>> wrote:
On 03/04/2016 07:07 PM, Rob Clark wrote:
> On Fri, Mar 4, 2016 at 12:59
On Monday, March 7, 2016 5:23:26 PM PST Ian Romanick wrote:
> On 03/04/2016 07:33 PM, Kenneth Graunke wrote:
> > We resolved the implicit version directive when processing control lines,
> > such as #ifdef, to ensure any built-in macros exist. However, we failed
> > to resolve it when handling ord
On 03/04/2016 12:52 PM, Thomas Hellstrom wrote:
> Multiplying the contrast- and brightness matrices it becomes obvious that
> brightness should be multiplied by contrast in the procamp matrix. Fix this.
>
> v2: Fixed a couple of typos, one of them affecting the results.
Actually, when looking at a
On Mon, Mar 7, 2016 at 5:39 PM, Ben Widawsky
wrote:
> With the previous patches, the code can find out the actual number of
> available
> compute threads. It is enabled only for Cherryview since that is the only
> platform I know for a fact has shipped devices which can benefit from this.
> It
On Mon, Mar 7, 2016 at 5:39 PM, Ben Widawsky
wrote:
> Certain products are not uniquely identifiable based on device id alone. The
> kernel exports an interface to help deal with this. This patch merely
> introduces
> the consumer of the interface and makes sure nothing breaks.
>
> It is also pos
On Mon, Mar 7, 2016 at 5:39 PM, Ben Widawsky
wrote:
> "Braswell" is a Cherryview based *thing*. It unfortunately requires extra
> information to determine its marketing name. Unlike all previous products, and
> hopefully all future ones, there is no unique 1:1 mapping of PCI device ID to
> brand s
On Mon, Mar 7, 2016 at 5:58 PM, Brian Paul wrote:
> ---
> src/mesa/main/shaderimage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
> index fa967a2..fd5934f 100644
> --- a/src/mesa/main/shaderimage.c
> +++ b/src/
On 03.03.2016 01:36, Marek Olšák wrote:
> Hi,
>
> This patch series contains necessary radeonsi changes in order to support
> OpenGL-OpenCL interop. This only covers buffer and texture sharing.
>
> The changes can be summarized to:
> - write an image descriptor to amdgpu buffer metadata for Open
On 03.03.2016 01:36, Marek Olšák wrote:
> From: Marek Olšák
>
> The disabling of CMASK is simple, but notifying all contexts about it is not:
> - The screen must have a list of all contexts.
> - Each context must have a monotonic counter that is incremented only when
> the screen wants to re-em
On 03.03.2016 01:36, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/radeon/r600_buffer_common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
> b/src/gallium/drivers/radeon/r600_buffer_common.c
> index 439a3cb..fb
---
src/mesa/main/shaderimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
index fa967a2..fd5934f 100644
--- a/src/mesa/main/shaderimage.c
+++ b/src/mesa/main/shaderimage.c
@@ -360,7 +360,7 @@ _image_format_class_to
With the previous patches, the code can find out the actual number of available
compute threads. It is enabled only for Cherryview since that is the only
platform I know for a fact has shipped devices which can benefit from this. It
seems like other platforms /might/ benefit from this because of f
We have better information now, and 28 was not a valid thing to support. 6 EUs
per sublice with 7 threads per EU is the minimum supported config.
Cc: Jordan Justen
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/brw_device_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The way we are organizing this code, the statically configured max_cs_threads
should always be the minimum value we actually support (ie. are aware of). As a
result, we can fall back to that if we get invalid numbers from the kernel (ie.
when the query succeeds, but the result is lower than expecte
Certain products are not uniquely identifiable based on device id alone. The
kernel exports an interface to help deal with this. This patch merely introduces
the consumer of the interface and makes sure nothing breaks.
It is also possible to use these values for programming GPGPU mode, and I plan
"Braswell" is a Cherryview based *thing*. It unfortunately requires extra
information to determine its marketing name. Unlike all previous products, and
hopefully all future ones, there is no unique 1:1 mapping of PCI device ID to
brand string.
I put up a fight about adding any complexity to our G
I don't really have any basis to comment on the rest of the series, but
this patch is
Reviewed-by: Ian Romanick
On 03/04/2016 08:04 PM, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
>
On 03/04/2016 07:33 PM, Kenneth Graunke wrote:
> We resolved the implicit version directive when processing control lines,
> such as #ifdef, to ensure any built-in macros exist. However, we failed
> to resolve it when handling ordinary text.
>
> For example,
>
> int x = __VERSION__;
>
>
Reviewed-by: Ian Romanick
On 03/07/2016 04:55 PM, Kenneth Graunke wrote:
> The ES 3.0+ specifications contain the exact same text as the OpenGL
> specification, which says that we should return GL_INVALID_OPERATION.
>
> ES 2.0 contains different text saying we should return GL_INVALID_ENUM.
>
>
The ES 3.0+ specifications contain the exact same text as the OpenGL
specification, which says that we should return GL_INVALID_OPERATION.
ES 2.0 contains different text saying we should return GL_INVALID_ENUM.
Previously, Mesa chose the error code based on API (GL vs. ES).
This patch makes ES 3.
https://bugs.freedesktop.org/show_bug.cgi?id=94437
Bug ID: 94437
Summary: [swrast] piglit glx-shader-sharing regression
Product: Mesa
Version: 11.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Keyw
Alejandro Piñeiro writes:
> If the src is invalid, so src size is zero, the src_sz passed to emit
> send should be zero too, instead of a default 1 if we are in a simd4x2
> case. This can happens if using emit_untyped_atomic for an atomic
> dec/inc.
>
> v2: use the proper src_sz when calling emit
On 03/04/2016 04:52 AM, Thomas Hellstrom wrote:
Makes the code significantly more readable.
Signed-off-by: Thomas Hellstrom
---
src/gallium/auxiliary/vl/vl_csc.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/src/gallium/auxiliary/v
https://bugs.freedesktop.org/show_bug.cgi?id=94383
Tim Rowley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Monday, March 7, 2016 2:59:34 PM PST Tim Rowley wrote:
> Remove use of a win32-style type leaked from the swr rasterizer.
> ---
> src/gallium/drivers/swr/swr_fence.cpp | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/swr/swr_fence.cpp b/src/galli
On Mon, Mar 7, 2016 at 1:40 PM, Nanley Chery wrote:
>
> From: Nanley Chery
>
> The limit for these textures is 2048 not 1024.
>
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/anv_device.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_d
From: Nanley Chery
The limit for these textures is 2048 not 1024.
Signed-off-by: Nanley Chery
---
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 8aa1e61..5367375 100644
--
Remove use of a win32-style type leaked from the swr rasterizer.
---
src/gallium/drivers/swr/swr_fence.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/swr/swr_fence.cpp
b/src/gallium/drivers/swr/swr_fence.cpp
index f97ea22..e80faee 100644
--- a/src/
On 7 March 2016 at 10:35, Daniel Stone wrote:
> Hi,
>
> On 7 March 2016 at 10:19, Thierry Reding wrote:
>> On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
>>> Am Freitag, den 04.03.2016, 18:34 + schrieb Emil Velikov:
>>> > While I'm more inclined to Daniel's suggestion, I wonder
...to directly read from the vpm, saving a handful of QPU cycles.
The order of reads is preserved.
Signed-off-by: Varad Gautam
---
src/gallium/drivers/vc4/vc4_opt_vpm.c | 74 ---
src/gallium/drivers/vc4/vc4_qir.c | 2 +-
src/gallium/drivers/vc4/vc4_qir.h
This file will contain optimization passes for both vpm reads
and writes.
Signed-off-by: Varad Gautam
---
src/gallium/drivers/vc4/Makefile.sources | 2 +-
src/gallium/drivers/vc4/vc4_opt_vpm.c| 98
src/gallium/drivers/vc4/vc4_opt_vpm_writes.c | 98 --
Reviewed-by: Ilia Mirkin
On Mon, Mar 7, 2016 at 12:57 PM, Samuel Pitoiset
wrote:
> This allows to perform atomic operations on shared memory.
>
> Signed-off-by: Samuel Pitoiset
> ---
> .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 45
> +-
> 1 file changed, 44 inser
Reviewed-by: Ilia Mirkin
On Mon, Mar 7, 2016 at 12:52 PM, Samuel Pitoiset
wrote:
> The SHARED TGSI keyword is only allowed with TGSI_FILE_MEMORY and not
> with TGSI_FILE_BUFFER. I have found this by using the nouveau_compiler
> from command line.
>
> Signed-off-by: Samuel Pitoiset
> Cc: "11.2"
On Fri, Mar 4, 2016 at 6:39 PM, Ilia Mirkin wrote:
> Not that I'm against this, but is there actual HW that supports the full 3d
> stuff? From what I gather, no proprietary drivers expose this ext.
>
Right. I realized it after I wrote these patches. I'm not planning to post
more patches for this e
On Sat, Mar 5, 2016 at 8:02 AM, Brian Paul wrote:
> On 03/04/2016 06:29 PM, Anuj Phogat wrote:
>>
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/drivers/dri/i915/intel_mipmap_tree.c| 8
>> src/mesa/drivers/dri/i915/intel_tex_layout.c | 4 ++--
>> src/mesa/drivers/dri/i965
This allows to perform atomic operations on shared memory.
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 45 +-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
The SHARED TGSI keyword is only allowed with TGSI_FILE_MEMORY and not
with TGSI_FILE_BUFFER. I have found this by using the nouveau_compiler
from command line.
Signed-off-by: Samuel Pitoiset
Cc: "11.2"
---
src/gallium/auxiliary/tgsi/tgsi_text.c | 4 +++-
1 file changed, 3 insertions(+), 1 delet
On 03/06/2016 11:37 PM, Ilia Mirkin wrote:
On Tue, Mar 1, 2016 at 12:44 PM, Samuel Pitoiset
wrote:
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 52 ++
1 file changed, 52 insertions(+)
diff --git a/src/gallium/drivers/nouveau/
Reviewed-by: Ilia Mirkin
On Mon, Mar 7, 2016 at 12:29 PM, Samuel Pitoiset
wrote:
> The limit of the thread count immediate value is 12 bits.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --g
The limit of the thread count immediate value is 12 bits.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
b/src/gallium/drivers/nouveau/code
On 03/05/2016 02:01 PM, Jose Fonseca wrote:
On 05/03/16 17:40, Brian Paul wrote:
Fixes VMware MSVC, MinGW builds:
build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o):
ir_to_mesa.cpp:(.rdata+0xf9c): undefined reference to
`program_resource_visitor::set_buffer_offset(unsigned int)'
This doesn'
> On Mar 4, 2016, at 3:26 PM, Emil Velikov wrote:
>
> On 4 March 2016 at 19:28, Tim Rowley wrote:
>>
>> diff --git a/src/gallium/drivers/swr/rasterizer/common/os.h
>> b/src/gallium/drivers/swr/rasterizer/common/os.h
>> index 736d298..522ae0d 100644
>> --- a/src/gallium/drivers/swr/rasterizer/
On Mon, Mar 7, 2016 at 9:51 AM, Leo Liu wrote:
> From: Tamil velan
>
> With this issue 'mpv --hwdec=vdpau --vo=vdpau ' fails
> for vdpau decode if the stream height is 4096. Vdpau decode of
> height upto 4096 is necessary usecase on amdgpu driver for VI
> and newer platforms.
>
> The fix is in dr
From: Tamil velan
With this issue 'mpv --hwdec=vdpau --vo=vdpau ' fails
for vdpau decode if the stream height is 4096. Vdpau decode of
height upto 4096 is necessary usecase on amdgpu driver for VI
and newer platforms.
The fix is in driver specific implementation of "Decoder
Query Capabilities" A
On Mon, 2016-03-07 at 16:03 +0200, Pohjolainen, Topi wrote:
> On Mon, Mar 07, 2016 at 10:48:49AM +0100, Samuel Iglesias Gons?lvez
> wrote:
> > Hello,
> >
> > There is only one patch from this series that has been reviewed
> > (patch
> > 1).
> >
> > Our plans is to start sending patches for adding
On Mon, Mar 07, 2016 at 10:48:49AM +0100, Samuel Iglesias Gons?lvez wrote:
> Hello,
>
> There is only one patch from this series that has been reviewed (patch
> 1).
>
> Our plans is to start sending patches for adding fp64 support to i965
> driver in the coming weeks but they depend on these patc
On Mar 6, 2016 2:26 PM, "Marek Olšák" wrote:
>
> Hi Oded,
>
> I prefer "if" over #ifdef. The idea is that everybody should be able
> to test if the compilation succeeds without a BE machine. #ifdef
> disallows that.
>
> R600_BIG_ENDIAN can be moved to r600_pipe_common.h.
>
> Marek
>
OK, no problem
Am Montag, den 07.03.2016, 11:19 +0100 schrieb Thierry Reding:
> On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
> > Am Freitag, den 04.03.2016, 18:34 + schrieb Emil Velikov:
> > > On 4 March 2016 at 17:38, Lucas Stach wrote:
> > > > Am Freitag, den 04.03.2016, 17:20 + schrieb
Hi,
On 7 March 2016 at 10:19, Thierry Reding wrote:
> On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
>> Am Freitag, den 04.03.2016, 18:34 + schrieb Emil Velikov:
>> > While I'm more inclined to Daniel's suggestion, I wonder why people
>> > moved away from Thierry's approach - cr
On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
> Am Freitag, den 04.03.2016, 18:34 + schrieb Emil Velikov:
> > On 4 March 2016 at 17:38, Lucas Stach wrote:
> > > Am Freitag, den 04.03.2016, 17:20 + schrieb Daniel Stone:
> > >> Hi,
> > >>
> > >> On 4 March 2016 at 16:08, Lucas
Hello,
There is only one patch from this series that has been reviewed (patch
1).
Our plans is to start sending patches for adding fp64 support to i965
driver in the coming weeks but they depend on these patches.
Can someone take a look at them? ;)
Sam
On Thu, 2015-12-17 at 14:44 +0100, Samue
Am Freitag, den 04.03.2016, 18:34 + schrieb Emil Velikov:
> On 4 March 2016 at 17:38, Lucas Stach wrote:
> > Am Freitag, den 04.03.2016, 17:20 + schrieb Daniel Stone:
> >> Hi,
> >>
> >> On 4 March 2016 at 16:08, Lucas Stach wrote:
> >> > Am Freitag, den 04.03.2016, 15:09 + schrieb Dan
On 02.03.2016 06:26, Marek Olšák wrote:
> From: Marek Olšák
>
> Cc: 11.1 11.2
> ---
> src/gallium/drivers/radeon/r600_buffer_common.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
> b/src/gallium/drivers/radeon/r
From: Iago Toral Quiroga
CC: Eric Anholt
---
src/gallium/drivers/vc4/vc4_program.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/vc4/vc4_program.c
b/src/gallium/drivers/vc4/vc4_program.c
index 5c91c02..6f27665 100644
--- a/src/gallium/drivers/vc4/v
From: Connor Abbott
---
src/compiler/nir/nir.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index d2fd23d..39aad02 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -557,6 +557,15 @@ nir_dest_for_reg(nir_register *
From: Connor Abbott
When we replace an expresion we have to compute bitsize information for the
replacement. We do this in two passes to validate that bitsize information
is consistent and correct: first we propagate bitsize from child nodes to
parent, then we do it the other way around, starting
From: Connor Abbott
v2: Squash multiple commits addressing the new parameter in different
files so we don't break the build (Iago)
v3: Fix tgsi (Samuel)
v4: Fix nir_clone.c (Samuel)
v5: Fix vc4 and freedreno (Iago)
CC: Eric Anholt
CC: Rob Clark
Signed-off-by: Iago Toral Quiroga
Signed
As nir_alu_type has now embedded the data size, the check for the
instruction's output type (to see if a boolean resolve is required)
should ignore the data size part.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/mesa/drivers/dri/i965/brw_nir_analyze_boolean_resolves.c | 2 +-
1 file changed
From: Connor Abbott
---
src/compiler/nir/nir.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 39aad02..c7e4dcc 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -566,6 +566,15 @@ nir_src_bit_size(nir_src src)
From: Connor Abbott
This should only see sized types, but we can't do that until we have fixed NIR
and the driver to make this happen. A later commit will address this.
---
src/mesa/drivers/dri/i965/brw_nir.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw
From: Jason Ekstrand
This really hacky commit adds a bit size to registers and SSA values. It
also adds rules in the validator to validate that they do the right things.
It's still an open question as to whether or not we want a bit_size in
nir_alu_instr or if we just want to let it inherit fro
From: Connor Abbott
---
src/compiler/nir/nir.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index d493186..d2fd23d 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -99,6 +99,7 @@ union nir_constant_data {
int i[16]
From: Connor Abbott
This should only see sized types, but we can't make that change
until we make sure that nir uses the sized versions in all the
relevant places. A later commit will address this.
---
src/mesa/drivers/dri/i965/brw_nir.c | 12
1 file changed, 12 insertions(+)
diff
From: Jason Ekstrand
v2: Fix size/type mask to properly handle 8-bit types.
Signed-off-by: Juan A. Suarez Romero
---
src/compiler/nir/nir.h | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index cccb3a4..659e9
From: Connor Abbott
v2: fix it for GLSL_TYPE_SUBROUTINE (Iago)
Signed-off-by: Iago Toral Quiroga
---
src/compiler/nir_types.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
index 18d64b7..0748783 100644
--- a/src/c
From: Connor Abbott
v2: Use the bit-size information from the opcode information if defined (Iago)
Signed-off-by: Iago Toral Quiroga
FIXME: This should be squashed into the previous commit so we don't break
the build. The break happens because the python script that generates the
constant fold
From: Connor Abbott
Some opcodes need explicit bitsizes, and sometimes we need to use the
double version when constant folding.
v2: fix output type for u2f (Iago)
v3: do not change vecN opcodes to be float. The next commit will add
infrastructure to enable 64-bit integer constant folding so
Hello,
Iago and I are working on adding FP64 support to i965 drivers [0] with
the help of Connor and Jason (Thanks!). That support requires changes
in NIR to include the bit-size information in the data types and also
modifications in the opcodes to use sized types as needed.
This means that all
https://bugs.freedesktop.org/show_bug.cgi?id=93667
Fabian Vogt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Fri, Mar 04, 2016 at 06:34:37PM +, Emil Velikov wrote:
> On 4 March 2016 at 17:38, Lucas Stach wrote:
> > Am Freitag, den 04.03.2016, 17:20 + schrieb Daniel Stone:
> >> Hi,
> >>
> >> On 4 March 2016 at 16:08, Lucas Stach wrote:
> >> > Am Freitag, den 04.03.2016, 15:09 + schrieb Dan
On Tue, Mar 1, 2016 at 2:11 PM, Oded Gabbay wrote:
> This patch enables the correct detection of PIPE_FORMAT_R10G10B10A2_UINT
> and PIPE_FORMAT_B10G10R10A2_UINT formats in r600g in big-endian mode.
>
> Because the swapping doesn't happen on component boundaries for these
> formats, the GPU H/W nee
73 matches
Mail list logo
