Re: [Mesa-dev] [PATCH] r600g/llvm: don't export more colors than the number of CBs
Am 24.08.2013 03:30, schrieb Vadim Girlin:
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:
EXPORT PIXEL 0 R0.xyzw VPM
EXPORT PIXEL 61R1.x___ VPM
EXPORT_DONEPIXEL 61R0._x__ VPM EOP
AFAIU with zero color buffers no memory is reserved for colors in the export
ring and all exports in this example actually write to the same location.
The code above still works fine in this particular case, because correct
values are written last, but reordering can break it (especially with SB
which tends to reorder the exports).
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
I briefly remember that we needed at least one color export otherwise
the GPU might hang, but I'm not 100% sure of that.
Marek and Alex should probably also take a look on this before we commit it.
Christian.
---
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), needs testing on
pre-evergreen GPUs.
src/gallium/drivers/r600/r600_llvm.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 03a68e4..d2f4aff 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -333,8 +333,8 @@ static void llvm_emit_epilogue(struct lp_build_tgsi_context
* bld_base)
} else if (ctx-type == TGSI_PROCESSOR_FRAGMENT) {
switch (ctx-r600_outputs[i].name) {
case TGSI_SEMANTIC_COLOR:
- has_color = true;
if ( color_count ctx-color_buffer_count) {
+ has_color = true;
LLVMValueRef args[3];
args[0] = output;
if (ctx-fs_color_all) {
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index fb766c4..85f8469 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1130,7 +1130,7 @@ static int r600_shader_from_tgsi(struct r600_screen
*rscreen,
radeon_llvm_ctx.face_gpr = ctx.face_gpr;
radeon_llvm_ctx.r600_inputs = ctx.shader-input;
radeon_llvm_ctx.r600_outputs = ctx.shader-output;
- radeon_llvm_ctx.color_buffer_count = MAX2(key.nr_cbufs , 1);
+ radeon_llvm_ctx.color_buffer_count = key.nr_cbufs;
radeon_llvm_ctx.chip_class = ctx.bc-chip_class;
radeon_llvm_ctx.fs_color_all = shader-fs_write_all
(rscreen-chip_class = EVERGREEN);
radeon_llvm_ctx.stream_outputs = so;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/llvm: don't export more colors than the number of CBs
On 24.08.2013 11:44, Christian König wrote:
Am 24.08.2013 03:30, schrieb Vadim Girlin:
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:
EXPORT PIXEL 0 R0.xyzw VPM
EXPORT PIXEL 61R1.x___ VPM
EXPORT_DONEPIXEL 61R0._x__ VPM EOP
AFAIU with zero color buffers no memory is reserved for colors in the
export
ring and all exports in this example actually write to the same
location.
The code above still works fine in this particular case, because correct
values are written last, but reordering can break it (especially with SB
which tends to reorder the exports).
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
I briefly remember that we needed at least one color export otherwise
the GPU might hang, but I'm not 100% sure of that.
If there are no color buffers bound but the original shader writes color
0, you still have to export it to keep the alpha test working ...
Marek and Alex should probably also take a look on this before we
commit it.
Christian.
---
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), needs testing on
pre-evergreen GPUs.
src/gallium/drivers/r600/r600_llvm.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 03a68e4..d2f4aff 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -333,8 +333,8 @@ static void llvm_emit_epilogue(struct
lp_build_tgsi_context * bld_base)
} else if (ctx-type == TGSI_PROCESSOR_FRAGMENT) {
switch (ctx-r600_outputs[i].name) {
case TGSI_SEMANTIC_COLOR:
-has_color = true;
if ( color_count ctx-color_buffer_count) {
+has_color = true;
LLVMValueRef args[3];
args[0] = output;
if (ctx-fs_color_all) {
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index fb766c4..85f8469 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1130,7 +1130,7 @@ static int r600_shader_from_tgsi(struct
r600_screen *rscreen,
radeon_llvm_ctx.face_gpr = ctx.face_gpr;
radeon_llvm_ctx.r600_inputs = ctx.shader-input;
radeon_llvm_ctx.r600_outputs = ctx.shader-output;
-radeon_llvm_ctx.color_buffer_count = MAX2(key.nr_cbufs , 1);
+radeon_llvm_ctx.color_buffer_count = key.nr_cbufs;
radeon_llvm_ctx.chip_class = ctx.bc-chip_class;
radeon_llvm_ctx.fs_color_all = shader-fs_write_all
(rscreen-chip_class = EVERGREEN);
radeon_llvm_ctx.stream_outputs = so;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/llvm: don't export more colors than the number of CBs
Like Christoph said, COLOR0 (if available) must always be exported for
alpha test.
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:
EXPORT PIXEL 0 R0.xyzw VPM
EXPORT PIXEL 61R1.x___ VPM
EXPORT_DONEPIXEL 61R0._x__ VPM EOP
AFAIU with zero color buffers no memory is reserved for colors in the export
ring and all exports in this example actually write to the same location.
The code above still works fine in this particular case, because correct
values are written last, but reordering can break 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 other hw), needs testing on
pre-evergreen GPUs.
src/gallium/drivers/r600/r600_llvm.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 03a68e4..d2f4aff 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -333,8 +333,8 @@ static void llvm_emit_epilogue(struct
lp_build_tgsi_context * bld_base)
} else if (ctx-type == TGSI_PROCESSOR_FRAGMENT) {
switch (ctx-r600_outputs[i].name) {
case TGSI_SEMANTIC_COLOR:
- has_color = true;
if ( color_count ctx-color_buffer_count) {
+ has_color = true;
LLVMValueRef args[3];
args[0] = output;
if (ctx-fs_color_all) {
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index fb766c4..85f8469 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1130,7 +1130,7 @@ static int r600_shader_from_tgsi(struct r600_screen
*rscreen,
radeon_llvm_ctx.face_gpr = ctx.face_gpr;
radeon_llvm_ctx.r600_inputs = ctx.shader-input;
radeon_llvm_ctx.r600_outputs = ctx.shader-output;
- radeon_llvm_ctx.color_buffer_count = MAX2(key.nr_cbufs , 1);
+ radeon_llvm_ctx.color_buffer_count = key.nr_cbufs;
radeon_llvm_ctx.chip_class = ctx.bc-chip_class;
radeon_llvm_ctx.fs_color_all = shader-fs_write_all
(rscreen-chip_class = EVERGREEN);
radeon_llvm_ctx.stream_outputs = so;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 68504] New: 9.2-rc1 clover fails to build on ppc: cannot convert 'bool' to '__vector(4) __bool int' in return
https://bugs.freedesktop.org/show_bug.cgi?id=68504 Priority: medium Bug ID: 68504 Assignee: mesa-dev@lists.freedesktop.org Summary: 9.2-rc1 clover fails to build on ppc: cannot convert 'bool' to '__vector(4) __bool int' in return Severity: normal Classification: Unclassified OS: All Reporter: chith...@gentoo.org Hardware: Other Status: NEW Version: 9.2 Component: Other Product: Mesa Created attachment 84560 -- https://bugs.freedesktop.org/attachment.cgi?id=84560action=edit compressed build.log Using gcc-4.7.3, llvm-3.3, clang-3.3 on Gentoo PPC ./configure --prefix=/usr --build=powerpc-unknown-linux-gnu --host=powerpc-unknown-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-silent-rules --disable-dependency-tracking --enable-dri --enable-glx --enable-shared-glapi --enable-texture-float --disable-debug --enable-egl --disable-gbm --disable-gles1 --disable-gles2 --enable-glx-tls --disable-osmesa --enable-asm --disable-xa --disable-xorg --with-dri-drivers=,swrast,radeon,r200 --with-gallium-drivers=,swrast,r300,r600 PYTHON2=/usr/bin/python2.7 --with-egl-platforms=x11 --enable-gallium-egl --enable-gallium-llvm --disable-openvg --enable-r600-llvm-compiler --disable-vdpau --disable-xvmc --enable-opencl --with-opencl-libdir=/usr/lib/OpenCL/vendors/mesa --with-clang-libdir=/usr/lib Causes the build to fail in clover: In file included from ./core/device.hpp:29:0, from core/device.cpp:23: ./core/base.hpp: In member function '__vector(4) __bool int clover::ref_counter::release()': ./core/base.hpp:73:36: error: cannot convert 'bool' to '__vector(4) __bool int' in return ./core/base.hpp: At global scope: ./core/base.hpp:205:26: error: expected type-specifier ./core/base.hpp:205:26: error: expected '' -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 68504] 9.2-rc1 clover fails to build on ppc: cannot convert 'bool' to '__vector(4) __bool int' in return
https://bugs.freedesktop.org/show_bug.cgi?id=68504 Chí-Thanh Christopher Nguyễn chith...@gentoo.org changed: What|Removed |Added Attachment #84560|text/plain |application/x-xz mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/llvm: don't export more colors than the number of CBs
On 08/24/2013 02:31 PM, Marek Olšák wrote:
Like Christoph said, COLOR0 (if available) must always be exported for
alpha test.
Are there any piglit tests for that? I didn't see any regressions with
this patch (at least on evergreen), possibly I messed up the testing
somehow. Also I think old 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:
EXPORT PIXEL 0 R0.xyzw VPM
EXPORT PIXEL 61R1.x___ VPM
EXPORT_DONEPIXEL 61R0._x__ VPM EOP
AFAIU with zero color buffers no memory is reserved for colors in the export
ring and all exports in this example actually write to the same location.
The code above still works fine in this particular case, because correct
values are written last, but reordering can break 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 other hw), needs testing on
pre-evergreen GPUs.
src/gallium/drivers/r600/r600_llvm.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 03a68e4..d2f4aff 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -333,8 +333,8 @@ static void llvm_emit_epilogue(struct lp_build_tgsi_context
* bld_base)
} else if (ctx-type == TGSI_PROCESSOR_FRAGMENT) {
switch (ctx-r600_outputs[i].name) {
case TGSI_SEMANTIC_COLOR:
- has_color = true;
if ( color_count ctx-color_buffer_count) {
+ has_color = true;
LLVMValueRef args[3];
args[0] = output;
if (ctx-fs_color_all) {
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index fb766c4..85f8469 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1130,7 +1130,7 @@ static int r600_shader_from_tgsi(struct r600_screen
*rscreen,
radeon_llvm_ctx.face_gpr = ctx.face_gpr;
radeon_llvm_ctx.r600_inputs = ctx.shader-input;
radeon_llvm_ctx.r600_outputs = ctx.shader-output;
- radeon_llvm_ctx.color_buffer_count = MAX2(key.nr_cbufs , 1);
+ radeon_llvm_ctx.color_buffer_count = key.nr_cbufs;
radeon_llvm_ctx.chip_class = ctx.bc-chip_class;
radeon_llvm_ctx.fs_color_all = shader-fs_write_all
(rscreen-chip_class = EVERGREEN);
radeon_llvm_ctx.stream_outputs = so;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nouveau/video: avoid overwriting base codec init with template
On Sat, Aug 24, 2013 at 8:36 AM, Martin Peres martin.pe...@labri.fr wrote: On 24/08/2013 11:38, Christian König wrote: Am 24.08.2013 06:50, schrieb Ilia Mirkin: Commit 53e20b8b introduced the use of a template to initialize some common fields. Move this copying of fields to before the common vp3 fields are initialized. Reported-by: Martin Peres martin.pe...@labri.fr Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Sorry, that some fields are initialized earlier wasn't obviously to me. It wasn't obvious to me either at first -- I saw the changes and they looked fine :) Patch is: Reviewed-by: Christian König christian.koe...@amd.com Thanks! I don't have commit access, so I'd appreciate it if you could check it in. You can pull it from https://github.com/imirkin/mesa bugfixes if you prefer to use git. This patch should also be pushed in 9.2 before its release. I don't think that the use the template patches went into 9.2, so this patch is also not appropriate for 9.2 (it wouldn't apply). -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/llvm: don't export more colors than the number of CBs
On Sat, Aug 24, 2013 at 5:44 AM, Christian König
deathsim...@vodafone.de wrote:
Am 24.08.2013 03:30, schrieb Vadim Girlin:
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:
EXPORT PIXEL 0 R0.xyzw VPM
EXPORT PIXEL 61R1.x___ VPM
EXPORT_DONEPIXEL 61R0._x__ VPM EOP
AFAIU with zero color buffers no memory is reserved for colors in the
export
ring and all exports in this example actually write to the same location.
The code above still works fine in this particular case, because correct
values are written last, but reordering can break it (especially with SB
which tends to reorder the exports).
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
I briefly remember that we needed at least one color export otherwise the
GPU might hang, but I'm not 100% sure of that.
Marek and Alex should probably also take a look on this before we commit it.
I think the exports are dependent on the setting of CB_COLOR_CONTROL.MODE.
Alex
Christian.
---
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), needs testing on
pre-evergreen GPUs.
src/gallium/drivers/r600/r600_llvm.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 03a68e4..d2f4aff 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -333,8 +333,8 @@ static void llvm_emit_epilogue(struct
lp_build_tgsi_context * bld_base)
} else if (ctx-type == TGSI_PROCESSOR_FRAGMENT) {
switch (ctx-r600_outputs[i].name) {
case TGSI_SEMANTIC_COLOR:
- has_color = true;
if ( color_count
ctx-color_buffer_count) {
+ has_color = true;
LLVMValueRef args[3];
args[0] = output;
if (ctx-fs_color_all) {
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index fb766c4..85f8469 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1130,7 +1130,7 @@ static int r600_shader_from_tgsi(struct r600_screen
*rscreen,
radeon_llvm_ctx.face_gpr = ctx.face_gpr;
radeon_llvm_ctx.r600_inputs = ctx.shader-input;
radeon_llvm_ctx.r600_outputs = ctx.shader-output;
- radeon_llvm_ctx.color_buffer_count = MAX2(key.nr_cbufs ,
1);
+ radeon_llvm_ctx.color_buffer_count = key.nr_cbufs;
radeon_llvm_ctx.chip_class = ctx.bc-chip_class;
radeon_llvm_ctx.fs_color_all = shader-fs_write_all
(rscreen-chip_class = EVERGREEN);
radeon_llvm_ctx.stream_outputs = so;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/llvm: don't export more colors than the number of CBs
See piglit/fbo-alphatest-nocolor.
Marek
On Sat, Aug 24, 2013 at 3:12 PM, Vadim Girlin vadimgir...@gmail.com wrote:
On 08/24/2013 02:31 PM, Marek Olšák wrote:
Like Christoph said, COLOR0 (if available) must always be exported for
alpha test.
Are there any piglit tests for that? I didn't see any regressions with this
patch (at least on evergreen), possibly I messed up the testing somehow.
Also I think old 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:
EXPORT PIXEL 0 R0.xyzw VPM
EXPORT PIXEL 61R1.x___ VPM
EXPORT_DONEPIXEL 61R0._x__ VPM EOP
AFAIU with zero color buffers no memory is reserved for colors in the
export
ring and all exports in this example actually write to the same location.
The code above still works fine in this particular case, because correct
values are written last, but reordering can break 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 other hw), needs testing on
pre-evergreen GPUs.
src/gallium/drivers/r600/r600_llvm.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 03a68e4..d2f4aff 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -333,8 +333,8 @@ static void llvm_emit_epilogue(struct
lp_build_tgsi_context * bld_base)
} else if (ctx-type == TGSI_PROCESSOR_FRAGMENT) {
switch (ctx-r600_outputs[i].name) {
case TGSI_SEMANTIC_COLOR:
- has_color = true;
if ( color_count
ctx-color_buffer_count) {
+ has_color = true;
LLVMValueRef args[3];
args[0] = output;
if (ctx-fs_color_all) {
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index fb766c4..85f8469 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1130,7 +1130,7 @@ static int r600_shader_from_tgsi(struct r600_screen
*rscreen,
radeon_llvm_ctx.face_gpr = ctx.face_gpr;
radeon_llvm_ctx.r600_inputs = ctx.shader-input;
radeon_llvm_ctx.r600_outputs = ctx.shader-output;
- radeon_llvm_ctx.color_buffer_count = MAX2(key.nr_cbufs ,
1);
+ radeon_llvm_ctx.color_buffer_count = key.nr_cbufs;
radeon_llvm_ctx.chip_class = ctx.bc-chip_class;
radeon_llvm_ctx.fs_color_all = shader-fs_write_all
(rscreen-chip_class = EVERGREEN);
radeon_llvm_ctx.stream_outputs = so;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-announce] Mesa 9.2 release candidate 2
On 2013-08-23 09:48 +0200, Andreas Boll wrote: 2013/8/23 Ian Romanick i...@freedesktop.org: Mesa 9.2 release candidate 2 is now available for testing. The tag in the GIT repository for Mesa 9.2-rc2 is 'mesa-9.2-rc2'. Mesa 9.2 release candidate 2 is available for download at ftp://freedesktop.org/pub/mesa/9.2/ md5sums: 4cde5bbe49658431951e6f51814a9c05 MesaLib-9.2.0-rc2.tar.gz 1b06e7a85fed9b571764affaea51e3e6 MesaLib-9.2.0-rc2.tar.bz2 4a528e491c76e387ba9c6d77e690e4df MesaLib-9.2.0-rc2.zip I have verified building from the .tar.bz2 file by doing: tar -xjf Mesa-9.2.0-rc1.tar.bz2 cd Mesa-9.2.0-rc1 ./configure --enable-gallium-llvm --with-llvm-shared-libs make -j6 make install I have also verified that I pushed the tag. I doubt that. Actually Ian did push the tag, but not the 9.2 branch. Cheers, Sven ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/llvm: don't export more colors than the number of CBs
On 08/24/2013 07:24 PM, Marek Olšák wrote:
See piglit/fbo-alphatest-nocolor.
Ah, it seems I just compared wrong results when I was testing all
combinations of backends and looked for regressions.
Now I think the problem is that even though llvm backend correctly emits
color export 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...@gmail.com wrote:
On 08/24/2013 02:31 PM, Marek Olšák wrote:
Like Christoph said, COLOR0 (if available) must always be exported for
alpha test.
Are there any piglit tests for that? I didn't see any regressions with this
patch (at least on evergreen), possibly I messed up the testing somehow.
Also I think old 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:
EXPORT PIXEL 0 R0.xyzw VPM
EXPORT PIXEL 61R1.x___ VPM
EXPORT_DONEPIXEL 61R0._x__ VPM EOP
AFAIU with zero color buffers no memory is reserved for colors in the
export
ring and all exports in this example actually write to the same location.
The code above still works fine in this particular case, because correct
values are written last, but reordering can break 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 other hw), needs testing on
pre-evergreen GPUs.
src/gallium/drivers/r600/r600_llvm.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 03a68e4..d2f4aff 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -333,8 +333,8 @@ static void llvm_emit_epilogue(struct
lp_build_tgsi_context * bld_base)
} else if (ctx-type == TGSI_PROCESSOR_FRAGMENT) {
switch (ctx-r600_outputs[i].name) {
case TGSI_SEMANTIC_COLOR:
- has_color = true;
if ( color_count
ctx-color_buffer_count) {
+ has_color = true;
LLVMValueRef args[3];
args[0] = output;
if (ctx-fs_color_all) {
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index fb766c4..85f8469 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1130,7 +1130,7 @@ static int r600_shader_from_tgsi(struct r600_screen
*rscreen,
radeon_llvm_ctx.face_gpr = ctx.face_gpr;
radeon_llvm_ctx.r600_inputs = ctx.shader-input;
radeon_llvm_ctx.r600_outputs = ctx.shader-output;
- radeon_llvm_ctx.color_buffer_count = MAX2(key.nr_cbufs ,
1);
+ radeon_llvm_ctx.color_buffer_count = key.nr_cbufs;
radeon_llvm_ctx.chip_class = ctx.bc-chip_class;
radeon_llvm_ctx.fs_color_all = shader-fs_write_all
(rscreen-chip_class = EVERGREEN);
radeon_llvm_ctx.stream_outputs = so;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 60197] Mesa Gallium VPATH build is broken
https://bugs.freedesktop.org/show_bug.cgi?id=60197 --- Comment #6 from Quentin Sardem FF7 Glidic sardemff7+freedesk...@sardemff7.net --- Seems to be fixed in 76feef0823df75a36f264f48ec843dd863fd5b89 in a slightly different (and worse, imho) way. These Python-generated files should share a single rule if possible, to avoid copypaste issues. And the mkdir should definitely be in the $(AM_V_GEN). You can close this bug, or just ask for a new patch to rewrite the rules. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] i965: Allow C++ type safety in the use of enum brw_urb_write_flags.
Chad Versace chad.vers...@linux.intel.com writes:
On 08/23/2013 02:18 PM, Paul Berry wrote:
The disadvantages are that (a) we need an explicit enum value for 0,
and (b) we can't use related operators like |= unless we define
additional overloads.
Disadvantage (a) is trivial, not really a problem.
I agree, it's not a real disadvantage, you can always define an empty
enumerant that evaluates to zero. If that seems inconvenient or ugly we
can define a global constant that may be implicitly converted to any
bitmask-like enumeration type evaluating to zero, as in:
| templatetypename T
| struct bitmask_enumeration_traits;
|
| struct __empty_bitmask {
|templatetypename T
|operator T() const {
| bitmask_enumeration_traitsT();
| return T();
|}
|
|operator unsigned() const {
| return 0;
|}
| };
|
| const __empty_bitmask empty;
The bitmask_numeration_traits structure makes sure that the
polymorphic conversion operator won't be instantiated for non-bitmask
types. The enum declaration would look like:
| enum E {
| A = 1,
| B = 2,
| C = 4,
| D = 8
| };
|
| template
| struct bitmask_enumeration_traitsE {};
|
Actually, it *is* possible to arrange for the literal 0 to be
implicitly converted to our bitmask enum types in a type-safe way by
exploiting the fact that the language allows it to be implicitly
converted to any pointer type (while implicit conversion of any other
integral expression to a pointer type is disallowed). Though I believe
it would involve using an actual object instead of plain enums because
it's not possible to define a conversion constructor for an enum type.
Disadvantage (b) can be made painless with the macro I discuss below.
IMHO it would be nicer to define generic templates implementing
overloads for all bitwise operators. They would have to reference the
bitmask_enumeration_traits structure so they would be discarded for
non-bitmask types.
Aside from being nicer and safer it would have two clear advantages.
First, if we decide to use the __empty_bitmask type defined above, we
wouldn't have to keep around three different overloads for each binary
operator (T op T, empty op T, T op empty), we'd just define a general
one 'T op S' that would be discarded by the SFINAE rule for incompatible
T and S.
Second, we could arrange for the expression 'FOO op BAR' (with 'FOO' and
'BAR' enumerants from different incompatible bitmask types) to be
rejected by the compiler by means of a static assertion in the
definition of 'T op S'. If we use the macro solution below the compiler
will accept that expression by downgrading both T and S to integers and
then applying the built-in definition of 'op'. Though it would still
refuse to assign the result to a variable of any of both types *if* the
user is doing that.
So what do folks think? Is it worth it?
Yes, I think it's worth it. The code becomes more readable and
more type safe, as evidenced by the diff lines like this:
- unsigned flags,
+ enum brw_urb_write_flags flags,
If we continue to do this to other enums, then we should probably
define a convenience macro to define all the needed overloaded
bit operators. Like this:
#define BRW_CXX_ENUM_OPS(type_name) \
static inline type_name \
operator|(type_name x, type_name y) \
{ \
return (type_name) ((int) x | (int) y); \
} \
\
static inline type_name \
operator() \
and more operators
+/**
+ * Allow brw_urb_write_flags enums to be ORed together (normally C++
wouldn't
+ * allow this without a type cast).
+ */
+inline enum brw_urb_write_flags
+operator|(enum brw_urb_write_flags x, enum brw_urb_write_flags y)
+{
+ return (enum brw_urb_write_flags) ((int) x | (int) y);
+}
+#endif
I think the comment is distracting rather than helpful. There is no need for
C++
code to apologize for being C++ code.
I agree, the comment seems redundant to me (as well as using the 'enum'
keyword before enum names, though that's just a matter of taste). In a
general definition you might want to use the static_cast operator
instead of a c-style cast, to make clear you're only interested in
safe integer-to-enum casts.
In any case this seems like a good thing to do, already in this state,
Reviewed-by: Francisco Jerez curroje...@riseup.net
For what it's worth, this patch is
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgpjfqDaVRvuS.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-announce] Mesa 9.2 release candidate 2
On 08/24/2013 09:57 AM, Sven Joachim wrote: On 2013-08-23 09:48 +0200, Andreas Boll wrote: 2013/8/23 Ian Romanick i...@freedesktop.org: Mesa 9.2 release candidate 2 is now available for testing. The tag in the GIT repository for Mesa 9.2-rc2 is 'mesa-9.2-rc2'. Mesa 9.2 release candidate 2 is available for download at ftp://freedesktop.org/pub/mesa/9.2/ md5sums: 4cde5bbe49658431951e6f51814a9c05 MesaLib-9.2.0-rc2.tar.gz 1b06e7a85fed9b571764affaea51e3e6 MesaLib-9.2.0-rc2.tar.bz2 4a528e491c76e387ba9c6d77e690e4df MesaLib-9.2.0-rc2.zip I have verified building from the .tar.bz2 file by doing: tar -xjf Mesa-9.2.0-rc1.tar.bz2 cd Mesa-9.2.0-rc1 ./configure --enable-gallium-llvm --with-llvm-shared-libs make -j6 make install I have also verified that I pushed the tag. I doubt that. Actually Ian did push the tag, but not the 9.2 branch. Wow. I really screwed that whole thing up. :( It's all actually pushed now. Cheers, Sven ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 68504] 9.2-rc1 clover fails to build on ppc: cannot convert 'bool' to '__vector(4) __bool int' in return
https://bugs.freedesktop.org/show_bug.cgi?id=68504 --- Comment #1 from Francisco Jerez curroje...@riseup.net --- bugzilla-dae...@freedesktop.org writes: Using gcc-4.7.3, llvm-3.3, clang-3.3 on Gentoo PPC [...] Causes the build to fail in clover: In file included from ./core/device.hpp:29:0, from core/device.cpp:23: ./core/base.hpp: In member function '__vector(4) __bool int clover::ref_counter::release()': ./core/base.hpp:73:36: error: cannot convert 'bool' to '__vector(4) __bool int' in return That's weird... It looks like gcc is trying to vectorize the return type of that function, unsuccessfully. Can you try with different build flags like -mcpu=powerpc instead of -mcpu=7450 and/or -fno-tree-vectorize? [...] -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] r600g: Implement the new float comparison instructions for Cayman as well.
I assume this should have been part of commit
7727fbb7c5d64348994bce6682e681d6181a91e9. This (obviously) fixes a lot tests.
Signed-off-by: Henri Verbeet hverb...@gmail.com
---
src/gallium/drivers/r600/r600_shader.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index fb766c4..300b5c4 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -6128,10 +6128,10 @@ static struct r600_shader_tgsi_instruction
cm_shader_tgsi_instruction[] = {
{106, 0, ALU_OP0_NOP, tgsi_unsupported},
{TGSI_OPCODE_NOP, 0, ALU_OP0_NOP, tgsi_unsupported},
/* gap */
- {108, 0, ALU_OP0_NOP, tgsi_unsupported},
- {109, 0, ALU_OP0_NOP, tgsi_unsupported},
- {110, 0, ALU_OP0_NOP, tgsi_unsupported},
- {111, 0, ALU_OP0_NOP, tgsi_unsupported},
+ {TGSI_OPCODE_FSEQ, 0, ALU_OP2_SETE_DX10, tgsi_op2},
+ {TGSI_OPCODE_FSGE, 0, ALU_OP2_SETGE_DX10, tgsi_op2},
+ {TGSI_OPCODE_FSLT, 0, ALU_OP2_SETGT_DX10, tgsi_op2_swap},
+ {TGSI_OPCODE_FSNE, 0, ALU_OP2_SETNE_DX10, tgsi_op2_swap},
{TGSI_OPCODE_NRM4, 0, ALU_OP0_NOP, tgsi_unsupported},
{TGSI_OPCODE_CALLNZ,0, ALU_OP0_NOP, tgsi_unsupported},
/* gap */
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gen_matypes: fix cross-compiling with gcc
On Thursday 18 July 2013 16:59:52 Matt Turner wrote: On Mon, Feb 4, 2013 at 6:27 PM, Mike Frysinger vap...@gentoo.org wrote: The current gen_matypes logic assumes that the host compiler will produce information that is useful for the target compiler. Unfortunately, this is not the case whenever cross-compiling. When we detect that we're cross-compiling and using GCC, use the target compiler to produce assembly from the gen_matypes.c source, then process it with a shell script to create a usable header. This is similar to how the linux kernel creates its asm-offsets.c file. Signed-off-by: Mike Frysinger vap...@gentoo.org --- Thanks, committed (finally). hmm, i'm glad it still applied :) -mike signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
