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
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
>
> 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 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
> ---
>
> 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=84560&action=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 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 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
---
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 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 >>> Signed-off-by: Ilia Mirkin >> >> >> 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 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
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
>
>
> 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 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
>> 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
>>> ---
>>>
>>> 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 : >> 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 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
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
---
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 --- 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 copy&paste 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 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:
| template
| struct bitmask_enumeration_traits;
|
| struct __empty_bitmask {
|template
|operator T() const {
| bitmask_enumeration_traits();
| 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_traits {};
|
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
> For what it's worth, this patch is
> Reviewed-by: Chad Versace
> ___
> 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 : 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 --- 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
---
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 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 > > --- > > 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
