--- Felix Kühling <[EMAIL PROTECTED]> wrote: > Hello S3 Savage users, > [snip]
Felix, I'd like to give you a hand on the 3D driver while I still have some free time, but I have to admit, I'm somewhat intimidated. What's a good task that I can work on to get my feet wet on the 3D side? It's probably not too much more complicated than the 2D side. Gotta do it sometime... Thanks, Alex > -------------------------------------------------------------------------- > > 0. Low hanging bugs (more or less) > > - flat shading on Savage3D > - disable hardware culling for lines and points > - fix texture environments on Savage3D > - fix texture wrapping on Savage3D > - fix LOD bias > > 1. State management cleanup > > The whole state and texture management needs a big cleanup. There are > a > few global function pointers that I added (shame on me) that should > be > in the context. I'm not happy with how the driver is hooked up to > mesa > callbacks right now. They don't map well to how the various state > bits > are layed out in registers on the Savages. Also, currently, in some > situations, registers will be copied to the hardware even if nothing > changed. I'll see how other drivers handle this. I remember seeing > something in a cvs log about similar changes in the MGA driver. > > 2. Texture cleanup > > Color depth conversion can be done by Mesa. Right now it is done by > the > driver on texture upload time. The tiling can be reimplemented more > optimally. Also the tiling of small mipmap levels is broken ATM. > > Ian suggested to add tiled texture format support to Mesa. This would > be > a big chunk of work. I'm not considering it a priority now. > > 3. Separate commands and data > > Right now commands and data are submitted to the chip as one data > stream, either via the BCI or via DMA buffers. For easier security > checking command and data streams should be separated. Savage chips > can > handle vertex buffers and indexed drawing commands. I couldn't find a > way to specify the vertex format for indexed drawing commands. Either > it > is automagically deduced from various state bits (specular and > enabled > texture units come to mind) or vertices vertex buffers are always > complete. This would also mean that their format differs between > Savage3D and Savage4 since the Savage3D has only one texture unit. > These > are things that I'dd have to find out by experiment. But maybe > someone > happens to know it or has better documentation than I do. > > 4. Move hardware access to the kernel module > > The following functions should be moved into the kernel module. > > - clear > - swap > - vertex (DMA) buffer management > - drawing commands > - emitting and waiting for events > > While this is happening the sarea layout and the ioctl interface will > change a lot. Versioning should be used so that the driver can detect > an > incompatible kernel module instead of crashing badly and to avoid > unreproducable bug reports. Binary compatibility in any direction is > not > an issue as long as the driver is not officially released. > > 5. Cliprects > > At the moment the driver honors cliprects on clears and buffer swaps > but > not for drawing commands. This needs to be added in the kernel > module, > once drawing command submission is handled by the kernel. > > ------------------------------------------------------------------------- > > At this point the driver should be ready for inclusion in an XFree86 > release. So stabilization and bug fixing would be important to make > it > happen. After that there is enough room for performance improvements > and > for adding new features. Here are a few things that came to mind > spontaneously: > > * IRQs > > At least Savage4 and later can emit IRQs on all sorts of events. They > can be used to implement idle waiting to reduce CPU usage. > > * Page Flipping > > Savage4 and later support page flipping, probably synchronized with > the > retrace, since there is a "page pending" bit in a status register. > The > current driver supports and ancient fullscreen mode, but I think this > is > no longer used by Mesa or any application I know of. Anyway, it is > documentation for how the hardware must be programmed. There is also > an > interesting feature called "automatic Z clear" that can be used > together > with page flipping. > > * Configuration support > > Trivial. > > * Extensions > > Pick your favourite one and implement it. ;-) The Wiki mentions > MESA_ycbcr_texture and bump mapping for example. > > * ... > > > __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
