[Dri-devel] Planning to merge vtx-0-2-branch soon
OK, I'm planning to merge the vtx-0-2-branch to Mesa CVS trunk fairly shortly. At the moment, it is well tested with the X11 driver, and it compiles with the r200 driver from linux-solo. I'll make sure the r200 driver works properly before merging, but there are a lot of other drivers out there that will be affected by this in larger or smaller ways. The major changes are: - *Much* cleaner vertex handling in tnl module. - Display list compiler suitable for hardware-cached dlists. - Immediate mode code based on r200 vtxfmt code, and suitable for codegen optimizations. - Cleaner integration of VertexAttrib() and normal Color()/Normal() calls. There are a couple of downsides at the moment: - Use of floating point color everywhere has some performance issues. - The expected teething problems. In general, the bugs that I've had with this code have been very easy to track down and fix. I'm looking forward to getting it in as it clears up some of the nastiest code still in Mesa (authorship - mine...). I'm hoping that this will mark the start of doing the driver development in the Mesa tree. Can I ask everyone currently working on the DRI tree to check if they have Mesa CVS permissions if not email me and I'll work it out? Shortly I'll start a DRI branch to investigate building the dri tree with the drivers living under Extras/ with the rest of mesa. Keith --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Planning to merge vtx-0-2-branch soon
Currently all my mergedfb work has been in the 2D driver, but I'd like to start working on some 3d stuff (time permitting). however, I don't have write access to the mesa tree. It's not real important at this point I guess, but eventually... Also isn't mesa hosted on sourceforge? will there be issues with cvs access (not that freedesktop is perfect)? will it all be in one mesa tree or will the DRI have it's own copy in our cvs? Just curious... Alex --- Keith Whitwell [EMAIL PROTECTED] wrote: OK, I'm planning to merge the vtx-0-2-branch to Mesa CVS trunk fairly shortly. At the moment, it is well tested with the X11 driver, and it compiles with the r200 driver from linux-solo. I'll make sure the r200 driver works properly before merging, but there are a lot of other drivers out there that will be affected by this in larger or smaller ways. The major changes are: - *Much* cleaner vertex handling in tnl module. - Display list compiler suitable for hardware-cached dlists. - Immediate mode code based on r200 vtxfmt code, and suitable for codegen optimizations. - Cleaner integration of VertexAttrib() and normal Color()/Normal() calls. There are a couple of downsides at the moment: - Use of floating point color everywhere has some performance issues. - The expected teething problems. In general, the bugs that I've had with this code have been very easy to track down and fix. I'm looking forward to getting it in as it clears up some of the nastiest code still in Mesa (authorship - mine...). I'm hoping that this will mark the start of doing the driver development in the Mesa tree. Can I ask everyone currently working on the DRI tree to check if they have Mesa CVS permissions if not email me and I'll work it out? Shortly I'll start a DRI branch to investigate building the dri tree with the drivers living under Extras/ with the rest of mesa. Keith __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Planning to merge vtx-0-2-branch soon
Alex Deucher wrote: Currently all my mergedfb work has been in the 2D driver, but I'd like to start working on some 3d stuff (time permitting). however, I don't have write access to the mesa tree. It's not real important at this point I guess, but eventually... Also isn't mesa hosted on sourceforge? will there be issues with cvs access (not that freedesktop is perfect)? will it all be in one mesa tree or will the DRI have it's own copy in our cvs? Just curious... A lot of these are open questions. The DRI tree could be set up so that it points to a Mesa tree which can be used to track Mesa cvs directly. I'm not sure whether that will be helpful or necessary, though it would make sense for the snapshots to be built this way. We could set up the DRI tree to have *some* version of Mesa plus drivers installed actually in the tree. One problem with this is it possibly extends the chain to the user - Mesa-DRI-Xfree86-Distro-user... (Actually Mesa updates have to go through this route already) Ideally I'd like to see something closer to Mesa-Distro-user, allowing driver updates to make it into general users hands a lot quicker. We do have snapshots, but the distros are still the main way of getting code into users hands, and we should try streamline that path. It's necessary to ask 'what is the DRI tree for?' - what are we still developing there? There is your 2d work, which is somewhat of an exception, but also - libGL.so - The DRI protocol. - The dri glx XFree86 modules - The DRI-aware parts of the DDX drivers. I'm not sure how easy it will be to get updates into XFree86 compared to the past when regular merges took place. This could mean that the DRI tree either becomes more or less important over time... Keith --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
