On Fri, 2003-08-29 at 17:22, Ian Romanick wrote: > Eric Anholt wrote: > > > My current diff is at: > > http://people.freebsd.org/~anholt/dri/files/sis-14.diff > > Since building the SiS driver is disabled, I don't see any reason to not > commit your changes. This will allow more adventureous people to start > testing. :)
Hmm. And give up my precious p4 already? Maybe tomorrow. I'm moving back to school Sunday, though, so really I need to be spending my time packing. > > It's against DRI CVS. Should work fine on Linux/FreeBSD, with or > > without sisfb. I haven't tested the linux-without-sisfb case, though. > > > > My progress so far: > > * glxgears, geartrain, tunnel, ipers, fire, multiarb, ray, > > morph3d, isosurf, spectex, gloss, bounce, teapot, reflect all > > work. tuxracer works on FreeBSD. > > * DRM and DDX changes are in DRI CVS HEAD. > > Woohoo! > > > To do: > > * Tuxracer crashes in sisDDDeleteTexture on linux. I have no idea > > why (it's crashing freeing memory which I swear is allocated). > > * 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? /me sticks FOG_COORDINATE fogging on the todo list A screenshot of fire on sis is at: http://people.freebsd.org/~anholt/dri/sis/sisfire.png while one of indirect rendering on the sis box is at: http://people.freebsd.org/~anholt/dri/sis/swfire.png > > * Issues with clipping/scissoring (texenv, tessdemo -- GLUT_SINGLE > > buffering) > > * Implement / advertise GL extensions. > > Just by looking at sis_reg.h, it looks like you should be able to get at > least the following: > > GL_ARB_multitexture > GL_EXT_paletted_texture > GL_EXT_shared_texture_palette > GL_EXT_fog_coord > GL_NV_blend_square > GL_ARB_texture_border_clamp and/or GL_EXT_texture_edge_clamp > GL_ARB_texture_mirrored_repeat / GL_IBM_texture_mirrored_repeat > GL_MESA_ycbcr_texture > GL_EXT_texture_filter_anisotropic > GL_EXT_texture_lod_bias > > If you play with some of the missing values, I bet that the following > are also supportable: > > GL_EXT_stencil_wrap > GL_EXT_blend_logic_op > GL_ARB_texture_env_add (maybe even some of the other env modes) > > At some point we'll want to disect what the various bits of > A_REPLACE_RGB_STAGE0 actually mean. Who knows what will be possible then. > > "Fake" / software support can be added for the following. The only one > that you actually need to do anything for is ARB_texture_compression. > Look at the mga, radeon, r128, or r200 for an example. > > GL_ARB_texture_compression > GL_ARB_multisample > GL_SGIS_generate_mipmap > GL_EXT_multi_draw_arrays 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) > > * 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. On the topic of textures, anyone have anything that uses 1d textures? -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- 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
