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
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 <<
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 <vadimgir...@gmail.com>
Fixes: 2cd76917934 ("r600g/sb: initial commit of the optimizing sha
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 vadimgir...@gmail.com 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
On 12/12/2014 05:28 PM, Alex Deucher wrote:
On Wed, Dec 10, 2014 at 6:50 AM, Vadim Girlin vadimgir...@gmail.com 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 vadimgir...@gmail.com wrote:
On 12/06
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 see
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 vadimgir...@gmail.com 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
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 too interested
On 12/09/2014 05:18 AM, Dave Airlie wrote:
On 8 December 2014 at 20:41, Vadim Girlin vadimgir...@gmail.com 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
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
On 12/06/2014 07:50 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin vadimgir...@gmail.com 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
On 12/06/2014 08:01 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:56 PM, Vadim Girlin vadimgir...@gmail.com wrote:
On 12/06/2014 07:50 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin vadimgir...@gmail.com
wrote:
I suspect we should rather get rid of such loops somehow
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. :) But I just
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
recently reimplemented exactly
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 vadimgir...@gmail.com
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/sb/sb_bc_finalize.cpp | 16
---
cc: Andreas Boll andreas.boll@gmail.com
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.
On 10/19/2013 06:18 AM, Vinson Lee wrote:
Fixes Uninitialized scalar field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
Reviewed-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/sb/sb_shader.cpp | 3 ++-
1 file changed, 2 insertions(+), 1
pass.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=70088
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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.h
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 vadimgir...@gmail.com
---
src/gallium
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 vadimgir...@gmail.com
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 alpha_ref
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 variant
On 09/28/2013 10:08 AM, Vinson Lee wrote:
Fixes Deference before null check defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
Reviewed-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/sb/sb_ra_init.cpp | 3 ++-
1 file changed, 2 insertions
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.08.2013 02:07, schrieb Vadim Girlin:
On 08/28/2013 02:59 AM
We need to export at least one color if the shader writes it,
even when nr_cbufs==0.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
Tested on evergreen with multiple combinations of backends - no regressions,
fixes some tests:
default- fixes fb-alphatest-nocolor and fb_alphatest
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 vadimgir...@gmail.com
---
Tested on evergreen with multiple combinations of backends - no regressions,
fixes some tests:
default
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 at least one color if the shader writes it,
even when
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.
I
the driver, or am I missing something?
Vadim
Marek
On Tue, Aug 27, 2013 at 11:52 PM, Vadim Girlin vadimgir...@gmail.com 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 likes to compile shader variants
backend uses the same logic.
Vadim
Marek
On Sat, Aug 24, 2013 at 3:30 AM, Vadim Girlin vadimgir...@gmail.com 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
with 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 vadimgir
it (especially with SB
which tends to reorder the exports).
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
On 08/19/2013 01:35 AM, Vinson Lee wrote:
Fixes Uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/r600/sb/sb_ir.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On 08/19/2013 11:50 AM, Vinson Lee wrote:
Silences Uninitialized pointer field defects reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
Reviewed-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/sb/sb_ir.h | 6 +++---
src/gallium/drivers/r600
-by: Vadim Girlin vadimgir...@gmail.com
Cc: 9.2 mesa-sta...@lists.freedesktop.org
---
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
)
- 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 vadimgir...@gmail.com
___
mesa-dev mailing list
mesa-dev
On 06/28/2013 01:31 AM, Tom Stellard wrote:
From: Chih-Wei Huang cwhu...@android-x86.org
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 ++--
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
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 vadimgir...@gmail.com
---
src/gallium/drivers/r600
precision than guaranteed by GL,
'sbsafemath' option in R600_DEBUG allows to disable them.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
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 vadimgir...@gmail.com
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 vadimgir...@gmail.com
---
src/gallium/drivers/r600/r600_isa.c | 19 ++
src/gallium/drivers/r600/r600_isa.h | 132
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
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 vadimgir...@gmail.com wrote:
Reduced test app
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 vadimgir...@gmail.com
---
src/gallium/drivers/r600/sb/sb_bc.h
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
with 64-bit port, looks like detection
logic was changed there.
Vadim
On Thu, May 9, 2013 at 4:15 AM, Vadim Girlin vadimgir...@gmail.com 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
-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
at compile time and
also replace it with MOV.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
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 vadimgir...@gmail.com
---
src/gallium/drivers/r600/r600_asm.c| 13 +++--
src/gallium/drivers/r600/r600_pipe.c
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
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 thomas.stell...@amd.com
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
On 05/03/2013 05:36 PM, Alex Deucher wrote:
On Fri, May 3, 2013 at 9:30 AM, Vadim Girlin vadimgir...@gmail.com 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
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
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 vadimgir...@gmail.com
---
src/gallium/drivers/r600/sb/sb_ra_coalesce.cpp | 14 +-
src
demo: http://madebyevan.com/webgl-water/
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
, May 2, 2013 at 5:04 PM, Vadim Girlin vadimgir...@gmail.com 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
On 05/02/2013 06:34 PM, Lauri Kasanen wrote:
On Thu, 02 May 2013 00:45:13 +0400
Vadim Girlin vadimgir...@gmail.com 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
This should fix build issues with GCC 4.3
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
cc: Lauri Kasanen c...@gmx.com
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
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
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 vadimgir...@gmail.com
---
There are no piglit regressions with this patch on evergreen.
I consider
all components 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 vadimgir...@gmail.com wrote:
This results in more clean shader code and may improve
:
http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-sb-2
Vadim
Marek
On Sat, Apr 20, 2013 at 11:02 AM, Vadim Girlin vadimgir...@gmail.com 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 other environment
and it even comes with
a help feature: R600_DEBUG=help
Marek
On Fri, Apr 19, 2013 at 4:48 PM, Vadim Girlin vadimgir...@gmail.com 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 some cleanups and reworks, and though
I
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 vadimgir...@gmail.com 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
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
On 04/19/2013 07:23 PM, Henri Verbeet wrote:
On 19 April 2013 16:48, Vadim Girlin vadimgir...@gmail.com 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
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 r600-sb branch is not
ready to be merged yet, but recently I've
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
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
On 04/15/2013 10:52 AM, Martin Andersson wrote:
On Mon, Apr 15, 2013 at 1:09 AM, Vadim Girlin vadimgir...@gmail.com 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
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
On 04/13/2013 09:54 PM, Martin Andersson wrote:
On Sat, Apr 13, 2013 at 4:23 AM, Vadim Girlin vadimgir...@gmail.com 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
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
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 vadimgir...@gmail.com wrote:
On 04/11/2013 02:08 AM, Marek Olšák wrote:
Here's the output
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, Vadim Girlin vadimgir...@gmail.comwrote
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 vadimgir...@gmail.com wrote:
On 04/09/2013 10
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;
): 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 vadimgir...@gmail.com 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
: Vadim Girlin vadimgir...@gmail.com
Date: Wed, 10 Apr 2013 01:20:19 +0400
Subject: [PATCH] r600g: use ALU EXECUTE_MASK_OP on cayman instead of
LOOP_BREAK/CONTINUE
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/r600_asm.c| 14 --
src/gallium/drivers
On 04/08/2013 02:03 PM, Marek Olšák wrote:
On Mon, Apr 8, 2013 at 11:29 AM, Michel Dänzer mic...@daenzer.net wrote:
On Fre, 2013-04-05 at 17:36 -0400, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Most test pass, issue are with border color and swizzle.
FWIW, those
- Mail original -
De�: Vadim Girlin vadimgir...@gmail.com
�: Vincent Lejeune v...@ovi.com
Cc�: Alex Deucher alexdeuc...@gmail.com; mesa-dev@lists.freedesktop.org
mesa-dev@lists.freedesktop.org
Envoy� le : Dimanche 31 mars 2013 22h34
Objet�: Re: [Mesa-dev] [PATCH] r600g: don't reserve more
On 03/31/2013 01:01 PM, Martin Andersson wrote:
On Sun, Mar 31, 2013 at 1:08 AM, Vadim Girlin vadimgir...@gmail.com 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
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.
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
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
On 03/28/2013 01:01 PM, � wrote:
Am 27.03.2013 20:37, schrieb Vadim Girlin:
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/r600_shader.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600
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 =
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
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
On 03/26/2013 02:00 AM, Marek Olšák wrote:
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com 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,
1 - 100 of 368 matches
Mail list logo
