Keith Whitwell wrote:
> Brian,
> 
> I'm wondering if there isn't some way to rationalize the multiple 
> sp_quad stages that each individually readback the current framebuffer 
> values for use within the stage.
> 
> At the moment that looks like:
>     - blend
>     - colormask
>     - final write (masked case)
> 
> It seems like reading the values once and carrying them along the 
> pipeline would be a good strategy *except* for the fast path of 
> non-masked, non-blended full quad writes.   Perhaps there should be 
> something like:
> 
>     - early write stage (write & terminate pipeline if mask == 0xf)
>         -- only add to pipeline if blend, colormask disabled.
>     - framebuffer readback
>     - blend
>     - colormask
>     - masked-copy (to apply quad->mask)
>     - late write stage.
> 
> 
> Similarly for Z, stencil, early-z-test, etc, it might make sense to read 
> the framebuffer Z/stencil values at an early point and carry them along 
> with the quad...

At this point I'm still just filling in the stages.  Early-reading the 
framebuffer colors and shortcutting the mask=0xf case would be good 
improvements.  I noticed a nice speed-up when I added a 'if mask==0, 
stop" check after Z-testing.

Even better is to do early Z/stencil testing to discard fragments before 
shading/texturing like we do in the s_span.c code.  That'll involve 
analyzing the shader (does it write to fragment.z?), alpha test, 
occlusion query state and rearranging the pipeline stages accordingly.

Another thought is to move some traditional per-fragment operations into 
the fragment program itself.  Alpha test, for example, may no longer 
exist in OpenGL 3.0; it would be up to the user to encode the test in 
their shader.

With software rendering, we have the potential to do almost everything 
in the fragment shader.  One idea I had is to add a new input register 
to fragment programs which is the current framebuffer color.  We could 
use that to do blending/masking/etc. in the program.  Normally, this 
would be hidden, but it could be exposed as an interesting new OpenGL 
extension (and something unique to Mesa).

-Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to