Hello S3 Savage users, The most basic grunt work on the Savage 3D driver has been done in the last three months. The driver was ported to Mesa 5 and support for the Savage3D chip family was added. The result is available in CVS on the savage-2-0-0-branch in DRI CVS. Now I consider the driver pretty stable as far as lockups are concerned, a good point for starting to turn it inside out, break things and make life more interesting for testers. :-P
I'm outlining my plans for the Savage 3D driver so that testers know what to expect and people who wish to help out get an idea what needs to be done. I'm not going to specify any deadlines since everything depends on how much spare time I (and/or others) have. I'm going to spend more time on it than I should anyway. ;-) >From the list below I'm going to do (1) and (2) pretty soon. Basically I'd like to do all of this, all at the same time, if I could. But I have other things that need attention too. So anybody who has some spare time and interest, let us ([EMAIL PROTECTED]) know what you're working on to avoid duplicate work and feel free to submit patches. IRC meetings every monday would be another good oportunity to discuss issues and coordinate our work. Independently of the issues below the 3D driver should move be ported to the latest Mesa development version and move to the Mesa CVS repository. I'm not sure yet when would be a good time for that. However, we should try not to fall too far behind Mesa CVS. The longer we wait the more painful the porting will be. Don't hesitate to ask questions if something is unclear from the statements below. Comments are welcome. Best regards, Felix -------------------------------------------------------------------------- 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. * ... ------------------------------------------------------- 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
