On 08/13/15 21:30, Glenn Kennard wrote:
FLT_TO_INT goes in the vector pipes on evergreen/NI,
not the trans unit as on earlier chips.
FWIW, AFAIK it works in trans as well, just uses different rounding mode.
According to the description in the EG ISA doc: "Channels 0-3 use
the 32-bit round mode
On 09/28/2013 10:08 AM, Vinson Lee wrote:
Fixes "Deference before null check" defect reported by Coverity.
Signed-off-by: Vinson Lee
Reviewed-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_ra_init.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -
Currently it's hardcoded in the shader, so every change requires
compilation of the shader variant, killing the performance
in Serious Sam 3 and probably other apps.
This patch passes alpha_ref in the user sgpr and removes it from
the shader key.
Signed-off-by: Vadim Girlin
---
src/ga
On 10/10/2013 02:11 PM, Michel Dänzer wrote:
On Don, 2013-10-10 at 12:49 +0400, Vadim Girlin wrote:
Currently it's hardcoded in the shader, so every change requires
compilation of the shader variant, killing the performance
in Serious Sam 3 and probably other apps.
This patch passes alph
On 10/10/2013 08:10 PM, Christian König wrote:
Am 10.10.2013 18:02, schrieb Vadim Girlin:
On 10/10/2013 02:11 PM, Michel Dänzer wrote:
On Don, 2013-10-10 at 12:49 +0400, Vadim Girlin wrote:
Currently it's hardcoded in the shader, so every change requires
compilation of the shader va
operand for channels y and z
instead of original value in TEMP[2].x.
This patch stores the results in temp reg and moves them to
dst after performing operation on all channels.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=70327
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600
ing on liveness pass.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=70088
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_core.cpp| 10 --
src/gallium/drivers/r600/sb/sb_dce_cleanup.cpp | 22 ++
src/gallium/drivers/r600/sb/sb_pass.
On 10/19/2013 06:18 AM, Vinson Lee wrote:
Fixes "Uninitialized scalar field" defect reported by Coverity.
Signed-off-by: Vinson Lee
Reviewed-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_shader.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/s
---
cc: Andreas Boll
Andreas, this patch should fix the issue with SB on RV770 that you
reported on IRC (assert with interpolation-mixed.shader_test).
There are no piglit regressions with this patch on my evergreen,
but I can't test with r700 or any other chips.
src/gallium/drivers/r600/sb/sb
s << " CND:" << n.bc.pop_count;
+ s << " CND:" << n.bc.cond;
if (n.bc.pop_count)
s << " POP:" << n.bc.pop_count;
Reviewed-by: Vadim Girlin
_
ff-by: Vadim Girlin
Cc: "9.2"
---
src/gallium/drivers/r600/sb/sb_sched.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_sched.cpp
b/src/gallium/drivers/r600/sb/sb_sched.cpp
index f0e41f5..2792315 100644
--- a/src/gallium/
On 08/19/2013 01:35 AM, Vinson Lee wrote:
Fixes "Uninitialized pointer field" defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/r600/sb/sb_ir.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_ir.h
b/src/gall
On 08/19/2013 11:50 AM, Vinson Lee wrote:
Silences "Uninitialized pointer field" defects reported by Coverity.
Signed-off-by: Vinson Lee
Reviewed-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_ir.h | 6 +++---
src/gallium/drivers/r600/sb/sb_shader.cpp | 3 ---
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c| 3 ++-
src/gallium/drivers/r600/r600_pipe.c | 4 ++--
src/gallium/drivers/r600/r600_pipe.h | 2 +-
src/gallium/drivers/r600/r600_shader.c | 2 +-
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src
(especially with SB
which tends to reorder the exports).
Signed-off-by: Vadim Girlin
---
This fixes regressions with LLVM+SB, so I consider it as a prerequisite
for enabling SB by default. Also it fixes some issues with LLVM backend alone.
Tested on evergreen only (I don't have other hw),
k old backend uses the same logic.
Vadim
Marek
On Sat, Aug 24, 2013 at 3:30 AM, Vadim Girlin wrote:
Currently llvm backend always exports at least one color in pixel
shader even if no color buffers are enabled. With depth/stencil exports
this can result in the following code:
E
nr_cbufs==0, but it still relies on
nr_ps_color_exports value computed in the old backend path (which is
currently broken for that case), and this resulted in the regressions
that I wanted to fix. I'll send new patch.
Vadim
Marek
On Sat, Aug 24, 2013 at 3:12 PM, Vadim Girlin wrote:
On
We need to export at least one color if the shader writes it,
even when nr_cbufs==0.
Signed-off-by: Vadim Girlin
---
Tested on evergreen with multiple combinations of backends - no regressions,
fixes some tests:
default- fixes fb-alphatest-nocolor and fb_alphatest-nocolor-ff
default+sb
ing/benchmarking.
Vadim
Roland
Am 27.08.2013 19:56, schrieb Vadim Girlin:
We need to export at least one color if the shader writes it,
even when nr_cbufs==0.
Signed-off-by: Vadim Girlin
---
Tested on evergreen with multiple combinations of backends - no regressions,
fixes some tests:
Roland Scheidegger wrote:
Not that I'm qualified to review r600 code, but couldn't you create
different shader variants depending on whether you need alpha test? At
least I would assume shader exports aren't free.
Roland
Am 27.08.2013 19:56, schrieb Vadim Girlin:
We need to export
On 08/28/2013 02:28 AM, Roland Scheidegger wrote:
Am 27.08.2013 23:52, schrieb Vadim Girlin:
On 08/28/2013 12:43 AM, Marek Olšák wrote:
Shader variants are BAD, BAD, BAD. Have you ever played an AAA game
with a Mesa driver that likes to compile shader variants on first use?
It's HORRIBLE
ion is deferred somewhere in the
stack before the driver, or am I missing something?
Vadim
Marek
On Tue, Aug 27, 2013 at 11:52 PM, Vadim Girlin wrote:
On 08/28/2013 12:43 AM, Marek Olšák wrote:
Shader variants are BAD, BAD, BAD. Have you ever played an AAA game
with a Mesa driver that l
er variants and other times it is better to
have one variant covering all the different states and just use bit
constants to choose between them.
Just some thoughts on this topic,
Christian.
PS: My mail server is once more driving me nuts, please ignore the extra
copy if you get this mail twice.
Am 28.
Hi,
Last month I finally found the time to work on the rewrite of my
previous shader optimization branch, now it's mostly done in terms of
the correctness of produced code and feature support (at least on
evergreen), though it's still a work in progress in terms of the
efficiency of generated
On 02/14/2013 08:53 PM, Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear performance down to an unflyable stutter, with your
branch I can fly in densly clouded conditions at usable framerates. I can now
turn all shaders
On 02/14/2013 08:53 PM, Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear performance down to an unflyable stutter, with your
branch I can fly in densly clouded conditions at usable framerates. I can now
turn all shaders
r more value than the code itself.
Christian.
Am 14.02.2013 11:10, schrieb Dragomir Ivanov:
Greetings,
I hope that, even if you work will be short-lived, e.g. until LLVM
bytecode compiler takes off, the know-how is still very useful.
On Thu, Feb 14, 2013 at 4:04 AM, Vadim Girlin mailto:vadimgir..
On 02/15/2013 03:22 PM, Christian König wrote:
Am 15.02.2013 12:00, schrieb Vadim Girlin:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
s
On 02/15/2013 04:06 PM, Michel � wrote:
On Fre, 2013-02-15 at 15:00 +0400, Vadim Girlin wrote:
On 02/14/2013 02:42 PM, Christian K�nig wrote:
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
s
On 02/15/2013 06:31 PM, Tom Stellard wrote:
On Fri, Feb 15, 2013 at 03:00:24PM +0400, Vadim Girlin wrote:
On 02/14/2013 02:42 PM, Christian K�nig wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the f
On 02/15/2013 03:22 PM, Christian König wrote:
Am 15.02.2013 12:00, schrieb Vadim Girlin:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
s
On 02/16/2013 11:10 AM, Mathias � wrote:
Hi,
On Friday, February 15, 2013 15:00:24 Vadim Girlin wrote:
"LLVM backend is the future" is a pretty abstract argument. I prefer to
operate with real facts. After a year of LLVM backend development what
are the real benefits for the users
Overcautious stack reservation caused significant loss of performance.
Signed-off-by: Vadim Girlin
---
No regressions with quick-driver.tests on evergreen.
Adds more than 30% FPS for Unigine Heaven with default backend.
src/gallium/drivers/r600/r600_asm.c | 2 +-
1 file changed, 1 insertion
Please ignore this, there are some issues with this patch undetected by
piglit.
I suspect it's something similar to the hw bug discussed here recently:
http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg33361.html
On 02/18/2013 07:29 AM, Vadim Girlin wrote:
Overcautious
Overcautious stack reservation caused significant loss of performance.
v2: fix stack depth computation
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c| 4 +--
src/gallium/drivers/r600/r600_asm.h| 10 ++
src/gallium/drivers/r600/r600_shader.c | 64
On 02/18/2013 02:20 PM, Andy Furniss wrote:
Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more.
While
normally 3D clouds tear performance down to an unflyable stutter, with
your
branch I can fly in densly clouded conditions at usable framerates. I
can
v3: handle hw-specific cases
Signed-off-by: Vadim Girlin
---
cc: Andy Furniss
Hopefully this should work better on the non-evergreen chips
src/gallium/drivers/r600/r600_asm.c| 4 +-
src/gallium/drivers/r600/r600_asm.h| 29 +--
src/gallium/drivers/r600/r600_shader.c | 134
On 02/18/2013 02:20 PM, Andy Furniss wrote:
Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more.
While
normally 3D clouds tear performance down to an unflyable stutter, with
your
branch I can fly in densly clouded conditions at usable framerates. I
can
On 02/19/2013 04:54 PM, Andy Furniss wrote:
Vadim Girlin wrote:
Testing with rv790 with drm-fixes kernel not much works -
etqw runs but in a level 50% of screen is junk.
nexuiz menus total junk, didn't test further.
xonotic menus OK but gpu lock on starting timedemo.
vdpau mpeg2 d
On 02/19/2013 08:39 PM, Andy Furniss wrote:
Vadim Girlin wrote:
Could you please test glxgears and other simple mesa demos? It's easier
to spot the problems with small apps that don't use a lot of complex
shaders. If some of them don't work correctly, please send me
v4: implement exact computation taking into account wavefront size
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c| 44 +--
src/gallium/drivers/r600/r600_asm.h| 24 --
src/gallium/drivers/r600/r600_shader.c | 131 ++---
3
On 02/22/2013 04:23 AM, Alex Deucher wrote:
On Thu, Feb 21, 2013 at 6:52 PM, Vadim Girlin wrote:
v4: implement exact computation taking into account wavefront size
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c| 44 +--
src/gallium/drivers/r600/r600_asm.h
On 02/19/2013 08:39 PM, Andy Furniss wrote:
Vadim Girlin wrote:
Could you please test glxgears and other simple mesa demos? It's easier
to spot the problems with small apps that don't use a lot of complex
shaders. If some of them don't work correctly, please send me
On 02/22/2013 04:35 PM, Henri Verbeet wrote:
For what it's worth, I get a number of failures in the Wine d3d9 tests
on Cayman with this branch (9219c54b5c5a65c269124637a6e654eda4cdbb8e).
I haven't looked at why yet.
Unfortunately I have no cayman card to reproduce the issues. I can only
test
On 02/24/2013 11:01 PM, Henri Verbeet wrote:
On 24 February 2013 17:07, Vadim Girlin wrote:
If you'd like to help me with debugging the issues on cayman, then please
read the "regression debugging" section in the r600-sb branch notes [1] (or
possibly more up-to-date source
On 02/24/2013 11:25 PM, Vadim Girlin wrote:
On 02/24/2013 11:01 PM, Henri Verbeet wrote:
On 24 February 2013 17:07, Vadim Girlin wrote:
If you'd like to help me with debugging the issues on cayman, then
please
read the "regression debugging" section in the r600-sb branc
On 02/24/2013 11:01 PM, Henri Verbeet wrote:
On 24 February 2013 17:07, Vadim Girlin wrote:
If you'd like to help me with debugging the issues on cayman, then please
read the "regression debugging" section in the r600-sb branch notes [1] (or
possibly more up-to-date source
On 02/26/2013 10:49 PM, Benjamin Bellec wrote:
Hello,
Does your branch should works on R700 ?
I tested it on a RV770 but get many corruptions on Counter Strike Source
(native). I haven't tested anything else.
There are still some known problems with r7xx chips, hopefully they'll
be fixed soo
On 03/02/2013 05:15 AM, Sebastien Caty wrote:
On February 28, 2013 12:19:30 PM Vadim Girlin wrote:
Make sure that you have recent patches, some problems with R7xx chips
were fixed yesterday. Then please check if there are any regressions
with piglit tests (as compared to the piglit results with
On 03/02/2013 10:06 AM, Sebastien Caty wrote:
On March 1, 2013 06:24:01 PM Matt Turner wrote:
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty
wrote:
Trying to dig more and found out which shader is causing trouble but I
haven't found out how to run a specific test with piglit. Documentation
is
On 03/02/2013 10:06 AM, Sebastien Caty wrote:
On March 1, 2013 06:24:01 PM Matt Turner wrote:
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty
wrote:
Trying to dig more and found out which shader is causing trouble but I
haven't found out how to run a specific test with piglit. Documentation
is
On 03/26/2013 02:00 AM, Marek Olšák wrote:
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek wrote:
On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote:
Hi everyone, one image is better than a thousand words:
...
Hi,
I tried your patches and hit a few problems. As first, they do not appl
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_shader.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 29facf7..d4c9c03 100644
--- a/src/gallium/drivers
On 03/28/2013 01:01 PM, � wrote:
Am 27.03.2013 20:37, schrieb Vadim Girlin:
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_shader.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium
On 03/28/2013 09:47 PM, Vincent Lejeune wrote:
> [snip]
diff --git a/lib/Target/R600/R600RegisterInfo.td
b/lib/Target/R600/R600RegisterInfo.td
index ce5994c..3ee6623 100644
--- a/lib/Target/R600/R600RegisterInfo.td
+++ b/lib/Target/R600/R600RegisterInfo.td
@@ -43,6 +43,37 @@ foreach Index = 0-
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 out the stall was an infinite loop that was the result of broken
calculation in the shader function.
On 03/31/2013 01:01 PM, Martin Andersson wrote:
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
On 04/01/2013 12:00 AM, Vincent Lejeune wrote:
Hi Vadim,
Does this patch work ? (It's still not pushed)
It works for me on evergreen, but I'm not sure about other chip
generations. I wanted to ask somebody to test it, but the problem is
that the piglit coverage for this is not enough (e.g. i
On 03/31/2013 04:51 PM, Martin Andersson wrote:
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
update_max_depth function).
Vadim
----- Mail original -
De�: Vadim Girlin
�: Vincent Lejeune
Cc�: Alex Deucher ; "mesa-dev@lists.freedesktop.org"
Envoy� le : Dimanche 31 mars 2013 22h34
Objet�: Re: [Mesa-dev] [PATCH] r600g: don't reserve more stack space than
required
On 04/08/2013 02:03 PM, Marek Olšák wrote:
On Mon, Apr 8, 2013 at 11:29 AM, Michel Dänzer wrote:
On Fre, 2013-04-05 at 17:36 -0400, j.gli...@gmail.com wrote:
From: Jerome Glisse
Most test pass, issue are with border color and swizzle.
FWIW, those issues are there with non-compressed forma
de or the shader compiler or some other thing?
//Martin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>From 46456ca7ecfa3f0b107b1f9106d024f9f239a571 Mon Sep 17 00:00:00 2001
From: Vadi
for that shader) and maybe try adding
some constant, e.g. 4 to the bc->nstack in the r600_bytecode_build just
to be sure that we reserve enough of stack space, though I don't think
stack size is the cause of this issue.
Vadim
Marek
On Tue, Apr 9, 2013 at 11:30 PM, Vadim Girlin w
Hi,
It seems there is a bug in the compiler. The problem may be reproduced
with the following shader (complete shader_test file attached):
void main()
{
float f = 0.0;
while (true) {
f = 1.0;
break;
, OK
thread 3 (1, 1): expected = 27877, observed = 27877, OK
Please post the output if it fails on cayman.
Vadim
Marek
On Wed, Apr 10, 2013 at 8:46 AM, Vadim Girlin wrote:
On 04/10/2013 03:58 AM, Marek Olšák wrote:
Hi Vadim,
your patch does not fix the test.
Hmm, I'm out of ideas
ible), closer to what the
catalyst (shader analyzer) does. I'm not sure if it will help though,
and anyway we'll need stack operations in some cases, so I'm afraid this
won't fix the issue completely.
So far I have no other ideas.
Vadim
Marek
On Wed, Apr 10, 2013 at 11:42 PM,
nting any big changes, possibly there is
a better solution or at least a more clean workaround. In the worst case
we can return to your approach and improve it to handle other cases.
Vadim
//Martin
On Thu, Apr 11, 2013 at 5:31 PM, Vadim Girlin wrote:
On 04/11/2013 02:08 AM, Marek Olšák w
On 04/13/2013 09:54 PM, Martin Andersson wrote:
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 used
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't work as expected. Workaround this by replacing the ALU_PUSH_BEFORE
with a PUSH + ALU for nested
On 04/15/2013 10:52 AM, Martin Andersson wrote:
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
Signed-off-by: Vadim Girlin
---
src/gallium/include/state_tracker/st_api.h | 1 +
src/gallium/state_trackers/dri/common/dri_context.c | 2 ++
src/gallium/state_trackers/dri/common/dri_screen.c | 3 ++-
src/mesa/state_tracker/st_extensions.c | 3 +++
4 files changed, 8
On 04/15/2013 11:22 PM, Martin Andersson wrote:
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 PUS
Hi,
In the previous status update I said that the r600-sb branch is not
ready to be merged yet, but recently I've done some cleanups and
reworks, and though I haven't finished everything that I planned
initially, I think now it's in a better state and may be considered for
merging.
I'm inte
apps (Serious Sam 3).
This patch fixes it by restoring previous behavior.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=72369
Signed-off-by: Vadim Girlin
Cc: "10.0"
---
src/gallium/drivers/r600/sb/sb_bc_finalize.cpp | 16
1 file changed, 12 insertions(+), 4
On Mon, 2013-12-09 at 10:56 -0500, Tom Stellard wrote:
> On Sat, Dec 07, 2013 at 07:06:36PM +0400, Vadim Girlin wrote:
> > On evergreen we have to reserve 1 stack element in some additional cases
> > besides the ones mentioned in the docs, but stack size computation was
> > r
On Tue, 2014-01-07 at 21:49 +0100, Marek Olšák wrote:
> FYI, Evergreen has dedicated instructions for both MAD and FMA. FMA
> seems to be available on DX11 chips only.
FWIW, not all evergreen chips support FMA, only high-end chips that
support FP64 (I guess cypress only), according to the isa docs
On Wed, 2014-01-29 at 07:13 +1000, Dave Airlie wrote:
> >> 3) In si_init_gs_rings:
> >> - could you please use readable decimal numbers for specifying the
> >> sizes? Like 1024 * 1024 * ...
> > [...]
> >> - isn't 64 MB too many for a ring buffer?
> >
> > I can write the numbers any way you like. :)
On 04/19/2013 07:23 PM, Henri Verbeet wrote:
On 19 April 2013 16:48, Vadim Girlin wrote:
In the previous status update I said that the r600-sb branch is not ready to
be merged yet, but recently I've done some cleanups and reworks, and though
I haven't finished everything that
wanted
to support both default backend and llvm backend for increased testing
coverage and to be able to compare the efficiency of the algorithms in
my experiments etc.
Vadim
Cheers,
Christian.
Am 19.04.2013 16:48, schrieb Vadim Girlin:
Hi,
In the previous status update I said that the r60
On 04/19/2013 08:35 PM, Christian König wrote:
Hey Vadim,
Am 19.04.2013 18:18, schrieb Vadim Girlin:
[SNIP]
In theory, yes, some optimizations in this branch are typically used
on the earlier compilation stages, not on the target machine code. On
the other hand, there are some differences
m
There is a table for R600_DEBUG in r600_pipe.c and it even comes with
a help feature: R600_DEBUG=help
Marek
On Fri, Apr 19, 2013 at 4:48 PM, Vadim Girlin wrote:
Hi,
In the previous status update I said that the r600-sb branch is not ready to
be merged yet, but recently I've done s
On 04/20/2013 01:42 PM, Christian König wrote:
Am 19.04.2013 18:50, schrieb Vadim Girlin:
On 04/19/2013 08:35 PM, Christian König wrote:
Hey Vadim,
Am 19.04.2013 18:18, schrieb Vadim Girlin:
[SNIP]
In theory, yes, some optimizations in this branch are typically used
on the earlier
On 04/20/2013 03:38 PM, Christian König wrote:
Am 20.04.2013 13:12, schrieb Vadim Girlin:
On 04/20/2013 01:42 PM, Christian König wrote:
Am 19.04.2013 18:50, schrieb Vadim Girlin:
On 04/19/2013 08:35 PM, Christian König wrote:
Hey Vadim,
Am 19.04.2013 18:18, schrieb Vadim Girlin:
[SNIP
On 04/20/2013 07:05 PM, Henri Verbeet wrote:
On 19 April 2013 18:01, Vadim Girlin wrote:
The choice of C++ (unlike in my previous branch that used C) was mostly
driven by the fact that optimization algorithms usually deal with a lot of
different complex data structures, containers, etc, and C
s
Updated branch can be found here:
http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-sb-2
Vadim
Marek
On Sat, Apr 20, 2013 at 11:02 AM, Vadim Girlin wrote:
On 04/20/2013 03:11 AM, Marek Olšák wrote:
Please don't add any new environment variables and use R600_DEBUG
instead. The ot
This results in more clean shader code and may improve the quality of
optimized code produced by r600-sb due to eliminated false dependencies
in some cases.
Signed-off-by: Vadim Girlin
---
There are no piglit regressions with this patch on evergreen.
I consider this as a prerequisite for r600
ponents of
source register or modify the swizzles in such a way that there is no
unused components, e.g. xyzz with SHADOW2D/SAMPLE_C.
Vadim
Marek
On Sat, Apr 27, 2013 at 10:29 AM, Vadim Girlin wrote:
This results in more clean shader code and may improve the quality of
optimized code produc
This should fix build issues with GCC < 4.3
Signed-off-by: Vadim Girlin
---
cc: Lauri Kasanen
Lauri, please test to make sure that I didn't miss anything.
src/gallium/drivers/r600/r600_shader.c | 6 +++---
src/gallium/drivers/r600/sb/sb_bc.h | 4 ++--
src/gallium
On 05/01/2013 11:42 PM, Lauri Kasanen wrote:
Hi
Running "R600_DEBUG=sb glxgears" on a RV710 gives wrong output:
http://i40.tinypic.com/t7gx09.png
This is on current master, git-8eef6ad.
Let me know what you need to debug this.
Please send me the output with R600_DEBUG=sb,ps,vs
Vadim
___
On 05/01/2013 11:36 PM, Lauri Kasanen wrote:
Hi Vadim
Now that it built, I could test your optimizations in my own apps.
These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e).
In one of my private apps, using R600_DEBUG=sb caused regressions: FPS
went from 28 to 7, the SSAO shader gav
On 05/02/2013 11:06 AM, Michel Dänzer wrote:
On Don, 2013-05-02 at 05:45 +0200, Marek Olšák wrote:
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
b/src/gallium/drivers/radeon
Some inputs may be preloaded into predefined GPRs,
so we can't reallocate arrays with such inputs.
Fixes issues with webgl demo: http://oos.moxiecode.com/js_webgl/snake/
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_ra_coalesce.cpp | 14 +-
src/gallium/drivers
demo: http://madebyevan.com/webgl-water/
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_sched.cpp | 12 ++--
src/gallium/drivers/r600/sb/sb_sched.h | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_sched.cpp
b/src
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_ra_init.cpp | 25 +++--
src/gallium/drivers/r600/sb/sb_sched.cpp | 4
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_ra_init.cpp
b/src/gallium/drivers/r600
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_core.cpp | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_core.cpp
b/src/gallium/drivers/r600/sb/sb_core.cpp
index 9f81ed4..b919fa4 100644
--- a/src/gallium/drivers/r600/sb/sb_core.cpp
+++ b/src
ek
On Thu, May 2, 2013 at 5:04 PM, Vadim Girlin wrote:
On 05/02/2013 11:06 AM, Michel Dänzer wrote:
On Don, 2013-05-02 at 05:45 +0200, Marek Olšák wrote:
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/galli
On 05/02/2013 06:34 PM, Lauri Kasanen wrote:
On Thu, 02 May 2013 00:45:13 +0400
Vadim Girlin wrote:
On 05/01/2013 11:36 PM, Lauri Kasanen wrote:
Now that it built, I could test your optimizations in my own apps.
These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e).
In one of my
to use new
disassembler in r600g/sb for shader dumps when shader optimization
is not enabled.
If shader optimization is enabled, new disassembler is used by default.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c| 13 +++--
src/gallium/drivers/r600/r600_pipe.c | 1 +
s
On 05/03/2013 03:10 PM, Lauri Kasanen wrote:
Assigning a struct only copies the members - any padding is left as is.
Thus this code:
struct foo;
foo = bar;
leaves the padding of foo intact, ie uninitialized random garbage.
This patch fixes constant shader recompiles by initializing the struct
This patch results in lockups with Heaven on juniper for me.
Vadim
On 04/26/2013 09:21 PM, Tom Stellard wrote:
From: Tom Stellard
We are already emitting a EVENT_TYPE_CACHE_FLUSH_AND_INV_EVENT packet
when this flush flag is set, so flushing the dest caches with a
SURFACE_SYNC should not be n
1 - 100 of 392 matches
Mail list logo
