Hi,
why is mesa-dev CC'd to this mail? I guess that mesa run into this problem and
there is a thread on mesa-dev which could be provided in the commit message as
an extra reference? (This also means that this mail will end up in mesa-dev's
moderation queue...)
On 08.05.2013 14:58, Christian König
On 05/09/2013 05:42 AM, Dragomir Ivanov wrote:
Hmm, Vadim... it works indeed. I can't push up to Ultra, but I see the
difference as on your screenshots.
Interestingly when I play it on win with catalyst, everything is WOW, on
r600g is Meh...
Unfortunately I erased windows, so I can't supply scree
We would crash when stride was bigger than the size of the buffer.
The correct behavior is to just fetch zero's in this case.
Unfortunatly gallium allows user_buffers in vertex_buffers and we
can't figure out the sizes of those, so we need to null check
the buffer to see if we can at all perform th
On 05/08/2013 08:06 PM, Eric Anholt wrote:
> Tapani Pälli writes:
>
>> Patch makes sure in conservative way that the depth_clear_value
>> is correct and represents max depth of current depth buffer.
>>
>> This fixes the case where user has 16bit color buffer but 24bit
>> depth buffer and 'fb->_De
Am 09.05.2013 03:55, schrieb Bryan Cain:
> On 05/08/2013 03:26 PM, Roland Scheidegger wrote:
>> There's some other
>> somewhat bogus code with comments saying UCMP should be used instead of
>> some poor emulation with i2f instructions.
>
> Yeah, sorry about that. I wrote that code (and comment) a
For vec4 equality comparisons we emit
(and (and (and a b) c) d)
which leads to three dependent instructions. We can reassociate the
operands which allows the first two instructions to be issued
independently. Turn it into:
(and (and a b) (and c d))
Do the same thing for ORs, used in vec4
On 05/08/2013 03:26 PM, Roland Scheidegger wrote:
> There's some other
> somewhat bogus code with comments saying UCMP should be used instead of
> some poor emulation with i2f instructions.
Yeah, sorry about that. I wrote that code (and comment) a few days
before the UCMP opcode was added to TGSI
Hmm, Vadim... it works indeed. I can't push up to Ultra, but I see the
difference as on your screenshots.
Interestingly when I play it on win with catalyst, everything is WOW, on
r600g is Meh...
Unfortunately I erased windows, so I can't supply screenshot, but
subjectively it was way more beautiful
On 05/09/2013 02:42 AM, Dragomir Ivanov wrote:
Hi there,
I just fired Doom3 on 64 -bit Arch Linux (no 32 libs involved), to test
r600g progress.
Game runs fine, but I can't see bump mapping effects as on Catalyst under
windows. They are enabled in the options. Does Mesa/r600g support bumps?
AMD E
On 05/07/2013 03:53 PM, Eric Anholt wrote:
With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to
renderbuffers that are also textures, so the core Mesa FinishRenderTexture
hook doesn't get called. That hook also wasn't called in various cases
within the driver where we'd update te
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp |2 ++
test/CodeGen/R600/sub.ll | 15 +++
2 files changed, 17 insertions(+)
create mode 100644 test/CodeGen/R600/sub.ll
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600/R600ISel
From: Roland Scheidegger
I don't know what this code was trying to do but whatever it was it couldn't
have worked since negation of integer boolean inputs while not specified as
outright illegal (not yet at least) won't do anything since it doesn't affect
the result of comparison with zero at all
This fixes Piglit test shaders/link-mismatch-layout-02.
---
src/glsl/linker.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 4415b8d..4bc0eee 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -561,6 +561,7 @@ cross_validate_globa
Fail linking if gl_FragCoord is used with different layout qualifiers in
seperate shader objects.
This fixes Piglit test shaders/link-mismatch-layout-01.
---
src/glsl/linker.cpp | 34 ++
1 file changed, 34 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/
Fail compile if gl_FragCoord is redeclared with different layout qualifiers in
one shader.
---
src/glsl/ast_to_hir.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 63fbd5a..d6362b0 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b
It is illegal to redeclare builtin variables with incompatible layout
qualifiers in seprerate shader objects that are linked together. Since a
redeclaration without any layout qualifiers can be incompatible with another
redeclartion where no redeclaration wouldn't be, it can be necessary to know
we
Prior to GLSL version 1.3 builtin variables such as gl_Position have no storage
qualifiers (in or out). However, the internal declarations in Mesa have storage
qualifiers regardless of version.
As the code to identify a redeclaration checks for identical storage qualifiers
you cannot redeclare bui
Hi there,
I just fired Doom3 on 64 -bit Arch Linux (no 32 libs involved), to test
r600g progress.
Game runs fine, but I can't see bump mapping effects as on Catalyst under
windows. They are enabled in the options. Does Mesa/r600g support bumps?
AMD E-350 here. Evergreen class GPU.
OpenGL renderer
On Wed, May 8, 2013 at 2:39 PM, Kenneth Graunke wrote:
> Much like we do for G45.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
Much like we do for G45.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index ee2c9f1..09c
On Tue, Apr 23, 2013 at 3:54 PM, Ander Conselvan de Oliveira
wrote:
> Linux kernel 3.8 shipped with a bug in the prime fd passing code that
> makes it unreliable. As of this writing, it seems unlikely that 3.9
> will contain the fix for the issue.
>
> This patch disable prime support when running
Fredrik Höglund writes:
> On Tuesday 07 May 2013, Eric Anholt wrote:
>> Ever since fake front was introduced in
>> 63b51b5cf17ddde09b72a2811296f37b9a4c5ad2, we were skipping the XSync() in
>> the non-fake-front path, so compositors like Firefox's GL canvas were
>> having to manually put it in out
Christoph Brill writes:
> Hi list,
>
> I'm trying to follow the patches and patchsets sent to mesa-dev and
> really like the process of how they get reviewed. It's a good way of
> catching bugs before they get committed. But currently this approach
> has a downside (at least for me): It's easy to
Am 08.05.2013 17:17, schrieb Marek Olšák:
> The SUB opcode is not emitted by GLSL, however this may change in the
> future. I don't think using specialized opcodes instead of the
> modifiers will make anyone's life easier (the modifiers must be
> implemented anyway).
>
> If you really want people
Fixes piglit test for OpenCL builtin mul24, and allows mad24 to run.
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp |2 ++
test/CodeGen/R600/mul.ll | 16
2 files changed, 18 insertions(+)
create mode 100644 test/CodeGen/R600/mul.ll
diff -
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #17 from Keith Kriewall ---
I posted this issue to Microsoft and they have released a hotfix for Visual
Studio 2010 SP1 to correct it:
http://support.microsoft.com/kb/2836024
--
You are receiving this mail because:
You are the ass
Signed-off-by: Aaron Watry
v2: Add v4i32 test
---
lib/Target/R600/R600ISelLowering.cpp |2 ++
test/CodeGen/R600/sra.ll | 13 +
2 files changed, 15 insertions(+)
create mode 100644 test/CodeGen/R600/sra.ll
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Ta
Signed-off-by: Aaron Watry
v2: Add vselect v4i32 test
---
lib/Target/R600/R600ISelLowering.cpp |3 +++
test/CodeGen/R600/vselect.ll | 17 +
2 files changed, 20 insertions(+)
create mode 100644 test/CodeGen/R600/vselect.ll
diff --git a/lib/Target/R600/R600ISelLower
These two patches fix a number of piglit OpenCL test failures on my
HD6850 (Barts).
There are no piglit CL test regressions and the llvm make check runs
without any unexpected failures.
v2: Add tests for v4i32 data type.
___
mesa-dev mailing list
mesa-
Series looks good to me.
Jose
- Original Message -
> The support is analogous to the way we handle indirect addressing
> in temporaries, except that we don't have to worry about storing
> (after declarations) and thus we'll able to keep using the old
> code when indirect addressing isn't
On 05/08/2013 10:05 AM, Kenneth Graunke wrote:
On 05/08/2013 09:48 AM, Chad Versace wrote:
Mesa's extension table incorrectly lists this GL_OES_texture_npot as
ES2-only. It's also an ES1 extension. This patch adds ES1 to the
extensions API mask.
From the GL_OES_texture_npot spec:
OpenGL E
On 05/07/2013 04:46 PM, Ian Romanick wrote:
On 05/07/2013 03:53 PM, Eric Anholt wrote:
With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to
^
image
renderbuffers that are also textures, so the core Mesa
FinishRenderTexture
hook doesn't get c
On 05/08/2013 09:59 AM, Eric Anholt wrote:
Ian Romanick writes:
On 05/07/2013 03:53 PM, Eric Anholt wrote:
With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to
^
image
renderbuffers that are also textures, so the core Mesa FinishRenderTe
On 05/08/2013 09:57 AM, Eric Anholt wrote:
Dave Airlie writes:
Haswell has been broken on master for a surprisingly long time, since
commit
1dfea559c3 (Thu May 2 11:27:37 2013 -0700). Reverting that commit fixed
it
for me.
If it doesn't get properly fixed by the 7th day, I'd like to see the
Tapani Pälli writes:
> Patch makes sure in conservative way that the depth_clear_value
> is correct and represents max depth of current depth buffer.
>
> This fixes the case where user has 16bit color buffer but 24bit
> depth buffer and 'fb->_DepthMax' has a wrong value. I'm currently
> investiga
On 05/08/2013 09:48 AM, Chad Versace wrote:
Mesa's extension table incorrectly lists this GL_OES_texture_npot as
ES2-only. It's also an ES1 extension. This patch adds ES1 to the
extensions API mask.
From the GL_OES_texture_npot spec:
OpenGL ES 1.0 or OpenGL ES 2.0 is required. This extensi
Ian Romanick writes:
> On 05/07/2013 03:53 PM, Eric Anholt wrote:
>> With EGL_KHR_gl_renderbuffer_iamge, we have the ability to render to
> ^
> image
>
>> renderbuffers that are also textures, so the core Mesa FinishRenderTexture
>> hook doesn't get called. Th
Dave Airlie writes:
>>>
Haswell has been broken on master for a surprisingly long time, since
commit
1dfea559c3 (Thu May 2 11:27:37 2013 -0700). Reverting that commit fixed
it
for me.
If it doesn't get properly fixed by the 7th day, I'd like to see the
guil
On 05/08/2013 09:48 AM, Chad Versace wrote:
Mesa's extension table incorrectly lists this GL_OES_texture_npot as
ES2-only. It's also an ES1 extension. This patch adds ES1 to the
extensions API mask.
From the GL_OES_texture_npot spec:
OpenGL ES 1.0 or OpenGL ES 2.0 is required. This extensi
Mesa's extension table incorrectly lists this GL_OES_texture_npot as
ES2-only. It's also an ES1 extension. This patch adds ES1 to the
extensions API mask.
>From the GL_OES_texture_npot spec:
OpenGL ES 1.0 or OpenGL ES 2.0 is required. This extension is
written against OpenGL ES 1.1.12 and
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
test/CodeGen/R600/llvm.AMDGPU.imax.ll | 21 +
test/CodeGen/R600/llvm.AMDGPU.imin.ll | 21 +
test/CodeGen/R600/llvm.AMDGPU.trunc.ll | 22 +++---
test/CodeGen/R600/llvm.AMDGPU.umax.ll |
Reviewed-by: Marek Olšák
Marek
On Wed, May 8, 2013 at 6:20 PM, Brian Paul wrote:
> Before, if we failed to allocate the index buffer we'd silently
> return from st_draw_vbo() without drawing anything. We should
> raise GL_OUT_OF_MEMORY to give some indication that something went
> wrong.
> ---
Before, if we failed to allocate the index buffer we'd silently
return from st_draw_vbo() without drawing anything. We should
raise GL_OUT_OF_MEMORY to give some indication that something went
wrong.
---
src/mesa/state_tracker/st_draw.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
I don't really care much about modifiers vs no-modifiers, or ABS/SUB opcodes vs
no opcodes. It is merely a convention, and as long as we consistently follow
it we're good IMO.
I am, however, worried about this growing trend of long threads about TGSI with
little more than nitpicking. I think
- Original Message -
> The SUB opcode is not emitted by GLSL, however this may change in the
> future. I don't think using specialized opcodes instead of the
> modifiers will make anyone's life easier (the modifiers must be
> implemented anyway).
>
> If you really want people to follow the
Am 08.05.2013 05:16, schrieb Zack Rusin:
> The support is analogous to the way we handle indirect addressing
> in temporaries, except that we don't have to worry about storing
> (after declarations) and thus we'll able to keep using the old
> code when indirect addressing isn't used. In other words
The SUB opcode is not emitted by GLSL, however this may change in the
future. I don't think using specialized opcodes instead of the
modifiers will make anyone's life easier (the modifiers must be
implemented anyway).
If you really want people to follow the TGSI documentation, there
should be a ut
From: Christian König
The last queued surface always keeps displaying.
Fixing a problem with XBMC.
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/presentation.c |8 ---
src/gallium/state_trackers/vdpau/vdpau_private.h | 28 +++---
2 files change
The support is analogous to the way we handle indirect addressing
in temporaries, except that we don't have to worry about storing
(after declarations) and thus we'll able to keep using the old
code when indirect addressing isn't used. In other words we're
still using constants directly, unless the
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_gs.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_gs.c
b/src/gallium/auxiliary/draw/draw_gs.c
index fcd6e2d..fa0981e 100644
--- a/src/gallium/auxiliary/draw/draw_gs.c
++
On 05/03/2013 04:07 PM, Ian Romanick wrote:
From: Ian Romanick
Now that all the places that used to generate array derefeneces of
vectors have been changed to generate either ir_binop_vector_extract or
ir_triop_vector_insert (or both), remove all support for dealing with
this deprecated constru
On 05/08/2013 03:14 AM, Stéphane Marchesin wrote:
It helps a bit with vertex shader performance on i915g
(a couple percent faster with openarena).
I have tried most other passes, and they weren't showing
any measurable improvement. Note that my vertex shaders
didn't have loops, so maybe the loop
On Tue, May 07, 2013 at 10:48:53AM +0200, Christian König wrote:
> Am 06.05.2013 18:48, schrieb Tom Stellard:
> >From: Tom Stellard
> >
> >The BFE optimization was the only one we were actually using, and it was
> >emitting an intrinsic that we don't support.
> >
> >https://bugs.freedesktop.org/sh
Am 08.05.2013 12:47, schrieb Marek Olšák:
> Modifiers are actually very useful with MOV. However I don't think the
> modifiers really care what the type is. They just change the sign bit
> of float (which is a bitwise operation). Also, UCMP doesn't do
> anything with the 2nd and 3rd argument, so th
From: Christian König
libX11 acquires the display lock before calling "xcb_take_socket" and inside
the "return_socket" callback, this can lead to a classic deadlock situation
with the XCB iolock. Releasing the lock while calling "return_socket" only
partially helps because we still try to avoid c
Hi list,
I'm trying to follow the patches and patchsets sent to mesa-dev and
really like the process of how they get reviewed. It's a good way of
catching bugs before they get committed. But currently this approach
has a downside (at least for me): It's easy to miss a patch and
happens from time t
Hi Peter,
Am 08.05.2013 11:48, schrieb test automation:
Hi Everyone,
Could you please tell me about whom to contact if I want to do this
Automatic testing in the To-Do List ?
Help Wanted / To-Do List
*Automatic testing. * It would be great if someone would set up an
automated system for grabb
Modifiers are actually very useful with MOV. However I don't think the
modifiers really care what the type is. They just change the sign bit
of float (which is a bitwise operation). Also, UCMP doesn't do
anything with the 2nd and 3rd argument, so their types don't matter.
I think the ABS and SUB o
On Thu, May 2, 2013 at 7:12 PM, Eric Anholt wrote:
> Marek Olšák writes:
>
>> Shaders are unified on most hardware (= same limits in all stages).
>> No idea what the assertion was good for.
>> ---
>> src/mesa/main/config.h |6 ++
>> src/mesa/main/context.c
On 08.05.2013 03:48, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> UCMP while an integer opcode isn't really consistently implemented as
> having all integer arguments. softpipe will assume all arguments are
> ints, whereas gallivm has the arguments defined as untyped which
> means the
Patch makes sure in conservative way that the depth_clear_value
is correct and represents max depth of current depth buffer.
This fixes the case where user has 16bit color buffer but 24bit
depth buffer and 'fb->_DepthMax' has a wrong value. I'm currently
investigating how to get _DepthMax correcte
Hi Everyone,
Could you please tell me about whom to contact if I want to do this
Automatic testing in the To-Do List ?
Help Wanted / To-Do List
*Automatic testing. * It would be great if someone would set up an
automated system for grabbing the latest Mesa code and run tests (such as
piglit) the
On 05/07/2013 12:23 AM, Chad Versace wrote:
Emit EGL_BAD_CONTEXT if the user passes a context to
eglCreateImageKHR(type=EGL_ANDROID_image_native_buffer).
From the EGL_ANDROID_image_native_buffer spec:
* If is EGL_NATIVE_BUFFER_ANDROID and is not
EGL_NO_CONTEXT, the error EGL_BAD_CONTE
It helps a bit with vertex shader performance on i915g
(a couple percent faster with openarena).
I have tried most other passes, and they weren't showing
any measurable improvement. Note that my vertex shaders
didn't have loops, so maybe the loop optimizations could
still be useful in the future.
64 matches
Mail list logo
