Brian Paul wrote: > 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).
The software renderer isn't the only target for this architecture, however - we want to support real hardware, with i915 probably representing the low-end cutoff. From the point of view of implementing GL3 on top of pipe/softpipe, there's no problem if pipe/softpipe exports some capabilities not used by the API. However, there is a good reason to retain the alpha test API for implementing GL2 against hardware which does provide alpha test functionality in a fast path compared to fragment shader kills. If we retain the fixed-function method of expressing this state, programmable hardware (and the software rasterizer) can compile that down to a shader pretty easily. Digressing a bit: I think a danger is to try and be too broad about what is being supported under a single driver interface both now and in the future. It would be nice to think an interface defined now will go on being meaningful indefinitely into the future - I don't think that's reasonable given the other goals of pipe/softpipe - small code size, close abstraction of the hardware, etc. At some future point I think we should draw a new cutoff line and re-spin the interface we come up with here in terms of that hardware. Old devices can stay with this interface (and not get broken), new ones will be written against the new interface -- this API won't go on being endlessly pulled and stretched to accommodate new features, it should represent current-ish hardware pretty accurately and efficiently, and be allowed to do so well - and that's it. The interface won't drastically rearchitect itself any more than the existing devices supported by it will. I guess this is somewhat similar to what's going on now -- the existing Mesa driver interface isn't going away as a result of pipe & softpipe, and hardware that really doesn't meet the minimum cutoff (== GL 1.5 pixel shaders, afaict) can still be supported under the existing interfaces. Keith ------------------------------------------------------------------------- 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
