Michel Dänzer mic...@daenzer.net writes:
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git
From: Michel Dänzer michel.daen...@amd.com
Putting those in VRAM seems to cause (worse) stutter in Unigine Valley on
some systems.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82050
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/r600_buffer_common.c
On 08/28/2014 01:50 AM, Micael wrote:
I am getting another error regarding explicit locations, which I
believe has a one-line fix. If I only have a single uniform in my
shader, and that uniform is explicitely given location 1 (or anything
above zero), my program will crash if I attempt to give
From: Michel Dänzer michel.daen...@amd.com
This allows the kernel to prevent such BOs from ever being stored in the
CPU inaccessible part of VRAM.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/r600_buffer_common.c | 23 ++-
From: Michel Dänzer michel.daen...@amd.com
This flag is a hint that userspace expects the BO to be accessed by the
CPU. We can use that hint to prevent such BOs from ever being stored in
the CPU inaccessible part of VRAM.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
The VertexProgram and FragmentProgram have a Cache member for dealing
with fixed function programs. There are no fixed function geometry
programs, so this should never have existed, and was just copy and
pasted.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/mtypes.h
https://bugs.freedesktop.org/show_bug.cgi?id=83148
Fabio Pedretti fabio@libero.it changed:
What|Removed |Added
Hardware|x86-64 (AMD64) |All
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniform_query.cpp | 2 +-
1 file changed, 1
On Tue, Aug 26, 2014 at 04:39:55PM -0700, Kenneth Graunke wrote:
Apparently guardband clipping doesn't work like we thought: objects
entirely outside fthe guardband are trivially rejected, regardless of
their relation to the viewport. Normally, the guardband is larger than
the viewport, so
https://bugs.freedesktop.org/show_bug.cgi?id=83148
--- Comment #15 from Maciej guti...@outlook.com ---
Did an updated from Oibaf PPA few minutes ago, problem fixed, thank you ;)
--
You are receiving this mail because:
You are the assignee for the bug.
Am 28.08.2014 um 08:56 schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
This flag is a hint that userspace expects the BO to be accessed by the
CPU. We can use that hint to prevent such BOs from ever being stored in
the CPU inaccessible part of VRAM.
Signed-off-by: Michel
At least with the other components on which Mesa relies (e.g., libdrm,
2D drivers, etc.) it's largely the same group of people with the same
set of goals.
This was only true until Tom Stellard started to manage LLVM point releases.
Christian.
Am 28.08.2014 um 00:07 schrieb Ian Romanick:
On
https://bugs.freedesktop.org/show_bug.cgi?id=83148
--- Comment #16 from Andy Furniss adf.li...@gmail.com ---
(In reply to comment #13)
Created attachment 105365 [details] [review]
u_vbuf: Make sure all caps are initialized
Does this patch help? I think caps.user_vertex_buffers being randomly
I'd like to say up front that while I could imagine that perhaps some
of my comments on radeonsi could be perceived as harsh, it's not my
intention to pick on radeonsi or anyone working on radeonsi in
particular. I just think radeonsi / r600g is probably the best
comparison inside Mesa for a
If available use Pixman fastpath for texture argb conversion.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/main/texstore.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/src/mesa/main/texstore.c
Added '--enable-pixman' (default=no) parameter for autogen
and the corresponding behaviour to include paths and Pixman
library for Mesa if Pixman found.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
configure.ac | 30 ++
1 file changed, 30
This patch adds utility functions for using Pixman to
convert textures between different pixel formats.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/main/texstore.c | 111 +++
1 file changed, 111 insertions(+)
diff
Here is new version of my patch set for using Pixman in Mesa
for texture format conversions, mostly complete rewrite after recent
changes in src/mesa/main/texstore.c. This set does not cause
regressions in Piglit quick set on SNB.
Here are some timings I came up from with this set when running
On Thu, Aug 28, 2014 at 1:52 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
Pointed out by valgrind.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83148
Signed-off-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Alex Deucher
On Thu, Aug 28, 2014 at 2:37 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
Putting those in VRAM seems to cause (worse) stutter in Unigine Valley on
some systems.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82050
Signed-off-by: Michel
Oops there's a bug in there, I'll send out a new version (we only pass a
one pixel sized array).
FWIW the msaa case also has its issues (generates a warning in
store_texsubimage, I guess that's pretty harmless though at the very
least the default value is going not to be what it should but who
Hi Juha-Pekka,
On 28/08/14 13:51, Juha-Pekka Heikkila wrote:
Added '--enable-pixman' (default=no) parameter for autogen
and the corresponding behaviour to include paths and Pixman
library for Mesa if Pixman found.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
From: Roland Scheidegger srol...@vmware.com
mesa was creating a cube map array texture with just one layer, which is
not legal. This caused an assertion failure when using that texture later
in llvmpipe (when enabling cube map arrays) since it verifies the number
of layers in the view is
On 22/08/14 17:41, Andreas Pokorny wrote:
Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.
Hi Andreas,
I'm hoping that Giovanni will take a look. After all kms-dri is his creation.
From my POV the patch is good
https://bugs.freedesktop.org/show_bug.cgi?id=83195
Priority: medium
Bug ID: 83195
Assignee: mesa-dev@lists.freedesktop.org
Summary: destroy GL context on stall recovery
Severity: minor
Classification: Unclassified
OS: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=82539
--- Comment #11 from Emil Velikov emil.l.veli...@gmail.com ---
In case the previous came as your fault not mine.
There are some loose things in our current build, but in order to fix it
properly I would need to now what the expected result of
On Thu, Aug 28, 2014 at 4:57 AM, Christian König
deathsim...@vodafone.de wrote:
Am 28.08.2014 um 08:56 schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
This flag is a hint that userspace expects the BO to be accessed by the
CPU. We can use that hint to prevent such BOs from
draw module has loads of !util_is_inf_or_nan() assertions, but most are
#ifdef'd out. If my memory serves me right, they were useful to cacth
bugs (as NaNs shouldn't appear when the input is not NaN). But as you
say, it's not a valid assumption, when inputs are NaNs.
Series looks good to
From: Roland Scheidegger srol...@vmware.com
Pretty trivial, just fill in the offsets and such. The implementation
is near 100% copy and paste from llvmpipe. Should be useful for debugging.
No piglit change when not using SOFTPIPE_USE_LLVM=1.
Now that it can do the same tests with and without
From: Roland Scheidegger srol...@vmware.com
Pretty easy, just make sure that all paths testing for PIPE_TEXTURE_CUBE
also recognize PIPE_TEXTURE_CUBE_ARRAY, and add the layer * 6 calculation
to the calculated face.
Also handle it for texture size query, looks like OpenGL wants the number
of
Juha-Pekka,
I'll try and look at the actual patches here next week. For now, a couple
quick comments.
On Thu, Aug 28, 2014 at 5:51 AM, Juha-Pekka Heikkila
juhapekka.heikk...@gmail.com wrote:
Here is new version of my patch set for using Pixman in Mesa
for texture format conversions, mostly
Ahh wrong patch sent again. This one is unchanged.
Roland
Am 28.08.2014 18:17, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Pretty trivial, just fill in the offsets and such. The implementation
is near 100% copy and paste from llvmpipe. Should be useful for
On 28/08/14 04:15, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Pretty easy, just make sure that all paths testing for PIPE_TEXTURE_CUBE
also recognize PIPE_TEXTURE_CUBE_ARRAY, and add the layer * 6 calculation
to the calculated face.
Also handle it for texture size
Am 28.08.2014 18:19, schrieb Jose Fonseca:
On 28/08/14 04:15, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Pretty easy, just make sure that all paths testing for PIPE_TEXTURE_CUBE
also recognize PIPE_TEXTURE_CUBE_ARRAY, and add the layer * 6 calculation
to the
On 26.08.2014 15:17, Abdiel Janulgue wrote:
On 23.08.2014 02:57, Ian Romanick wrote:
Patches 2, 3, 4, 5, 6, 9, 10, 11, 12, 15, and 17 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
(Additional question below.)
On 08/18/2014 05:17 AM, Abdiel Janulgue wrote:
v3 of clamp and
Kenneth Graunke kenn...@whitecape.org writes:
The VertexProgram and FragmentProgram have a Cache member for dealing
with fixed function programs. There are no fixed function geometry
programs, so this should never have existed, and was just copy and
pasted.
Reviewed-by: Eric Anholt
Hi,
Thanks for looking through that again.
On Thu, Aug 28, 2014 at 4:01 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 22/08/14 17:41, Andreas Pokorny wrote:
Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast
Hi,
On Thu, Aug 28, 2014 at 6:09 PM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
On Thu, Aug 28, 2014 at 4:01 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 22/08/14 17:41, Andreas Pokorny wrote:
Allows using prime fds as display target and from display target.
Test for
On Tue, Aug 12, 2014 at 9:48 AM, Kenneth Graunke kenn...@whitecape.org wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index d3509a0..19f7ef8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++
On Monday, August 25, 2014 06:41:54 PM Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_disasm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
b/src/mesa/drivers/dri/i965/brw_disasm.c
index 424b214..65c6f23 100644
---
On 28/08/14 01:31, Alexander von Gluck IV wrote:
Hi Alex,
Does that mean that we'll get non-softpipe hgl drivers soon :P
Feel free to squash the attached patch. It cleans up a couple of whitespace
issues + adds st/hgl to EXTRA_DIST (so that it gets picked up by 'make dist')
-Emil
P.S. Is it
On Thu, Aug 28, 2014 at 1:54 PM, Kenneth Graunke kenn...@whitecape.org wrote:
Both are used in the docs, so it's kind of a toss-up. I'm fine with this,
though, and the rest of the series looks great.
Right, for CMP it doesn't make much of a difference, but for AND...
and.z makes a lot more
It is meant to be private within the actual winsys. Remove it from
the exported header, and fold it into it's only user.
Cc: Alexander von Gluck IV kallis...@unixzen.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/winsys/sw/hgl/hgl_sw_winsys.c | 19 +++
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/Makefile.am | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am
index e4ef003..fd205d7 100644
--- a/src/gallium/Makefile.am
+++ b/src/gallium/Makefile.am
@@ -177,6 +177,8 @@
Cc: Alexander von Gluck IV kallis...@unixzen.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
include/HaikuGL/OpenGLKit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/HaikuGL/OpenGLKit.h b/include/HaikuGL/OpenGLKit.h
index f482871..71d9830 100644
---
Cc: Alexander von Gluck IV kallis...@unixzen.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/targets/haiku-softpipe/GalliumContext.cpp | 2 +-
src/gallium/targets/haiku-softpipe/SConscript | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On , Emil Velikov wrote:
Cc: Alexander von Gluck IV kallis...@unixzen.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/targets/haiku-softpipe/GalliumContext.cpp | 2 +-
src/gallium/targets/haiku-softpipe/SConscript | 2 +-
2 files changed, 2 insertions(+), 2
On 28/08/14 22:27, Alexander von Gluck IV wrote:
On , Emil Velikov wrote:
Cc: Alexander von Gluck IV kallis...@unixzen.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/targets/haiku-softpipe/GalliumContext.cpp | 2 +-
src/gallium/targets/haiku-softpipe/SConscript
On 27/08/14 04:23, Alex Deucher wrote:
On Sun, Aug 24, 2014 at 8:32 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
The first UVD generation can only do frame based output.
Signed-off-by: Christian König christian.koe...@amd.com
Can
On 27/08/14 04:23, Alex Deucher wrote:
On Sun, Aug 24, 2014 at 8:32 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
The first UVD generation can only do frame based output.
Signed-off-by: Christian König christian.koe...@amd.com
Can
Previously, if chans 4, we passed uninitialized stack garbage to the
ir_swizzle constructor for the excess components. Thankfully, it
ignores that data, as it's unnecessary, so no harm actually comes of it.
However, it's obviously better to initialize it.
Signed-off-by: Kenneth Graunke
Previously, opt_copy_propagation_elements would always rewrite the
instruction stream, even if was the same thing as before. In order to
report progress correctly, we'll need to bail if the suggested
replacement is identical (or equivalent) to the original code.
This also introduced unnecessary
It's been altering the tree and reporting false since January 2011.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/opt_copy_propagation_elements.cpp | 1 +
1 file changed, 1 insertion(+)
No changes in shader-db (34,558 shaders) nor Piglit on Haswell.
diff --git
Currently, setup_glsl_msaa_blit_shader() doesn't store compiled
msaa shaders generated for specific sample counts. This causes
the recompilation BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE* and
BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_RESOLVE* shaders every
time there is a change in source buffer sample
Patch contains no functional changes.
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/common/meta.h | 1 +
src/mesa/drivers/common/meta_blit.c | 17 ++---
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/common/meta.h
Currently, BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE* and
BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_RESOLVE* shaders
in setup_glsl_msaa_blit_shader() are not recompiled
when the source buffer sample count changes.
Fixes following piglit tests on Broadwell:
ext_framebuffer_multisample-accuracy
On 04.07.2014 01:24, Andy Furniss wrote:
Maybe not 1/frame but anyway the first couple of a run have numbers
rather than s
[27977.386795] radeon :01:00.0: GPU fault detected: 146 0x0c035014
[27977.386800] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR
0x15E0
On Thu, Aug 28, 2014 at 4:01 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 22/08/14 17:41, Andreas Pokorny wrote:
Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.
Hi Andreas,
I'm hoping that Giovanni will
Hello sir/madam,
I am a computer science student with good knowledge of C and C++ . I want
to know more about this project and how to work on this one .
Please help me if possible.
Anurag Das
Indian Institute of Information Technology,India
On , Emil Velikov wrote:
On 28/08/14 01:31, Alexander von Gluck IV wrote:
Hi Alex,
Does that mean that we'll get non-softpipe hgl drivers soon :P
Maybe!
I'm mostly cleaning all of this up in preperation for work on a
haiku-intel
target on my github. Not sure if it will go anywhere, but I
On 29.08.2014 00:01, Alex Deucher wrote:
On Thu, Aug 28, 2014 at 4:57 AM, Christian König
deathsim...@vodafone.de wrote:
Am 28.08.2014 um 08:56 schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
This flag is a hint that userspace expects the BO to be accessed by the
CPU. We
Anuj,
A cursory reading on my phone says these patches should be OK. I'll give
it a more thorough look tomorrow when I have the full source in front of me.
One comment though: Is there a good reason this is 3 patches? The first
redactors stuff just so you can do a check in the second which you
Currently a no-op, since instruction compaction isn't implemented for the
generations that have a programmable strips-and-fans unit.
---
src/mesa/drivers/dri/i965/brw_sf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
It may be possible to create a contrived example in which a 3-src
instruction would have been compacted on Gen 8. I'd rather not
discover it in the wild.
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 8c30809..5617947 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
+++
The array was previously indexed in units of brw_compact_inst (8-bytes),
but before compaction all instructions are uncompacted, so every odd
element was unused.
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 59 +++---
1 file changed, 37 insertions(+), 22 deletions(-)
This series adds instruction compaction support for G45 and Gen5
and enables compaction of control flow instructions.
Available from
git://people.freedesktop.org/~mattst88/mesa compaction-improvements
[PATCH 01/14] i965: Set JumpCount, not JIP, on ENDIF on Gen 6.
Benign bug fix.
[PATCH
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 215 -
1 file changed, 210 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index acce663..5008ba6 100644
---
Despite what the Sandybridge PRM says, ENDIF has Jump Count in dst,
not JIP in src1. (The same mistake appears about WHILE as well).
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
The spec says the type must be W (JIP is 16-bits after all), but we've
been emitting it with a UD type all along and have experienced no
adverse effects. Changing the type to D allows ELSE and ENDIF
instructions to be compacted.
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 4 ++--
1 file
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index dd32175..696ed98 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
+++
---
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
src/mesa/drivers/dri/i965/brw_disasm.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 0ef43e9..251f5b7 100644
---
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 32 --
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 696ed98..c291f96 100644
---
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 35 ++
1 file changed, 35 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index e9ba928..38a60d0 100644
---
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 39 ++
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 5008ba6..9c23d55 100644
---
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 5617947..dd32175 100644
---
We're currently emitting compactable control flow instruction the wrong
types, preventing their compaction. The next patch will fix this and
actually enable compaction.
On chips that cannot compact control flow instructions, attempts to find
a match in the datatype table will fail.
---
From: Roland Scheidegger srol...@vmware.com
I actually screwed that up in 754319490f6946a9ad5ee619822d5fe4254e6759,
mistakenly thinking the code actually wanted the non-nan result before.
So, introduce that missing nan behavior case and use that instead.
For sse, there's no actual change in the
In commit 04895f5c I added support for reswizzling writemasks. This test
was checking that we didn't support this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82881
---
src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
https://bugs.freedesktop.org/show_bug.cgi?id=83148
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Status|NEW |RESOLVED
80 matches
Mail list logo
