Re: [Mesa3d-dev] ARB draw buffers + texenv program
On 14.04.2010 00:38, Dave Airlie wrote:
> On Wed, Apr 14, 2010 at 8:33 AM, Roland Scheidegger
> wrote:
>> On 13.04.2010 20:28, Alex Deucher wrote:
>>> On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
>>> wrote:
On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger
wrote:
> On 13.04.2010 02:52, Dave Airlie wrote:
>> On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote:
>>> Dave Airlie wrote:
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs to understand the
draw buffers. The attached patch fixes it here for me on r300g anyone
want to test this on Intel
with the piglit test before/after?
>>> The piglit test passes as-is with Mesa/swrast and NVIDIA.
>>>
>>> It fails with gallium/softpipe both with and w/out your patch.
>>>
>>> I think that your patch is on the right track. But multiple render
>>> targets
>>> are still a bit of an untested area in the st/mesa code.
>>>
>>> One thing: the patch introduces a dependency on buffer state in the
>>> texenvprogram code so in state.c we should check for the _NEW_BUFFERS
>>> flag.
>>>
>>> Otherwise, I'd like to debug the softpipe failure a bit further to see
>>> what's going on. Perhaps you could hold off on committing this for a
>>> bit...
>> Well Eric pointed out to me the fun line in the spec
>>
>> (3) Should gl_FragColor be aliased to gl_FragData[0]?
>>
>> RESOLUTION: No. A shader should write either gl_FragColor, or
>> gl_FragData[n], but not both.
>>
>> Writing to gl_FragColor will write to all draw buffers specified
>> with DrawBuffersARB.
>>
>> So I was really just masking the issue with this. From what I can see
>> softpipe messes up and I'm not sure where we should be fixing this.
>> swrast does okay, its just whether we should be doing something in
>> gallium
>> or in the drivers is open.
> Hmm yes looks like that's not really well defined. I guess there are
> several options here:
> 1) don't do anything at the state tracker level, and assume that if a
> fragment shader only writes to color 0 but has several color buffers
> bound the color is meant to go to all outputs. Looks like that's what
> nv50 is doing today. If a shader writes to FragData[0] but not others,
> in gallium that would mean that output still gets replicated to all
> outputs, but since the spec says unwritten outputs are undefined that
> would be just fine (for OpenGL - not sure about other APIs).
> 2) Use some explicit means to distinguish FragData[] from FragColor in
> gallium. For instance, could use different semantic name (like
> TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective
> outputs). Or could have a flag somewhere (not quite sure where) saying
> if color output is to be replicated to all buffers.
> 3) Translate away the single color output in state tracker to multiple
> outputs.
>
> I don't like option 3) though. Means we need to recompile if the
> attached buffers change. Moreover, it seems both new nvidia and AMD
> chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw.
> I don't like option 1) neither, that kind of implicit behavior might be
> ok but this kind of guesswork isn't very nice imho.
Whatever's easiest, just document it. I'd be cool with:
DECL IN[0], COLOR, PERSPECTIVE
DECL OUT[0], COLOR
MOV OUT[0], IN[0]
END
Effectively being a write to all color buffers, however, this one from
progs/tests/drawbuffers:
DCL IN[0], COLOR, LINEAR
DCL OUT[0], COLOR
DCL OUT[1], COLOR[1]
IMM FLT32 { 1., 0., 0., 0. }
0: MOV OUT[0], IN[0]
1: SUB OUT[1], IMM[0]., IN[0]
2: END
Would then double-write the second color buffer. Unpleasant. Language
like this would work, I suppose?
"""
If only one color output is declared, writes to the color output shall
be redirected to all bound color buffers. Otherwise, color outputs
shall be bound to their specific color buffer.
"""
>>> Also, keep in mind that writing to multiple color buffers uses
>>> additional memory bandwidth, so for performance, we should only do so
>>> when required.
>> Do apps really have several color buffers bound but only write to one,
>> leaving the state of the others undefined in the process? Sounds like a
>> poor app to begin with to me.
>> Actually, I would restrict that language above further, so only color
>> output 0 will get redirected to all buffers if it's the only one
>> written. As said though I'd think some explicit bits somewhere are
>> cleaner. I'm not yet sure that the above would really wo
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Wed, Apr 14, 2010 at 8:33 AM, Roland Scheidegger wrote:
> On 13.04.2010 20:28, Alex Deucher wrote:
>> On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
>> wrote:
>>> On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger
>>> wrote:
On 13.04.2010 02:52, Dave Airlie wrote:
> On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote:
>> Dave Airlie wrote:
>>> Just going down the r300g piglit failures and noticed fbo-drawbuffers
>>> failed, I've no idea
>>> if this passes on Intel hw, but it appears the texenvprogram really
>>> needs to understand the
>>> draw buffers. The attached patch fixes it here for me on r300g anyone
>>> want to test this on Intel
>>> with the piglit test before/after?
>> The piglit test passes as-is with Mesa/swrast and NVIDIA.
>>
>> It fails with gallium/softpipe both with and w/out your patch.
>>
>> I think that your patch is on the right track. But multiple render
>> targets
>> are still a bit of an untested area in the st/mesa code.
>>
>> One thing: the patch introduces a dependency on buffer state in the
>> texenvprogram code so in state.c we should check for the _NEW_BUFFERS
>> flag.
>>
>> Otherwise, I'd like to debug the softpipe failure a bit further to see
>> what's going on. Perhaps you could hold off on committing this for a
>> bit...
> Well Eric pointed out to me the fun line in the spec
>
> (3) Should gl_FragColor be aliased to gl_FragData[0]?
>
> RESOLUTION: No. A shader should write either gl_FragColor, or
> gl_FragData[n], but not both.
>
> Writing to gl_FragColor will write to all draw buffers specified
> with DrawBuffersARB.
>
> So I was really just masking the issue with this. From what I can see
> softpipe messes up and I'm not sure where we should be fixing this.
> swrast does okay, its just whether we should be doing something in gallium
> or in the drivers is open.
Hmm yes looks like that's not really well defined. I guess there are
several options here:
1) don't do anything at the state tracker level, and assume that if a
fragment shader only writes to color 0 but has several color buffers
bound the color is meant to go to all outputs. Looks like that's what
nv50 is doing today. If a shader writes to FragData[0] but not others,
in gallium that would mean that output still gets replicated to all
outputs, but since the spec says unwritten outputs are undefined that
would be just fine (for OpenGL - not sure about other APIs).
2) Use some explicit means to distinguish FragData[] from FragColor in
gallium. For instance, could use different semantic name (like
TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective
outputs). Or could have a flag somewhere (not quite sure where) saying
if color output is to be replicated to all buffers.
3) Translate away the single color output in state tracker to multiple
outputs.
I don't like option 3) though. Means we need to recompile if the
attached buffers change. Moreover, it seems both new nvidia and AMD
chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw.
I don't like option 1) neither, that kind of implicit behavior might be
ok but this kind of guesswork isn't very nice imho.
>>> Whatever's easiest, just document it. I'd be cool with:
>>>
>>> DECL IN[0], COLOR, PERSPECTIVE
>>> DECL OUT[0], COLOR
>>> MOV OUT[0], IN[0]
>>> END
>>>
>>> Effectively being a write to all color buffers, however, this one from
>>> progs/tests/drawbuffers:
>>>
>>> DCL IN[0], COLOR, LINEAR
>>> DCL OUT[0], COLOR
>>> DCL OUT[1], COLOR[1]
>>> IMM FLT32 { 1., 0., 0., 0. }
>>> 0: MOV OUT[0], IN[0]
>>> 1: SUB OUT[1], IMM[0]., IN[0]
>>> 2: END
>>>
>>> Would then double-write the second color buffer. Unpleasant. Language
>>> like this would work, I suppose?
>>>
>>> """
>>> If only one color output is declared, writes to the color output shall
>>> be redirected to all bound color buffers. Otherwise, color outputs
>>> shall be bound to their specific color buffer.
>>> """
>>
>> Also, keep in mind that writing to multiple color buffers uses
>> additional memory bandwidth, so for performance, we should only do so
>> when required.
>
> Do apps really have several color buffers bound but only write to one,
> leaving the state of the others undefined in the process? Sounds like a
> poor app to begin with to me.
> Actually, I would restrict that language above further, so only color
> output 0 will get redirected to all buffers if it's the only one
> written. As said though I'd think some explicit bits somewhere are
> cleaner. I'm not yet sure that the above would really work for all APIs,
> it is possible some say other buffers not written to are left as is
> instead of undefined.
Who knows, the GL API allows for it, I
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On 13.04.2010 20:28, Alex Deucher wrote:
> On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
> wrote:
>> On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger
>> wrote:
>>> On 13.04.2010 02:52, Dave Airlie wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote:
> Dave Airlie wrote:
>> Just going down the r300g piglit failures and noticed fbo-drawbuffers
>> failed, I've no idea
>> if this passes on Intel hw, but it appears the texenvprogram really
>> needs to understand the
>> draw buffers. The attached patch fixes it here for me on r300g anyone
>> want to test this on Intel
>> with the piglit test before/after?
> The piglit test passes as-is with Mesa/swrast and NVIDIA.
>
> It fails with gallium/softpipe both with and w/out your patch.
>
> I think that your patch is on the right track. But multiple render
> targets
> are still a bit of an untested area in the st/mesa code.
>
> One thing: the patch introduces a dependency on buffer state in the
> texenvprogram code so in state.c we should check for the _NEW_BUFFERS
> flag.
>
> Otherwise, I'd like to debug the softpipe failure a bit further to see
> what's going on. Perhaps you could hold off on committing this for a
> bit...
Well Eric pointed out to me the fun line in the spec
(3) Should gl_FragColor be aliased to gl_FragData[0]?
RESOLUTION: No. A shader should write either gl_FragColor, or
gl_FragData[n], but not both.
Writing to gl_FragColor will write to all draw buffers specified
with DrawBuffersARB.
So I was really just masking the issue with this. From what I can see
softpipe messes up and I'm not sure where we should be fixing this.
swrast does okay, its just whether we should be doing something in gallium
or in the drivers is open.
>>> Hmm yes looks like that's not really well defined. I guess there are
>>> several options here:
>>> 1) don't do anything at the state tracker level, and assume that if a
>>> fragment shader only writes to color 0 but has several color buffers
>>> bound the color is meant to go to all outputs. Looks like that's what
>>> nv50 is doing today. If a shader writes to FragData[0] but not others,
>>> in gallium that would mean that output still gets replicated to all
>>> outputs, but since the spec says unwritten outputs are undefined that
>>> would be just fine (for OpenGL - not sure about other APIs).
>>> 2) Use some explicit means to distinguish FragData[] from FragColor in
>>> gallium. For instance, could use different semantic name (like
>>> TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective
>>> outputs). Or could have a flag somewhere (not quite sure where) saying
>>> if color output is to be replicated to all buffers.
>>> 3) Translate away the single color output in state tracker to multiple
>>> outputs.
>>>
>>> I don't like option 3) though. Means we need to recompile if the
>>> attached buffers change. Moreover, it seems both new nvidia and AMD
>>> chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw.
>>> I don't like option 1) neither, that kind of implicit behavior might be
>>> ok but this kind of guesswork isn't very nice imho.
>> Whatever's easiest, just document it. I'd be cool with:
>>
>> DECL IN[0], COLOR, PERSPECTIVE
>> DECL OUT[0], COLOR
>> MOV OUT[0], IN[0]
>> END
>>
>> Effectively being a write to all color buffers, however, this one from
>> progs/tests/drawbuffers:
>>
>> DCL IN[0], COLOR, LINEAR
>> DCL OUT[0], COLOR
>> DCL OUT[1], COLOR[1]
>> IMM FLT32 { 1., 0., 0., 0. }
>> 0: MOV OUT[0], IN[0]
>> 1: SUB OUT[1], IMM[0]., IN[0]
>> 2: END
>>
>> Would then double-write the second color buffer. Unpleasant. Language
>> like this would work, I suppose?
>>
>> """
>> If only one color output is declared, writes to the color output shall
>> be redirected to all bound color buffers. Otherwise, color outputs
>> shall be bound to their specific color buffer.
>> """
>
> Also, keep in mind that writing to multiple color buffers uses
> additional memory bandwidth, so for performance, we should only do so
> when required.
Do apps really have several color buffers bound but only write to one,
leaving the state of the others undefined in the process? Sounds like a
poor app to begin with to me.
Actually, I would restrict that language above further, so only color
output 0 will get redirected to all buffers if it's the only one
written. As said though I'd think some explicit bits somewhere are
cleaner. I'm not yet sure that the above would really work for all APIs,
it is possible some say other buffers not written to are left as is
instead of undefined.
Roland
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 13, 2010 at 11:42 PM, Roland Scheidegger wrote: > On 13.04.2010 02:52, Dave Airlie wrote: >> On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote: >>> Dave Airlie wrote: Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? >>> The piglit test passes as-is with Mesa/swrast and NVIDIA. >>> >>> It fails with gallium/softpipe both with and w/out your patch. >>> >>> I think that your patch is on the right track. But multiple render targets >>> are still a bit of an untested area in the st/mesa code. >>> >>> One thing: the patch introduces a dependency on buffer state in the >>> texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. >>> >>> Otherwise, I'd like to debug the softpipe failure a bit further to see >>> what's going on. Perhaps you could hold off on committing this for a bit... >> >> Well Eric pointed out to me the fun line in the spec >> >> (3) Should gl_FragColor be aliased to gl_FragData[0]? >> >> RESOLUTION: No. A shader should write either gl_FragColor, or >> gl_FragData[n], but not both. >> >> Writing to gl_FragColor will write to all draw buffers specified >> with DrawBuffersARB. >> >> So I was really just masking the issue with this. From what I can see >> softpipe messes up and I'm not sure where we should be fixing this. >> swrast does okay, its just whether we should be doing something in gallium >> or in the drivers is open. > > Hmm yes looks like that's not really well defined. I guess there are > several options here: > 1) don't do anything at the state tracker level, and assume that if a > fragment shader only writes to color 0 but has several color buffers > bound the color is meant to go to all outputs. Looks like that's what > nv50 is doing today. If a shader writes to FragData[0] but not others, > in gallium that would mean that output still gets replicated to all > outputs, but since the spec says unwritten outputs are undefined that > would be just fine (for OpenGL - not sure about other APIs). > 2) Use some explicit means to distinguish FragData[] from FragColor in > gallium. For instance, could use different semantic name (like > TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective > outputs). Or could have a flag somewhere (not quite sure where) saying > if color output is to be replicated to all buffers. > 3) Translate away the single color output in state tracker to multiple > outputs. > > I don't like option 3) though. Means we need to recompile if the > attached buffers change. Moreover, it seems both new nvidia and AMD > chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw. > I don't like option 1) neither, that kind of implicit behavior might be > ok but this kind of guesswork isn't very nice imho. > Yeah 3 is definitely out, I've tried it its too messy, esp with 1->n and n->1 transitions, I'd be happy with 1 or 2, though I do wonder with 1 do you end up binding Color and Data0 implicitly say you bound 2 buffers but your fragprog only emits to one on purpose (maybe you have a few fragprogs). So I expect 2 is the correct answer. Dave. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
wrote:
> On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger
> wrote:
>> On 13.04.2010 02:52, Dave Airlie wrote:
>>> On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote:
Dave Airlie wrote:
> Just going down the r300g piglit failures and noticed fbo-drawbuffers
> failed, I've no idea
> if this passes on Intel hw, but it appears the texenvprogram really
> needs to understand the
> draw buffers. The attached patch fixes it here for me on r300g anyone
> want to test this on Intel
> with the piglit test before/after?
The piglit test passes as-is with Mesa/swrast and NVIDIA.
It fails with gallium/softpipe both with and w/out your patch.
I think that your patch is on the right track. But multiple render targets
are still a bit of an untested area in the st/mesa code.
One thing: the patch introduces a dependency on buffer state in the
texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag.
Otherwise, I'd like to debug the softpipe failure a bit further to see
what's going on. Perhaps you could hold off on committing this for a
bit...
>>>
>>> Well Eric pointed out to me the fun line in the spec
>>>
>>> (3) Should gl_FragColor be aliased to gl_FragData[0]?
>>>
>>> RESOLUTION: No. A shader should write either gl_FragColor, or
>>> gl_FragData[n], but not both.
>>>
>>> Writing to gl_FragColor will write to all draw buffers specified
>>> with DrawBuffersARB.
>>>
>>> So I was really just masking the issue with this. From what I can see
>>> softpipe messes up and I'm not sure where we should be fixing this.
>>> swrast does okay, its just whether we should be doing something in gallium
>>> or in the drivers is open.
>>
>> Hmm yes looks like that's not really well defined. I guess there are
>> several options here:
>> 1) don't do anything at the state tracker level, and assume that if a
>> fragment shader only writes to color 0 but has several color buffers
>> bound the color is meant to go to all outputs. Looks like that's what
>> nv50 is doing today. If a shader writes to FragData[0] but not others,
>> in gallium that would mean that output still gets replicated to all
>> outputs, but since the spec says unwritten outputs are undefined that
>> would be just fine (for OpenGL - not sure about other APIs).
>> 2) Use some explicit means to distinguish FragData[] from FragColor in
>> gallium. For instance, could use different semantic name (like
>> TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective
>> outputs). Or could have a flag somewhere (not quite sure where) saying
>> if color output is to be replicated to all buffers.
>> 3) Translate away the single color output in state tracker to multiple
>> outputs.
>>
>> I don't like option 3) though. Means we need to recompile if the
>> attached buffers change. Moreover, it seems both new nvidia and AMD
>> chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw.
>> I don't like option 1) neither, that kind of implicit behavior might be
>> ok but this kind of guesswork isn't very nice imho.
>
> Whatever's easiest, just document it. I'd be cool with:
>
> DECL IN[0], COLOR, PERSPECTIVE
> DECL OUT[0], COLOR
> MOV OUT[0], IN[0]
> END
>
> Effectively being a write to all color buffers, however, this one from
> progs/tests/drawbuffers:
>
> DCL IN[0], COLOR, LINEAR
> DCL OUT[0], COLOR
> DCL OUT[1], COLOR[1]
> IMM FLT32 { 1., 0., 0., 0. }
> 0: MOV OUT[0], IN[0]
> 1: SUB OUT[1], IMM[0]., IN[0]
> 2: END
>
> Would then double-write the second color buffer. Unpleasant. Language
> like this would work, I suppose?
>
> """
> If only one color output is declared, writes to the color output shall
> be redirected to all bound color buffers. Otherwise, color outputs
> shall be bound to their specific color buffer.
> """
Also, keep in mind that writing to multiple color buffers uses
additional memory bandwidth, so for performance, we should only do so
when required.
Alex
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger wrote:
> On 13.04.2010 02:52, Dave Airlie wrote:
>> On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote:
>>> Dave Airlie wrote:
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs to understand the
draw buffers. The attached patch fixes it here for me on r300g anyone
want to test this on Intel
with the piglit test before/after?
>>> The piglit test passes as-is with Mesa/swrast and NVIDIA.
>>>
>>> It fails with gallium/softpipe both with and w/out your patch.
>>>
>>> I think that your patch is on the right track. But multiple render targets
>>> are still a bit of an untested area in the st/mesa code.
>>>
>>> One thing: the patch introduces a dependency on buffer state in the
>>> texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag.
>>>
>>> Otherwise, I'd like to debug the softpipe failure a bit further to see
>>> what's going on. Perhaps you could hold off on committing this for a bit...
>>
>> Well Eric pointed out to me the fun line in the spec
>>
>> (3) Should gl_FragColor be aliased to gl_FragData[0]?
>>
>> RESOLUTION: No. A shader should write either gl_FragColor, or
>> gl_FragData[n], but not both.
>>
>> Writing to gl_FragColor will write to all draw buffers specified
>> with DrawBuffersARB.
>>
>> So I was really just masking the issue with this. From what I can see
>> softpipe messes up and I'm not sure where we should be fixing this.
>> swrast does okay, its just whether we should be doing something in gallium
>> or in the drivers is open.
>
> Hmm yes looks like that's not really well defined. I guess there are
> several options here:
> 1) don't do anything at the state tracker level, and assume that if a
> fragment shader only writes to color 0 but has several color buffers
> bound the color is meant to go to all outputs. Looks like that's what
> nv50 is doing today. If a shader writes to FragData[0] but not others,
> in gallium that would mean that output still gets replicated to all
> outputs, but since the spec says unwritten outputs are undefined that
> would be just fine (for OpenGL - not sure about other APIs).
> 2) Use some explicit means to distinguish FragData[] from FragColor in
> gallium. For instance, could use different semantic name (like
> TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective
> outputs). Or could have a flag somewhere (not quite sure where) saying
> if color output is to be replicated to all buffers.
> 3) Translate away the single color output in state tracker to multiple
> outputs.
>
> I don't like option 3) though. Means we need to recompile if the
> attached buffers change. Moreover, it seems both new nvidia and AMD
> chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw.
> I don't like option 1) neither, that kind of implicit behavior might be
> ok but this kind of guesswork isn't very nice imho.
Whatever's easiest, just document it. I'd be cool with:
DECL IN[0], COLOR, PERSPECTIVE
DECL OUT[0], COLOR
MOV OUT[0], IN[0]
END
Effectively being a write to all color buffers, however, this one from
progs/tests/drawbuffers:
DCL IN[0], COLOR, LINEAR
DCL OUT[0], COLOR
DCL OUT[1], COLOR[1]
IMM FLT32 { 1., 0., 0., 0. }
0: MOV OUT[0], IN[0]
1: SUB OUT[1], IMM[0]., IN[0]
2: END
Would then double-write the second color buffer. Unpleasant. Language
like this would work, I suppose?
"""
If only one color output is declared, writes to the color output shall
be redirected to all bound color buffers. Otherwise, color outputs
shall be bound to their specific color buffer.
"""
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On 13.04.2010 02:52, Dave Airlie wrote: > On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote: >> Dave Airlie wrote: >>> Just going down the r300g piglit failures and noticed fbo-drawbuffers >>> failed, I've no idea >>> if this passes on Intel hw, but it appears the texenvprogram really >>> needs to understand the >>> draw buffers. The attached patch fixes it here for me on r300g anyone >>> want to test this on Intel >>> with the piglit test before/after? >> The piglit test passes as-is with Mesa/swrast and NVIDIA. >> >> It fails with gallium/softpipe both with and w/out your patch. >> >> I think that your patch is on the right track. But multiple render targets >> are still a bit of an untested area in the st/mesa code. >> >> One thing: the patch introduces a dependency on buffer state in the >> texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. >> >> Otherwise, I'd like to debug the softpipe failure a bit further to see >> what's going on. Perhaps you could hold off on committing this for a bit... > > Well Eric pointed out to me the fun line in the spec > > (3) Should gl_FragColor be aliased to gl_FragData[0]? > > RESOLUTION: No. A shader should write either gl_FragColor, or > gl_FragData[n], but not both. > > Writing to gl_FragColor will write to all draw buffers specified > with DrawBuffersARB. > > So I was really just masking the issue with this. From what I can see > softpipe messes up and I'm not sure where we should be fixing this. > swrast does okay, its just whether we should be doing something in gallium > or in the drivers is open. Hmm yes looks like that's not really well defined. I guess there are several options here: 1) don't do anything at the state tracker level, and assume that if a fragment shader only writes to color 0 but has several color buffers bound the color is meant to go to all outputs. Looks like that's what nv50 is doing today. If a shader writes to FragData[0] but not others, in gallium that would mean that output still gets replicated to all outputs, but since the spec says unwritten outputs are undefined that would be just fine (for OpenGL - not sure about other APIs). 2) Use some explicit means to distinguish FragData[] from FragColor in gallium. For instance, could use different semantic name (like TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective outputs). Or could have a flag somewhere (not quite sure where) saying if color output is to be replicated to all buffers. 3) Translate away the single color output in state tracker to multiple outputs. I don't like option 3) though. Means we need to recompile if the attached buffers change. Moreover, it seems both new nvidia and AMD chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw. I don't like option 1) neither, that kind of implicit behavior might be ok but this kind of guesswork isn't very nice imho. Opinions? Roland -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On 04/13/2010 08:07 AM, Luca Barbieri wrote: > On nv30/nv40 support for patching fragment programs is already > necessary (constants must be patched in as immediates), and this can > be handled by just patching the end of the fragment program to include > a variable number of instructions to copy a temp to COLOR[x]. > > It's possible that there could be a hardware mechanism too, haven't checked. > > If other MRT-capable hardware already has this kind of fragment > program patching or supports this in hardware, then a new TGSI > semantic or register file can be added for this, and drivers can > easily implement that without recompilation. > nv50 passes, we check if multiple color results are written and if not, we don't set the FP_CTRL_MULTIPLE_RESULTS bit, and COLOR[0] goes to all RTs :-) I think nv40 might have that too, check the bits in your FP_CONTROL. > Drivers could also just unconditionally write all color outputs as a > first implementation or if that doesn't affect performance. > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On nv30/nv40 support for patching fragment programs is already necessary (constants must be patched in as immediates), and this can be handled by just patching the end of the fragment program to include a variable number of instructions to copy a temp to COLOR[x]. It's possible that there could be a hardware mechanism too, haven't checked. If other MRT-capable hardware already has this kind of fragment program patching or supports this in hardware, then a new TGSI semantic or register file can be added for this, and drivers can easily implement that without recompilation. Drivers could also just unconditionally write all color outputs as a first implementation or if that doesn't affect performance. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
> > (3) Should gl_FragColor be aliased to gl_FragData[0]? > > RESOLUTION: No. A shader should write either gl_FragColor, or > gl_FragData[n], but not both. > > Writing to gl_FragColor will write to all draw buffers specified > with DrawBuffersARB. > > So I was really just masking the issue with this. From what I can see > softpipe messes up and I'm not sure where we should be fixing this. > swrast does okay, its just whether we should be doing something in gallium > or in the drivers is open. > > From what I can see i965 + r300-r500 and at least nv40 from talking to Ben > would need fragment program changes to emit to each buffer instead. Okay I'm failing to get this to work, I'll run down the ideas I had so far that failed. 1. Have the mesa state tracker add the extra output instructions to the fragment program at compile time. Failed: no where to actually invalidate the current fragment program. 2. Add a flag to mesa context and have mesa add the extra output instructions at compile time (prog parser + texenvprogram). Failed: no where to tell that the FP needs updating has changed so needs to be recompiled. this works for texenvprog but fails for user programs. Now the other place to do this is like i965 does, in the driver but from a gallium pov it seems like something the state tracker should deal with at TGSI doesn't seem to care about the nuance between FRAG_OUTPUT_COLOR and FRAG_OUTPUT_DATAx http://people.freedesktop.org/~airlied/fp-convert-color-data-fail-one.patch Has the fail for case 2, the programopt.c changes are most likely correct, and I guess I can do option 1 with some sort of state tracker program invalidation (i.e. freeing the TGSI tokens and letting it get recompiled.) Ideas? Dave. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote: > Dave Airlie wrote: >> >> Just going down the r300g piglit failures and noticed fbo-drawbuffers >> failed, I've no idea >> if this passes on Intel hw, but it appears the texenvprogram really >> needs to understand the >> draw buffers. The attached patch fixes it here for me on r300g anyone >> want to test this on Intel >> with the piglit test before/after? > > The piglit test passes as-is with Mesa/swrast and NVIDIA. > > It fails with gallium/softpipe both with and w/out your patch. > > I think that your patch is on the right track. But multiple render targets > are still a bit of an untested area in the st/mesa code. > > One thing: the patch introduces a dependency on buffer state in the > texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. > > Otherwise, I'd like to debug the softpipe failure a bit further to see > what's going on. Perhaps you could hold off on committing this for a bit... Well Eric pointed out to me the fun line in the spec (3) Should gl_FragColor be aliased to gl_FragData[0]? RESOLUTION: No. A shader should write either gl_FragColor, or gl_FragData[n], but not both. Writing to gl_FragColor will write to all draw buffers specified with DrawBuffersARB. So I was really just masking the issue with this. From what I can see softpipe messes up and I'm not sure where we should be fixing this. swrast does okay, its just whether we should be doing something in gallium or in the drivers is open. >From what I can see i965 + r300-r500 and at least nv40 from talking to Ben would need fragment program changes to emit to each buffer instead. Dave. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 6, 2010 at 10:47 PM, Keith Whitwell wrote: > On Fri, 2010-04-02 at 20:43 -0700, Dave Airlie wrote: >> Just going down the r300g piglit failures and noticed fbo-drawbuffers >> failed, I've no idea >> if this passes on Intel hw, but it appears the texenvprogram really >> needs to understand the >> draw buffers. The attached patch fixes it here for me on r300g anyone >> want to test this on Intel >> with the piglit test before/after? >> >> Dave. > > This change makes sense & looks good to me. Thanks pushed to 7.8. Dave. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Fri, 2010-04-02 at 20:43 -0700, Dave Airlie wrote: > Just going down the r300g piglit failures and noticed fbo-drawbuffers > failed, I've no idea > if this passes on Intel hw, but it appears the texenvprogram really > needs to understand the > draw buffers. The attached patch fixes it here for me on r300g anyone > want to test this on Intel > with the piglit test before/after? > > Dave. This change makes sense & looks good to me. Keith -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
Brian Paul wrote: > Dave Airlie wrote: >> Just going down the r300g piglit failures and noticed fbo-drawbuffers >> failed, I've no idea >> if this passes on Intel hw, but it appears the texenvprogram really >> needs to understand the >> draw buffers. The attached patch fixes it here for me on r300g anyone >> want to test this on Intel >> with the piglit test before/after? > > The piglit test passes as-is with Mesa/swrast and NVIDIA. > > It fails with gallium/softpipe both with and w/out your patch. > > I think that your patch is on the right track. But multiple render > targets are still a bit of an untested area in the st/mesa code. > > One thing: the patch introduces a dependency on buffer state in the > texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. > > Otherwise, I'd like to debug the softpipe failure a bit further to see > what's going on. Perhaps you could hold off on committing this for a > bit... OK, I found/fixed the problem in softpipe. I think your patch is good, but I think we should hold off on committing it to the 7.8 branch until it's tested a bit more (and not delay the 7.8.1 release). Other people should apply it and give it a try. -Brian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
Dave Airlie wrote: > Just going down the r300g piglit failures and noticed fbo-drawbuffers > failed, I've no idea > if this passes on Intel hw, but it appears the texenvprogram really > needs to understand the > draw buffers. The attached patch fixes it here for me on r300g anyone > want to test this on Intel > with the piglit test before/after? The piglit test passes as-is with Mesa/swrast and NVIDIA. It fails with gallium/softpipe both with and w/out your patch. I think that your patch is on the right track. But multiple render targets are still a bit of an untested area in the st/mesa code. One thing: the patch introduces a dependency on buffer state in the texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. Otherwise, I'd like to debug the softpipe failure a bit further to see what's going on. Perhaps you could hold off on committing this for a bit... -Brian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Sat, Apr 03, 2010 at 01:43:04PM +1000, Dave Airlie wrote: > Just going down the r300g piglit failures and noticed fbo-drawbuffers > failed, I've no idea > if this passes on Intel hw, but it appears the texenvprogram really > needs to understand the > draw buffers. The attached patch fixes it here for me on r300g anyone > want to test this on Intel > with the piglit test before/after? i915g has MaxDrawBuffers == 1 and the test is skipped. -- o...@lunarg.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] ARB draw buffers + texenv program
Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? Dave. 0001-texenvprogram-fix-for-ARB_draw_buffers.patch Description: Binary data -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
