Hi Marek,
Since it seems no one else have any comments on this, maybe you could
commit it for me?
//Martin
On Thu, Dec 26, 2013 at 1:15 PM, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Thu, Dec 26, 2013 at 10:33 AM, Martin Andersson wrote:
>> Fixes
Fixes wayland regression on r600g due to fast clear introduced by commit
edbbfac6.
---
src/gallium/state_trackers/egl/common/native_helper.c | 15 +++
src/gallium/state_trackers/egl/common/native_helper.h | 5 +
src/gallium/state_trackers/egl/wayland/native_wayland.c | 4
On Fri, Aug 9, 2013 at 8:28 PM, Ian Romanick wrote:
> On 08/09/2013 04:22 AM, Martin Andersson wrote:
>>
>> I think I have found an issue in the piglit test.
>>
>> Marek, could you take a look at the attached patch and see if it looks
>> correct. If so I will send
for RGBX integer
> formats and see if it helps.
>
> In is_format_supported, return FALSE for all R?G?B?X_?INT formats.
>
> Marek
>
> On Sat, Aug 3, 2013 at 11:51 AM, Martin Andersson wrote:
>> Well, I should have been more clear. If I do this:
>>
>> 263: value[3]
be set to 1.0, because RGB formats
> must return (r,g,b,1). It's a bug in the piglit test.
>
> Marek
>
> On Fri, Aug 2, 2013 at 11:44 PM, Martin Andersson wrote:
>> On Fri, Aug 2, 2013 at 2:52 PM, Marek Olšák wrote:
>>> The format doesn't have alpha. See what th
y try setting "texture-integer.c:290" to "expected[3] = 1.0;"
The test passes if I do that.
//Martin
>
> Marek
>
> On Fri, Aug 2, 2013 at 2:15 PM, Martin Andersson wrote:
>> Hi,
>>
>> I started to look at why the spec/!OpenGL 3.0/gl-3.0-textur
Hi,
I started to look at why the spec/!OpenGL 3.0/gl-3.0-texture-integer
sometimes fails on my AMD 6950, using mesa master. It fails with
errors like this:
texture-integer: failure with format GL_RGB8I_EXT:
texture color = 100, 9, 71, 0
expected color = 0.25, 0.5, 0.75, 0
result color = 0.2
another test that fail randomly
(spec/EXT_framebuffer_blit/fbo-sys-blit) but it is broken with the
first patch as well.
//Martin
> Alex
>
>>
>> Marek
>>
>> On Sun, Jun 23, 2013 at 7:41 PM, Alex Deucher wrote:
>>> On Sat, Jun 22, 2013 at 11:53 AM, Martin Anderss
On Sun, Jun 23, 2013 at 7:41 PM, Alex Deucher wrote:
> On Sat, Jun 22, 2013 at 11:53 AM, Martin Andersson wrote:
>> On Sat, Jun 22, 2013 at 12:22 PM, Marek Olšák wrote:
>>> Reviewed-by: Marek Olšák
>>>
>>> BTW, SMX is a write cache, to maybe it shouldn
, is that a better place?
If that is the proper place for SMX should SH also be there, since it
was also there before the patch, or do you have any other suggestions?
> Marek
>
> On Sun, Jun 16, 2013 at 1:27 PM, Martin Andersson wrote:
>> Not including the SH and SMX caches wh
Not including the SH and SMX caches when invalidating read caches causes
random failures on some piglit tests when VA is enabled.
Since the failures are random, and there other problems also causing random
failures, it's hard to know exactly what tests were effected, but these
tests now consistent
meone else find
the real solution to these problems.
This was tested with a 6950 on mesa master
6d7abafdc86c6d8533bcb798465452c78c2694e8
//Martin
Martin Andersson (1):
r600g: Include SH and SMX when invalidating read caches
src/gallium/drivers/r600/r600_hw_context.c | 2 ++
1 file change
On Mon, Jun 10, 2013 at 11:55 PM, Alex Deucher wrote:
> On Mon, Jun 10, 2013 at 5:36 PM, Marek Olšák wrote:
>> Reviewed-by: Marek Olšák
>>
>> FYI, Cayman works for me as I said in
>> https://bugs.freedesktop.org/show_bug.cgi?id=62959 . I don't remember
>> if the issue has been fixed upstream.
>
On Fri, Jun 7, 2013 at 8:58 AM, Martin Andersson wrote:
> On Fri, Jun 7, 2013 at 12:37 AM, Marek Olšák wrote:
>> There are bugs in both piglit and DRI2. I haven't looked into the
>> issue, but Paul Berry seems to be working on it.
>>
>> See:
>> http://list
p.org/archives/mesa-dev/2013-May/039985.html
>
> Marek
>
ok, it is good to know that it is being worked on, thanks
//Martin
> On Fri, Jun 7, 2013 at 12:04 AM, Martin Andersson wrote:
>> I get random results when I run the spec/!OpenGL 1.1/read-front test.
>> Sometimes it
I get random results when I run the spec/!OpenGL 1.1/read-front test.
Sometimes it passes and sometimes it failes, it mostly fails though.
When it fails the observed values are random. I have an AMD 6950,
running mesa git ce67fb4715e0c2fab01de33da475ef4705622020 and kernel
3.10-rc4.
If I insert a
There is a hardware bug on Cayman where a BREAK/CONTINUE followed by
LOOP_STARTxxx for nested loops may put the branch stack into a state
such that ALU_PUSH_BEFORE doesn't work as expected. Workaround this
by replacing the ALU_PUSH_BEFORE with a PUSH + ALU
Fixes piglit tests EXT_transform_feedback
On Mon, Apr 15, 2013 at 1:09 AM, Vadim Girlin wrote:
> On 04/15/2013 01:05 AM, Martin Andersson wrote:
>>
>> There is a bug where a BREAK/CONTINUE followed by LOOP_STARTxxx for nested
>> loops may put the branch stack into a state such that ALU_PUSH_BEFORE
>> doesn
There is a bug where a BREAK/CONTINUE followed by LOOP_STARTxxx for nested
loops may put the branch stack into a state such that ALU_PUSH_BEFORE
doesn't work as expected. Workaround this by replacing the ALU_PUSH_BEFORE
with a PUSH + ALU for nested loops.
Fixes piglit tests:
spec/!OpenGL 1.1/read-
On Sat, Apr 13, 2013 at 4:23 AM, Vadim Girlin wrote:
> On 04/12/2013 11:36 PM, Martin Andersson wrote:
>>
>> I have made some progress with this issue.
>>
>> Vadim, I did as you suggested and tried to mimic the output from the
>> shader analyser
>> tool. I u
> state.
>>>>> LOOP_BREAK should put them into the inactive-break state, but something
>>>>> goes wrong. Do the other piglit tests with nested loops (e.g.
>>>>> glsl-fs-loop-nested) work on cayman? Though possibly there are no other
>>>>> tests
On Tue, Apr 9, 2013 at 3:18 AM, Marek Olšák wrote:
> Pushed, thanks. The transform feedback test still doesn't pass, but at least
> the hardlocks are gone.
Thanks, I have looked into the other issue as well
http://lists.freedesktop.org/archives/mesa-dev/2013-March/036941.html
The problem arises
If there are no objections or comments on this, it would be nice if
someone could commit it.
//Martin
On Tue, Apr 2, 2013 at 10:43 PM, Martin Andersson wrote:
> The multiplication part of tgsi_umad did not work on Cayman, because it did
> not populate the correct vector slots.
> -
The multiplication part of tgsi_umad did not work on Cayman, because it did
not populate the correct vector slots.
---
src/gallium/drivers/r600/r600_shader.c | 45 --
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shade
On Sun, Mar 31, 2013 at 2:51 PM, Martin Andersson wrote:
>
> It compiles to, http://pastebin.com/cQ8rbKCv.
There should not be a dot at the end, the correct address is:
http://pastebin.com/cQ8rbKCv
I also configure mesa with --disable-gallium-llvm
//
Hi,
I think have found a bug in the r600g shader compiler. I have a AMD 6950
and I'm running mesa from git.
The bug is exercised by the the vertex shader program in piglit
ext_transform_feedback/order.c
I have simplified the shader program so the compiled shader is easier to read:
#version 130
On Sun, Mar 31, 2013 at 1:08 AM, Vadim Girlin wrote:
> On 03/30/2013 05:35 AM, Martin Andersson wrote:
>>
>> I found an issue with the shader compiler for Cayman when I looked
>> into why the ext_transform_feedback/order test case caused a GPU stall.
>> It turned ou
The tgsi_umad function does not work for Cayman since it does not
populate the y, z and w slots for UMUL that Cayman requires.
---
src/gallium/drivers/r600/r600_shader.c | 47 +-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/
ince that makes the loop run
too
many times (in my test case lasti is 0 and last_slot is 3). So I just removed
the
loop, was that correct or should i resolve that in some other way?
Martin Andersson (1):
r600g: Add a Cayman specific version of UMAD
src/gallium/drivers/r600/r60
Virtual address is used for PIPE_QUERY_SO* queries in
r600_emit_query_begin, but not in r600_emit_query_end.
This will trigger a GPU fault when one of those queries is
made and virtual address is enabled.
---
src/gallium/drivers/r600/r600_query.c | 5 +++--
1 file changed, 3 insertions(+), 2 dele
Thanks for implementing this, I just have one comment.
On Thu, Mar 14, 2013 at 7:45 PM, Marek Olšák wrote:
> Initial version contributed by: Martin Andersson
>
> This is only used if the memcpy path cannot be used and if no transfer ops
> are needed. It's pretty similar to
On Mon, Mar 11, 2013 at 3:56 PM, Jose Fonseca wrote:
> I'm surprised this is is faster.
>
> In particular, for big things we'll be touching memory twice.
>
> Did you measure the speed up?
I tested it with the previous patch, with GL_UNSIGNED_BYTE, and on
that case it was faster, but since that pa
On Mon, Mar 11, 2013 at 11:54 AM, Michel Dänzer wrote:
> On Son, 2013-03-10 at 23:05 +0100, Martin Andersson wrote:
>> ---
>> src/mesa/main/readpix.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/main/readpix.c b/src/mes
---
src/mesa/main/readpix.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 349b0bc..0f5c84c 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -285,11 +285,12 @@ fast_read_rgba_pixels_memcpy( struc
---
src/mesa/main/readpix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 2f130ae..349b0bc 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -238,7 +238,7 @@ fast_read_rgba_pixels_memcpy( struct gl_co
all.tests, quick.tests and r600.tests. The sanity.tests worked but it
does not hit the fast path.
Martin Andersson (2):
mesa: Add GL_UNSIGNED_BYTE fast-path to fast_read_rgba_pixels_memcpy
mesa: Speedup the xrgb -> argb special case in
fast_read_rgba_pixels_memcpy
src/mesa/m
The problem is that we mix bo handles and flinked names in the hash
table. Because kms type handles are not flinked they should not be
added to the hash table. If we do that we will sooner or later
get a situation where we will overwrite a correct entry because
the bo handle was the same as a flink
37 matches
Mail list logo
