On 10/16/2017 10:06 PM, Gert Wollny wrote:
It is possible that the optimizer ends up in an infinite loop in
post_scheduler::schedule_alu(), because post_scheduler::prepare_alu_group()
does not find a proper scheduling. This can be deducted from
pending.count() being larger than zero and not getti
On 09/13/2017 11:16 AM, Gert Wollny wrote:
Am Dienstag, den 12.09.2017, 23:44 +0200 schrieb Glenn Kennard:
Vadim is correct, the fix is to extend the check in the if case above
to also exclude TGSI_FILE_SYSTEM_VALUE, and keep the assert in place.
ie:
if (pshader->indirect_files & ~((1 << TG
On 09/12/2017 12:49 PM, Gert Wollny wrote:
Am Dienstag, den 12.09.2017, 09:56 +0300 schrieb Vadim Girlin:
On 09/11/2017 07:09 PM, Emil Velikov wrote:
Anyway, if num_arrays is 0 there, I suspect it can be a result of
some other issue. At the very least it looks like a potential
performance
is wrong
with the indirect_files bits?
I'm adding Glenn to cc too, AFAIU he has added some related features
since then, so possibly he knows better.
Cc: Vadim Girlin
Fixes: 2cd76917934 ("r600g/sb: initial commit of the optimizing shader backend")
-Emil
___
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 12/16/2014 05:44 AM, Dave Airlie wrote:
On 16 December 2014 at 08:59, Vadim Girlin wrote:
On 12/16/2014 01:30 AM, Dave Airlie wrote:
New patch is attached, the only difference is in the sb_sched.cpp (it
disables copy coalescing for some "unsafe" cases, so it may leave more
On 12/16/2014 01:30 AM, Dave Airlie wrote:
New patch is attached, the only difference is in the sb_sched.cpp (it
disables copy coalescing for some "unsafe" cases, so it may leave more
MOVs
than previously, but I don't think there will be any noticeable effect on
performance).
So far I don't se
On 12/12/2014 05:28 PM, Alex Deucher wrote:
On Wed, Dec 10, 2014 at 6:50 AM, Vadim Girlin wrote:
On 12/09/2014 07:39 AM, Vadim Girlin wrote:
On 12/09/2014 05:18 AM, Dave Airlie wrote:
On 8 December 2014 at 20:41, Vadim Girlin wrote:
On 12/06/2014 07:13 AM, Vadim Girlin wrote:
On 12
On 12/09/2014 07:39 AM, Vadim Girlin wrote:
On 12/09/2014 05:18 AM, Dave Airlie wrote:
On 8 December 2014 at 20:41, Vadim Girlin wrote:
On 12/06/2014 07:13 AM, Vadim Girlin wrote:
On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a
On 12/09/2014 05:18 AM, Dave Airlie wrote:
On 8 December 2014 at 20:41, Vadim Girlin wrote:
On 12/06/2014 07:13 AM, Vadim Girlin wrote:
On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a bug in sb for a couple of
weeks now triggered b
On 12/06/2014 07:13 AM, Vadim Girlin wrote:
On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a bug in sb for a couple of
weeks now triggered by a change in how GLSL generates switch
statements.
I understand you probably aren't to
On 12/06/2014 08:01 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:56 PM, Vadim Girlin wrote:
On 12/06/2014 07:50 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin
wrote:
I suspect we should rather get rid of such loops somehow, i.e. convert to
something else, the loop
On 12/06/2014 07:50 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin wrote:
I suspect we should rather get rid of such loops somehow, i.e. convert to
something else, the loop that never repeats is not really a loop anyway.
AFAICS "continue" is not supported
On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a bug in sb for a couple of
weeks now triggered by a change in how GLSL generates switch
statements.
I understand you probably aren't too interested in r600g but I believe
I'm hitting a design level pr
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 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 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
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
---
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
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
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.
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
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
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
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 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 -
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.
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
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
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
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:
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
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
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
(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),
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
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 ---
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
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/
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
_
On 07/13/2013 06:21 AM, Vinson Lee wrote:
Fixes "Uninitialized scalar field" reported by Coverity.
Pushed, thanks.
Vadim
Signed-off-by: Vinson Lee
---
src/gallium/drivers/r600/sb/sb_shader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/s
On 07/01/2013 05:53 AM, Marek Olšák wrote:
The winsys should do this, because it measures how much time we spend
in buffer_map doing synchronization, which can be viewed with the gallium
HUD.
---
src/gallium/drivers/r600/r600_pipe.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
On 06/28/2013 01:31 AM, Tom Stellard wrote:
From: Chih-Wei Huang
Add the sb CXX files to the Android Makefile and also stop using some
c++11 features.
---
src/gallium/drivers/r600/Android.mk | 5 +++--
src/gallium/drivers/r600/sb/sb_bc.h | 4 ++--
src/gallium/drivers/r600/sb
igher precision than guaranteed by GL,
'sbsafemath' option in R600_DEBUG allows to disable them.
v2 - always set proper src vector size for transformed instructions
- check for clamp modifier in the expr_handler::fold_assoc
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/
On 06/05/2013 12:01 AM, Grigori Goronzy wrote:
On 31.05.2013 14:37, Vadim Girlin wrote:
There are no regressions on evergreen with piglit tests or any
other apps that I tested, with and without llvm backend.
(Issue with Unigine Heaven that I mentioned on #dri-devel
yesterday was in fact caused
igher precision than guaranteed by GL,
'sbsafemath' option in R600_DEBUG allows to disable them.
Signed-off-by: Vadim Girlin
---
There are no regressions on evergreen with piglit tests or any
other apps that I tested, with and without llvm backend.
(Issue with Unigine Heaven that I mentione
On 05/30/2013 05:48 AM, Tom Stellard wrote:
On Mon, May 27, 2013 at 02:15:21AM +0400, Vadim Girlin wrote:
This will help to improve dumps of the compute shaders,
also it will be required for complete handling of RAT instructions in sb.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_bc.h | 12 +++-
src/gallium/drivers/r600/sb/sb_bc_builder.cpp | 2 +-
src/gallium/drivers/r600/sb/sb_bc_decoder.cpp | 5 -
src/gallium/drivers/r600/sb/sb_bc_dump.cpp| 13 +++--
4 files changed, 27
This will help to improve dumps of the compute shaders,
also it will be required for complete handling of RAT instructions in sb.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_isa.c | 19 ++
src/gallium/drivers/r600/r600_isa.h | 132
2
is 0 here and what is the best way
to fix it, possibly in fact this is a consequence of some problem in
r600g, not in the libdrm. Though probably libdrm should handle it more
gracefully anyway.
Vadim
On Mon, May 20, 2013 at 4:11 AM, Vadim Girlin wrote:
Reduced test app attached and bel
Reduced test app attached and below is gdb backtrace. I suspect
something is not initialized properly but I'm not very familiar with
this code.
Vadim
Program received signal SIGFPE, Arithmetic exception.
0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0,
surf=0x88d848, level=0x88de
Parsing and ir construction is required for optimization only,
it's unnecessary if we only need to print shader dump.
This should make new disassembler more tolerant to any new
features in the bytecode.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_bc.h
7;t see this message with 64-bit port, looks like detection
logic was changed there.
Vadim
On Thu, May 9, 2013 at 4:15 AM, Vadim Girlin wrote:
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.
G
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
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_bc_parser.cpp | 3 ++-
src/gallium/drivers/r600/sb/sb_shader.cpp| 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
b/src/gallium/drivers/r600/sb/sb_bc_parser.cpp
he condition at compile time and
also replace it with MOV.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_expr.cpp | 84 +++--
src/gallium/drivers/r600/sb/sb_expr.h | 2 +
2 files changed, 81 insertions(+), 5 deletions(-)
diff --git a/src/gallium/
-off-by: Vadim Girlin
---
src/gallium/drivers/r600/sb/sb_sched.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_sched.cpp
b/src/gallium/drivers/r600/sb/sb_sched.cpp
index b21b342..d0045ce 100644
--- a/src/gallium/drivers/r600/sb
On 05/03/2013 05:36 PM, Alex Deucher wrote:
On Fri, May 3, 2013 at 9:30 AM, Vadim Girlin wrote:
This patch results in lockups with Heaven on juniper for me.
Does dropping the surface_sync packet completely help? We shouldn't
need a surface_sync packet after a CACHE_FLUSH_AND_INV_
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
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
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/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
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
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
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
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
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
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
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/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
___
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
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 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
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
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
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 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
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/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
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 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
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
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
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 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
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/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
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
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,
, 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
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;
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
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
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
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 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
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 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 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/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-
1 - 100 of 392 matches
Mail list logo
