On Fri, 2003-08-29 at 17:22, Ian Romanick wrote:Eric Anholt wrote:
* Not sure if the fogging in fire is correct -- it looks like I
would expect it to, but it disagrees with software rendering.
That is common. The sw path does per-pixel fog calculations and the hw path likely does per-vertex fog calculations.
Okay, I may be confused here: I understood that the default was the fog source being FRAGMENT_DEPTH. That's what it looks to me like is going on right now with sis (full DRI trunk plus the new driver) and with software rendering on my main box (radeon and 4.3.0). In contrast, the radeon and the software rendering on my sis box have a constant fogging across the ground, which I remember being told was because the fog was being interpolated between the vertices, which in the case of the ground happened to all have the same fog value. The vertex-based FOG_COORDINATE fogging is non-default, and the fire demo doesn't appear to change that. Or am I totally wrong/misreading things here?
There's two ways that fog color can be calculated per fragment. The fog factor can be interpolated and the color calculated per-pixel (expensive), or the fog color can be calculated per-vertex and the resulting color interpolated (cheep). Most hardware (esp. older hardware) does the later.
/me sticks FOG_COORDINATE fogging on the todo list
EXT_fog_coord is an orthogonal issue. This allows the application to specify the per-vertex fog factor directly instead of using the Z value. It is still up to the implementation whether to interpolate the fog factor and calculate the fog color per-pixel or do the color calculation per-vertex.
* Implement / advertise GL extensions.
[snip]
Thanks for the pointers on this. My main question is, how do I make sure when I expose those extensions that I'm actually conforming? Do we have a more extensive suite of demos somewhere than what's in the mesademos package in deb? Does glean cover these? (haven't set that up yet)
glean tests some extensions, but not that many.
* Get AGP support working (waiting for the card to come)
You will probably also want to convert the driver to use the texmem interface. There are also some utility functions in xc/lib/GL/mesa/src/drv/common/utils.[ch] that you should use.
Yeah, but converting to texmem would be a good chunk of work. Currently, the front buffer is allocated by the X Server but
back/depth/stencil are allocated from the framebuffer by client (to the
size of the window). Textures are allocated from framebuffer and then
AGP if framebuffer fails. If we were to move to the same system of
sharing space for textures as other drivers, it seems like we would have
to move to static back/depth/stencil, since otherwise how much of the
framebuffer do we save out for back/depth/stencil buffers of future
clients? That seems like the opposite direction from what's been talked
about for the future. The current system is no solution, though. Since
there's no method to kick out old textures when we run out of
framebuffer and agp, it just aborts.
That's interesting. I'll have to look at their texture code. It might be worth using the texmem code to manage textures in AGP space, though.
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
