Hi,
You are right!. The bug happens in blend_bind_samplers in shader.c the
texture[0] is NULL and it is wrong initialized.
The patch below fix it:
--- a/src/gallium/state_trackers/vega/shader.c
+++ b/src/gallium/state_trackers/vega/shader.c
@@ -135,8 +135,8 @@ static VGint blend_bind_samplers(struct vg_context *ctx,
textures[2] = stfb->blend_texture;
if (!samplers[0] || !textures[0]) {
- samplers[1] = samplers[2];
- textures[1] = textures[2];
+ samplers[0] = samplers[2];
+ textures[0] = textures[2];
}
if (!samplers[1] || !textures[1]) {
samplers[1] = samplers[0];
--
1.6.3.3
On Mon, Jan 25, 2010 at 7:41 AM, José Fonseca <jfons...@vmware.com> wrote:
> On Sun, 2010-01-24 at 18:36 -0800, Igor Oliveira wrote:
>> The patch fixes the bug 25863.
>> The bug happens when i use blend types like multiply, screen, dark in
>> vega state tracker.
>>
>> --- a/src/gallium/drivers/softpipe/sp_state_sampler.c
>> +++ b/src/gallium/drivers/softpipe/sp_state_sampler.c
>> @@ -244,7 +244,7 @@ softpipe_reset_sampler_varients(struct
>> softpipe_context *softpipe)
>> * fragment programs.
>> */
>> for (i = 0; i <= softpipe->vs->max_sampler; i++) {
>> - if (softpipe->vertex_samplers[i]) {
>> + if (softpipe->vertex_samplers[i] && softpipe->vertex_textures[i]) {
>> softpipe->tgsi.vert_samplers_list[i] =
>> get_sampler_varient( i,
>> sp_sampler(softpipe->vertex_samplers[i]),
>> @@ -258,7 +258,7 @@ softpipe_reset_sampler_varients(struct
>> softpipe_context *softpipe)
>> }
>>
>> for (i = 0; i <= softpipe->fs->info.file_max[TGSI_FILE_SAMPLER]; i++) {
>> - if (softpipe->sampler[i]) {
>> + if (softpipe->sampler[i] && softpipe->texture[i]) {
>> softpipe->tgsi.frag_samplers_list[i] =
>> get_sampler_varient( i,
>> sp_sampler(softpipe->sampler[i]),
>> --
>> 1.6.3.3
>
> This doesn't seem the best way to fix this: the segfault may happen in
> softpipe code, but the state tracker has the responsibility to sanitize
> state. Shouldn't the vega state tracker bind a dummy black texture in
> this case?
>
> Also, the net effect of this patch is to use the previously bound
> texture/sampler -- which may be null -- so the bug is potentially still
> there, but perhaps less likely.
>
> I wonder why changing blend type causes a null texture to be bound in
> the first place? I recall from Zack's VG talk that certain kind of
> blending ops had to be implemented with texturing, but binding a null
> texture binding seems a symptom of some subtle bug.
>
> Jose
>
>
From 45e4ae5196d3a040220364c6a8b790b73d7d2ca1 Mon Sep 17 00:00:00 2001
From: Igor Oliveira <igor.olive...@openbossa.org>
Date: Mon, 25 Jan 2010 10:32:40 -0400
Subject: [PATCH] vega: Fix null texture when using multiply, screen, darken and light
blend
---
src/gallium/state_trackers/vega/shader.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/vega/shader.c b/src/gallium/state_trackers/vega/shader.c
index bd5ae79..8e59d53 100644
--- a/src/gallium/state_trackers/vega/shader.c
+++ b/src/gallium/state_trackers/vega/shader.c
@@ -135,8 +135,8 @@ static VGint blend_bind_samplers(struct vg_context *ctx,
textures[2] = stfb->blend_texture;
if (!samplers[0] || !textures[0]) {
- samplers[1] = samplers[2];
- textures[1] = textures[2];
+ samplers[0] = samplers[2];
+ textures[0] = textures[2];
}
if (!samplers[1] || !textures[1]) {
samplers[1] = samplers[0];
--
1.6.3.3
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
