Re: [Dri-devel] dri driver features page -> website in CVS
> You could set up a dummy database for testing? Yes I could, for teh meomnt I installed apache and php, apache works, php doesn't, if I get php working then I'll see about a database. > So, which files in doc/ should go into CVS? At a quick glance, only the > files in the doc/ directory itself and the images directory; the faq and > howto directories are generated, right? IIRC those are Jose's, ask him. cheers Liam --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page -> website in CVS
On Friday 14 March 2003 05:50 am, you wrote: > On Don, 2003-03-13 at 20:49, Smitty wrote: > > > > If I can do a CVS commit when I've been changing things on the webserver > > from the webserver that would be good. > > You can, but that should be the exception because otherwise the only > improvement over the current situation is that there's a backup in the > CVS repository. > > > > > Don't you have a local web server setup you can test with? > > No. Besides even if I setup apache on my local machine I'd still have to > > set up a database like the one used for the FAQ on sf.net > > You could set up a dummy database for testing? Setting up mysql is not hard at all. Also, you can do mysqldump to get the actual data from the sf server, and pipe it right into your own to test with a snapshot of the real data. Nick --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page -> website in CVS
On Don, 2003-03-13 at 20:49, Smitty wrote: > > If I can do a CVS commit when I've been changing things on the webserver > from the webserver that would be good. You can, but that should be the exception because otherwise the only improvement over the current situation is that there's a backup in the CVS repository. > > Don't you have a local web server setup you can test with? > No. Besides even if I setup apache on my local machine I'd still have to > set up a database like the one used for the FAQ on sf.net You could set up a dummy database for testing? > > > I've thought about it a bit more and think that putting just /doc into > > > CVS may be a good idea, the other files either don't change or are > > > only changed by one person at a time / ever. > > > > Sounds good to me, we can always add more later. So we create a module > > called website or whatever containing a doc directory? Anyone, or shall > > I? > I have no objections, btw bear in mind that I managed to delete my local > copy of dri/htdocs/ while converting to ResierFS and house cleaning so try > not to mess it up. I always try to be careful. So, which files in doc/ should go into CVS? At a quick glance, only the files in the doc/ directory itself and the images directory; the faq and howto directories are generated, right? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page -> website in CVS
> I'm not sure what you mean here. If you cvs commit on the webserver, the > only bandwidth you need is for the I/O on your terminal. The CVS > protocol traffic is only between the machine you are logged in on and > the machine the CVS repository is on, both sf.net. And even if you > commit directly from your own machine, CVS doesn't take a lot of > bandwidth, very likely less than downloading the website as a tarball. I think I should rephrase / restate what I said: If I can do a CVS commit when I've been changing things on the webserver from the webserver that would be good. > Don't you have a local web server setup you can test with? No. Besides even if I setup apache on my local machine I'd still have to set up a database like the one used for the FAQ on sf.net > > Well I'm not really opposed to this, so what exactly would this > > involve(getting it into CVS and then d/l'ing, updating, committing, > > etc)? > > Creating a new module in CVS, adding the files to it and then checking > it out on the web server. I know what you're describing, I just don't have any idea how to do it yet. > > I've thought about it a bit more and think that putting just /doc into > > CVS may be a good idea, the other files either don't change or are > > only changed by one person at a time / ever. > > Sounds good to me, we can always add more later. So we create a module > called website or whatever containing a doc directory? Anyone, or shall > I? I have no objections, btw bear in mind that I managed to delete my local copy of dri/htdocs/ while converting to ResierFS and house cleaning so try not to mess it up. cheers Liam --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page -> website in CVS
> Maybe this is a radical proposal, but it's a thing I've made good > experience with, over the last few months. > > http://twiki.org > > It is probably not the right thing if you want a perfectly styled > corporate web site. But it is an easy way for everybody to keep > documentation up-to-date. The documents are managed by rcs on the web > server. Contrary to other Wikis it allows restricting write access to > registered and authorized users. For a practical example, the TWiki I > installed can be found at: > > http://g7-mac3.fy.chalmers.se/cgi-bin/twiki/view/Forte/WebHome I haven't looked at it D*mn it man, we're looking for evolution, not revolution! Seriously though this is only being done because the developers update dri_driver_features.phtml and they don't want changes to get lost (apparently this is dangerous). I think the website is coping very well. But then again I'm as biased as they come. Liam it depends --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page -> website in CVS
Maybe this is a radical proposal, but it's a thing I've made good experience with, over the last few months. http://twiki.org It is probably not the right thing if you want a perfectly styled corporate web site. But it is an easy way for everybody to keep documentation up-to-date. The documents are managed by rcs on the web server. Contrary to other Wikis it allows restricting write access to registered and authorized users. For a practical example, the TWiki I installed can be found at: http://g7-mac3.fy.chalmers.se/cgi-bin/twiki/view/Forte/WebHome Regards, Felix On 13 Mar 2003 21:07:51 +0100 Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Don, 2003-03-13 at 16:05, Smitty wrote: > > > > > > I'd rather not use CVS myself just for the website, when I mess up a > > > > single character I just ssh onto the webserver and use vi to change > > > > it. > > > > > > > > Also when something is being considered I like to test it / play with > > > > and update a page repeatedly while hitting the refresh button. > > > > > > You can still do that, you just do a cvs commit when you're done. > > >From the webserver? Because that wouldn't be too onerous (dialup is > > plently slow with plenty lag). > > I'm not sure what you mean here. If you cvs commit on the webserver, the > only bandwidth you need is for the I/O on your terminal. The CVS > protocol traffic is only between the machine you are logged in on and > the machine the CVS repository is on, both sf.net. And even if you > commit directly from your own machine, CVS doesn't take a lot of > bandwidth, very likely less than downloading the website as a tarball. > > > > > Ideally though, you'd only make changes in your private checkout, commit > > > when you're done and then bring the public site up to date with cvs up > > > (which we might be able to automate somehow). > > Tie updating the website to the commit? > > Yes, either directly or via a cronjob. > > > I don't see how that would work, I pretty much have to see it served up > > by the webserver to know when its right. > > Don't you have a local web server setup you can test with? > > > > Well I'm not really opposed to this, so what exactly would this involve > > (getting it into CVS and then d/l'ing, updating, committing, etc)? > > Creating a new module in CVS, adding the files to it and then checking > it out on the web server. > > > I've thought about it a bit more and think that putting just /doc into CVS > > may be a good idea, the other files either don't change or are only > > changed by one person at a time / ever. > > Sounds good to me, we can always add more later. So we create a module > called website or whatever containing a doc directory? Anyone, or shall > I? > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page -> website in CVS
On Don, 2003-03-13 at 16:05, Smitty wrote: > > > > I'd rather not use CVS myself just for the website, when I mess up a > > > single character I just ssh onto the webserver and use vi to change > > > it. > > > > > > Also when something is being considered I like to test it / play with > > > and update a page repeatedly while hitting the refresh button. > > > > You can still do that, you just do a cvs commit when you're done. > >From the webserver? Because that wouldn't be too onerous (dialup is > plently slow with plenty lag). I'm not sure what you mean here. If you cvs commit on the webserver, the only bandwidth you need is for the I/O on your terminal. The CVS protocol traffic is only between the machine you are logged in on and the machine the CVS repository is on, both sf.net. And even if you commit directly from your own machine, CVS doesn't take a lot of bandwidth, very likely less than downloading the website as a tarball. > > Ideally though, you'd only make changes in your private checkout, commit > > when you're done and then bring the public site up to date with cvs up > > (which we might be able to automate somehow). > Tie updating the website to the commit? Yes, either directly or via a cronjob. > I don't see how that would work, I pretty much have to see it served up > by the webserver to know when its right. Don't you have a local web server setup you can test with? > Well I'm not really opposed to this, so what exactly would this involve > (getting it into CVS and then d/l'ing, updating, committing, etc)? Creating a new module in CVS, adding the files to it and then checking it out on the web server. > I've thought about it a bit more and think that putting just /doc into CVS > may be a good idea, the other files either don't change or are only > changed by one person at a time / ever. Sounds good to me, we can always add more later. So we create a module called website or whatever containing a doc directory? Anyone, or shall I? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page -> website in CVS
> We don't need to put everything into CVS right away, but the way several > people are editing the same files right now is dangerous. Somewhat, at least it makes life interesting. > > I'd rather not use CVS myself just for the website, when I mess up a > > single character I just ssh onto the webserver and use vi to change > > it. > > > > Also when something is being considered I like to test it / play with > > and update a page repeatedly while hitting the refresh button. > > You can still do that, you just do a cvs commit when you're done. >From the webserver? Because that wouldn't be too onerous (dialup is plently slow with plenty lag). > Ideally though, you'd only make changes in your private checkout, commit > when you're done and then bring the public site up to date with cvs up > (which we might be able to automate somehow). Tie updating the website to the commit? I don't see how that would work, I pretty much have to see it served up by the webserver to know when its right. > Of course. :) You're basically emulating parts of the functionality of > CVS with other tools. Well I'm not really opposed to this, so what exactly would this involve (getting it into CVS and then d/l'ing, updating, committing, etc)? I've thought about it a bit more and think that putting just /doc into CVS may be a good idea, the other files either don't change or are only changed by one person at a time / ever. cheers Liam --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page -> website in CVS
On Mit, 2003-03-12 at 23:15, Smitty wrote: > > > PS: Editing files like this makes me kind of nervous, we should really > > > work out a way to handle the website in CVS. > > > > What's the difficulty in having it in CVS? it's extremely trivial to set > > up, you just tell the web server to cvs up from the repository every few > > hours or so. > > The website as a whole is rather large, We don't need to put everything into CVS right away, but the way several people are editing the same files right now is dangerous. > I'd rather not use CVS myself just for the website, when I mess up a > single character I just ssh onto the webserver and use vi to change it. > > Also when something is being considered I like to test it / play with and > update a page repeatedly while hitting the refresh button. You can still do that, you just do a cvs commit when you're done. Ideally though, you'd only make changes in your private checkout, commit when you're done and then bring the public site up to date with cvs up (which we might be able to automate somehow). > When it's right I .tar.gz and download it, to sync my local copy up with > the active copy. > > All very useful. I'm not a CVS expert so I don't know if you can keep all > this functionality alive. Of course. :) You're basically emulating parts of the functionality of CVS with other tools. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri driver features page -> website in CVS
> > PS: Editing files like this makes me kind of nervous, we should really > > work out a way to handle the website in CVS. > > What's the difficulty in having it in CVS? it's extremely trivial to set > up, you just tell the web server to cvs up from the repository every few > hours or so. The website as a whole is rather large, although it is now a heck of a lot smaller after I did some major house cleaning in the last month. These spring to mind: res/ snapshots/ I'm interested in what you say about putting the website in CVS as it should make it easier for developers, who use CVS all the time. But if I'm uploading / editing files on the webserver how is CVS going to remain synced with my newest changes? I'd rather not use CVS myself just for the website, when I mess up a single character I just ssh onto the webserver and use vi to change it. Also when something is being considered I like to test it / play with and update a page repeatedly while hitting the refresh button. I tweak the page like this because many pages have their headers / footers / style sheets added on the server via PHP, and so look very different when they are actually served up. When it's right I .tar.gz and download it, to sync my local copy up with the active copy. All very useful. I'm not a CVS expert so I don't know if you can keep all this functionality alive. Liam it depends --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
Ian Romanick wrote: Brian Paul wrote: Leif Delgass wrote: Add to list: --- GL_ARB_multisample - R200, R100, mga (What's necessary for a driver to support this?) I wouldn't advertise support for GL_ARB_multisample until it really works. The OpenGL spec allows one to support the entrypoints without really implementing the feature (sort of like texture compression). It's not trivial to implement and I'm not sure we even have the technical information needed for doing it with the ATI chips. The "implementation" in the drivers is "correct" and is required to advertise 1.3. The real problem is that GLX support isn't there. There's no support in glXChooseVisual or glXGetConfig (and in any of the supporting infrastructure) for the multisample enums. There's a couple other problems. In any case, I'm working on fixing the GLX support. The point I was trying to make is that if we advertise GL_ARB_multisample in the features table people are likely to think they can do full-scene antialiasing by multisampling with those drivers - and that's not true. Perhaps change the table entry from "GL_ARB_multisample" to just "multisampling" (and report "no"). -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Sunday 09 March 2003 21:11, Michel Dänzer wrote: > PS: Editing files like this makes me kind of nervous, we should really > work out a way to handle the website in CVS. What's the difficulty in having it in CVS? it's extremely trivial to set up, you just tell the web server to cvs up from the repository every few hours or so. - -- Cheers, Chris Howells -- [EMAIL PROTECTED], [EMAIL PROTECTED] Web: http://chrishowells.co.uk, PGP ID: 33795A2C KDE: http://www.koffice.org, http://printing.kde.org, http://usability.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+a7JPF8Iu1zN5WiwRAg0VAJ96BHh6hmDR77uWbE3n3i735xmZaQCgo/qN huY9AmbPkyUxYhg4Iuf9g/c= =5dyE -END PGP SIGNATURE- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
I just made some changes: * the r200 driver works pretty well on PPC here :) * changed the comment about the Radeon drivers on x86 from 'AGP only' to 'PCI cards require Option "ForcePCIMode"' (which takes quite a lot of space, better ideas?) * removed the bogus paragraph about the r128 driver not supporting PCI GART PS: Editing files like this makes me kind of nervous, we should really work out a way to handle the website in CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
Brian Paul wrote: Leif Delgass wrote: Add to list: --- GL_ARB_multisample - R200, R100, mga (What's necessary for a driver to support this?) I wouldn't advertise support for GL_ARB_multisample until it really works. The OpenGL spec allows one to support the entrypoints without really implementing the feature (sort of like texture compression). It's not trivial to implement and I'm not sure we even have the technical information needed for doing it with the ATI chips. The "implementation" in the drivers is "correct" and is required to advertise 1.3. The real problem is that GLX support isn't there. There's no support in glXChooseVisual or glXGetConfig (and in any of the supporting infrastructure) for the multisample enums. There's a couple other problems. In any case, I'm working on fixing the GLX support. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
On Sat, 8 Mar 2003, Nicholas Leippe wrote: > On Saturday 08 March 2003 05:02 pm, Leif Delgass wrote: > > BTW, I changed the PHP tags from ' > since the short versions didn't work when testing on my local system with > > PHP 4.1.2, and the PHP docs indicate the short versions are deprecated > > since they don't work well with XHTML. > > Good catch. I didn't know that. > > > Some other enhancements I thought of that could be made: > > - show only the driver notes for the currently selected driver > > I see someone did this and someone also made the chip titles links to the > details below like the original page. Much nicer, thanks. Yeah, I added those. I also cleaned up a couple things to get it to validate as transitional HTML 4.01. > > - have extensions default to "no" unless they are specified for a > > particular driver. That would make editing/adding extensions easier. > > Sure--doesn't really matter too much. > > I noticed that R200 lists the Radeon 9000. This is actually an R250 part > iirc. If it's the same driver, should we change R200 to say R200/R250 ? > They are similar, but not identical of course. Well, afaik Radeon 9000 and Radeon Mobility M9 work with the r200 driver. ATI recently announced a Radeon 9200 (RV280?) as well, which looks like it may work too, since I think it will be just a higher clocked 9000 with AGP 8x. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
On Saturday 08 March 2003 05:02 pm, Leif Delgass wrote: > BTW, I changed the PHP tags from ' since the short versions didn't work when testing on my local system with > PHP 4.1.2, and the PHP docs indicate the short versions are deprecated > since they don't work well with XHTML. Good catch. I didn't know that. > Some other enhancements I thought of that could be made: > - show only the driver notes for the currently selected driver I see someone did this and someone also made the chip titles links to the details below like the original page. Much nicer, thanks. > - have extensions default to "no" unless they are specified for a > particular driver. That would make editing/adding extensions easier. Sure--doesn't really matter too much. I noticed that R200 lists the Radeon 9000. This is actually an R250 part iirc. If it's the same driver, should we change R200 to say R200/R250 ? They are similar, but not identical of course. Nick --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
On Sat, 8 Mar 2003, Brian Paul wrote: [snip] > > GL_ARB_multisample - R200, R100, mga (What's necessary for a driver to > > support this?) > > I wouldn't advertise support for GL_ARB_multisample until it really works. > The OpenGL spec allows one to support the entrypoints without really > implementing the feature (sort of like texture compression). > > It's not trivial to implement and I'm not sure we even have the technical > information needed for doing it with the ATI chips. OK. So it sounds like this should be #ifdef'ed out in the radeon, r200 and mga drivers. [snip] > > There are a couple of other minor changes I had made to the version of the > > table on the DRI site that aren't reflected in the dynamic version. The > > attached version has these edits and those above (at least the ones I was > > sure about). > > > > BTW, I changed the PHP tags from ' > since the short versions didn't work when testing on my local system with > > PHP 4.1.2, and the PHP docs indicate the short versions are deprecated > > since they don't work well with XHTML. > > > > Some other enhancements I thought of that could be made: > > - show only the driver notes for the currently selected driver > > - have extensions default to "no" unless they are specified for a > > particular driver. That would make editing/adding extensions easier. > > > Feel free to incorporate your changes and make the page "live". I don't want > to be the sole gatekeeper for this info/webpage. > > At the top where it says "Select drivers to view" you might point out that one > can use shift-click to select multiple entries. > > Finally, a notice that this table reflects the latest code in CVS, and not > necesarily the drivers in XFree86 4.3 or RH8, etc., might be wise. > > -Brian OK, I've added the disclaimer and the note about selecting multiple drivers. I also implemented my suggestion about only showing the appropriate driver notes when a subset is selected (I'm a PHP newb, but it seems to work. :) ). I've also added back the anchor links to the driver notes on the chip names at the top of the table. I commented out the line that prints the ARB_multisample line for now. The dynamic page is now live with these changes. I changed the link on the status page to the new phtml page. The original flat HTML file is still in /doc as dri_driver_features.html.orig -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
Leif Delgass wrote: On Sat, 8 Mar 2003, Brian Paul wrote: Nicholas Leippe wrote: On Thursday 06 March 2003 08:26 am, Suzy Deffeyes wrote: Who is the audience for the table? Is it the end user checking to see if a feature is available and/or has some form of HW acceleration? Or is the audience the DRI developer, looking to see what pieces need implementing? That might dictate how much you put in the table, especially color coding. That's a very good question that I didn't have the answer to when I reworked it. I'm still not sure. I get the impression from what Brian has said that he feels it's more for the end user (gl app programmer) to let them know whether a feature is available for use since he doesn't care to distinguish any further. I would prefer to at least distinguishing between hw and sw support, but it's Brian's baby. :) I think that if you want to get into more detail about hw vs. sw features, etc that it should be put below in the "Driver-specific Notes" section below. But if someone feels strongly about it and will do all the work to do something fancier, that's fine. I just don't have time for it. Nice looking table, I like it. Thanks. So, how do I install it on the Mesa site? Just copy the dri_driver_features.phtml file? That doesn't seem to work. I don't know anything about dynamic html or html widgets. -Brian First off, good work Nicholas! I did a survey of the extensions exported by the drivers in the trunk and texmem branches and found a few edits/corrections that I made in the attached revision, and I also have a few questions. You can see the dynamic version with my edits on the DRI site here (note that it's not linked to from the live pages): http://dri.sourceforge.net/doc/dri_driver_features_new.phtml Changes: Add to list: --- GL_ARB_multisample - R200, R100, mga (What's necessary for a driver to support this?) I wouldn't advertise support for GL_ARB_multisample until it really works. The OpenGL spec allows one to support the entrypoints without really implementing the feature (sort of like texture compression). It's not trivial to implement and I'm not sure we even have the technical information needed for doing it with the ATI chips. GL_ARB/SGIS_texture_border_clamp - R200 (texmem), R100 GL_EXT/SGIS_texture_edge_clamp - R200, R100 (texmem) GL_ATI_texture_mirror_once - R200, R100 GL_NV_blend_square - R200, R100 Modifications: - GL_ARB_texture_mirrored_repeat - R200 YES, R128 YES (texmem) GL_EXT_stencil_wrap - i830 NO (currently disabled with #if 0) GL_SGIS_generate_mipmap - R200 YES GL_EXT_blend_function_separate - should be GL_EXT_blend_func_separate Should R128 export GL_EXT_texture_lod_bias? The driver supports it but it seems from the comment in r128_tex.c that scaling of the bias param might not be quite correct. The mga driver in the texmem branch exports these now, but are they really supported?: GL_EXT_fog_coord, GL_EXT_secondary_color, GL_EXT_stencil_wrap There are a couple of other minor changes I had made to the version of the table on the DRI site that aren't reflected in the dynamic version. The attached version has these edits and those above (at least the ones I was sure about). BTW, I changed the PHP tags from ' Some other enhancements I thought of that could be made: - show only the driver notes for the currently selected driver - have extensions default to "no" unless they are specified for a particular driver. That would make editing/adding extensions easier. Feel free to incorporate your changes and make the page "live". I don't want to be the sole gatekeeper for this info/webpage. At the top where it says "Select drivers to view" you might point out that one can use shift-click to select multiple entries. Finally, a notice that this table reflects the latest code in CVS, and not necesarily the drivers in XFree86 4.3 or RH8, etc., might be wise. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
On Sat, 8 Mar 2003, Brian Paul wrote:
> Nicholas Leippe wrote:
> > On Thursday 06 March 2003 08:26 am, Suzy Deffeyes wrote:
> >
> >>Who is the audience for the table? Is it the end user checking to see if a
> >>feature is available and/or has some form of HW acceleration? Or is the
> >>audience the DRI developer, looking to see what pieces need implementing?
> >>That might dictate how much you put in the table, especially color coding.
> >
> >
> > That's a very good question that I didn't have the answer to when I reworked
> > it. I'm still not sure. I get the impression from what Brian has said that
> > he feels it's more for the end user (gl app programmer) to let them know
> > whether a feature is available for use since he doesn't care to distinguish
> > any further.
> >
> > I would prefer to at least distinguishing between hw and sw support, but it's
> > Brian's baby. :)
>
> I think that if you want to get into more detail about hw vs. sw features, etc
> that it should be put below in the "Driver-specific Notes" section below. But
> if someone feels strongly about it and will do all the work to do something
> fancier, that's fine. I just don't have time for it.
>
>
> >> Nice looking table, I like it.
> >
> >
> > Thanks.
>
> So, how do I install it on the Mesa site? Just copy the
> dri_driver_features.phtml file? That doesn't seem to work. I don't know
> anything about dynamic html or html widgets.
>
> -Brian
First off, good work Nicholas!
I did a survey of the extensions exported by the drivers in the trunk and
texmem branches and found a few edits/corrections that I made in the
attached revision, and I also have a few questions. You can see
the dynamic version with my edits on the DRI site here (note that it's
not linked to from the live pages):
http://dri.sourceforge.net/doc/dri_driver_features_new.phtml
Changes:
Add to list:
---
GL_ARB_multisample - R200, R100, mga (What's necessary for a driver to
support this?)
GL_ARB/SGIS_texture_border_clamp - R200 (texmem), R100
GL_EXT/SGIS_texture_edge_clamp - R200, R100 (texmem)
GL_ATI_texture_mirror_once - R200, R100
GL_NV_blend_square - R200, R100
Modifications:
-
GL_ARB_texture_mirrored_repeat - R200 YES, R128 YES (texmem)
GL_EXT_stencil_wrap - i830 NO (currently disabled with #if 0)
GL_SGIS_generate_mipmap - R200 YES
GL_EXT_blend_function_separate - should be GL_EXT_blend_func_separate
Should R128 export GL_EXT_texture_lod_bias? The driver supports it but it
seems from the comment in r128_tex.c that scaling of the bias param might
not be quite correct.
The mga driver in the texmem branch exports these now, but are they really
supported?:
GL_EXT_fog_coord, GL_EXT_secondary_color, GL_EXT_stencil_wrap
There are a couple of other minor changes I had made to the version of the
table on the DRI site that aren't reflected in the dynamic version. The
attached version has these edits and those above (at least the ones I was
sure about).
BTW, I changed the PHP tags from 'http://www.retinalburn.net
\n";
echo "$label\n";
coloredRowData($member);
echo " \n";
}
function coloredRowData($member) {
global $drivers;
reset($drivers);
foreach ($drivers as $vendor => $chips) {
foreach ($chips as $chip => $d) {
echo "$member);
echo ">";
echo $d->$member;
echo "\n";
}
}
}
function row($label, $member, $tdflags = 0) {
echo " \n";
echo "$label\n";
rowData($member, $tdflags);
echo " \n";
}
function rowData($member, $tdflags = 0) {
global $drivers;
reset($drivers);
foreach ($drivers as $vendor => $chips) {
foreach ($chips as $chip => $d) {
echo "";
echo $d->$member;
echo "\n";
}
}
}
/*
*
* Template
*
/
/* template
$allDrivers_["vendor"]["chip"] = new Driver;
addDriver("vendor", "chip");
$d = &$allDrivers_["vendor"]["chip"];
$d->exampleCards = "";
$d->primaryAuthors= "";
$d->oses = "";
$d->archX86 = "";
$d->archAlpha = "";
$d->archPowerPC = "";
$d->driverName= "";
$d->kernelModule = "";
$d->xfree86_2d_driver = "";
$d->hardwareStencil = "";
$d->hardwareAlphaChannel = "";
$d->hardwareTCL = "";
$d->GL_ARB_multisample= "";
$d->GL_ARB_multitexture = "";
$d->GL_ARBSGIS_texture_bor
Re: [Dri-devel] dri driver features page
On Saturday 08 March 2003 11:25 am, you wrote: > I think that if you want to get into more detail about hw vs. sw features, etc > that it should be put below in the "Driver-specific Notes" section below. But > if someone feels strongly about it and will do all the work to do something > fancier, that's fine. I just don't have time for it. Well, I wouldn't mind, but I really don't know enough to be able to do so. We can just leave it how it is--it's useful enough already. > So, how do I install it on the Mesa site? Just copy the > dri_driver_features.phtml file? That doesn't seem to work. I don't know > anything about dynamic html or html widgets. Just copy it over and change the spelling on the link to it on the status page from .html to .phtml. That should do it. Nick --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
Nicholas Leippe wrote: On Thursday 06 March 2003 08:26 am, Suzy Deffeyes wrote: Who is the audience for the table? Is it the end user checking to see if a feature is available and/or has some form of HW acceleration? Or is the audience the DRI developer, looking to see what pieces need implementing? That might dictate how much you put in the table, especially color coding. That's a very good question that I didn't have the answer to when I reworked it. I'm still not sure. I get the impression from what Brian has said that he feels it's more for the end user (gl app programmer) to let them know whether a feature is available for use since he doesn't care to distinguish any further. I would prefer to at least distinguishing between hw and sw support, but it's Brian's baby. :) I think that if you want to get into more detail about hw vs. sw features, etc that it should be put below in the "Driver-specific Notes" section below. But if someone feels strongly about it and will do all the work to do something fancier, that's fine. I just don't have time for it. Nice looking table, I like it. Thanks. So, how do I install it on the Mesa site? Just copy the dri_driver_features.phtml file? That doesn't seem to work. I don't know anything about dynamic html or html widgets. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
On Thursday 06 March 2003 08:26 am, Suzy Deffeyes wrote: > Who is the audience for the table? Is it the end user checking to see if a > feature is available and/or has some form of HW acceleration? Or is the > audience the DRI developer, looking to see what pieces need implementing? > That might dictate how much you put in the table, especially color coding. That's a very good question that I didn't have the answer to when I reworked it. I'm still not sure. I get the impression from what Brian has said that he feels it's more for the end user (gl app programmer) to let them know whether a feature is available for use since he doesn't care to distinguish any further. I would prefer to at least distinguishing between hw and sw support, but it's Brian's baby. :) > Nice looking table, I like it. Thanks. Nick --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
> I was thinking it would be nice to color code it even more and add a legend > to distinguish at least the following states: > >++ > given a | the chip has hw support | > feature: +--+-+ >| Y | N | > ---++++--+--+ > the driver | hw | sw | no | sw | no | > supports |||| | | > ---++++--+--+ > case 1 23 4 5 > Perhaps: > 1 green --nothing else to be done, and optimal > 2 pink or yellow --indicate work to be done > 3 yellow or red --indicate work to be done > 4 light green--nothing else can be done, but not as good as hw > 5 white? --indicate no work can be/to be done? > Who is the audience for the table? Is it the end user checking to see if a feature is available and/or has some form of HW acceleration? Or is the audience the DRI developer, looking to see what pieces need implementing? That might dictate how much you put in the table, especially color coding. Nice looking table, I like it. Suzy --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page
Nicholas Leippe wrote: Brian, I scratched an itch and made this dynamic. You can see it at: http://lfm.sourceforge.net/dritest/dri_driver_features.phtml and of course grab it if you want from: /home/groups/l/lf/lfm/htdocs/dritest/dri_driver_features.phtml Neat - I like it. I was thinking it would be nice to color code it even more and add a legend to distinguish at least the following states: ++ given a | the chip has hw support | feature: +--+-+ | Y | N | ---++++--+--+ the driver | hw | sw | no | sw | no | supports |||| | | ---++++--+--+ case 1 23 4 5 Right now as it is, the page is ambiguous between 1,2 and 4, and between 3 and 5. (1) might even have two colors--one for yes, the other to indicate some exception such as mutual exclusion with some other feature such as fog and alpha or other specific limitations. This can get complicated. Sometimes a feature like GL_ARB_texture_env_combine can be partially implemented in hardware, but not fully. Sometimes we have to fall back to software because of a completely unrelated reason, like not having polygon smoothing in hardware. As far as color scheme, I really don't care too much, but the colors make it a lot easier to visualize. Perhaps: 1 green --nothing else to be done, and optimal 2 pink or yellow --indicate work to be done 3 yellow or red --indicate work to be done 4 light green--nothing else can be done, but not as good as hw 5 white? --indicate no work can be/to be done? I don't intend for this to be overly granular, no sense in creating anything more to maintain. I'm actually content with the table as-is in this regard. Either we have a feature or we don't. Sometimes a footnote will indicate that the feature is always done in software. The more complicated the table is, the less likely I'm going to bother updating it, unfortunately. I also hope you find the underlying code a little bit easier to read and maintain than the static html table was. My main itch was to eliminate the nasty horizontal scrolling. By only selecting the cards I care about that's now easy. I haven't looked at the code behind the dynamic table. I'll try to get to it later. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri driver features page
Brian, I scratched an itch and made this dynamic. You can see it at: http://lfm.sourceforge.net/dritest/dri_driver_features.phtml and of course grab it if you want from: /home/groups/l/lf/lfm/htdocs/dritest/dri_driver_features.phtml I was thinking it would be nice to color code it even more and add a legend to distinguish at least the following states: ++ given a | the chip has hw support | feature: +--+-+ | Y | N | ---++++--+--+ the driver | hw | sw | no | sw | no | supports |||| | | ---++++--+--+ case 1 23 4 5 Right now as it is, the page is ambiguous between 1,2 and 4, and between 3 and 5. (1) might even have two colors--one for yes, the other to indicate some exception such as mutual exclusion with some other feature such as fog and alpha or other specific limitations. As far as color scheme, I really don't care too much, but the colors make it a lot easier to visualize. Perhaps: 1 green --nothing else to be done, and optimal 2 pink or yellow --indicate work to be done 3 yellow or red --indicate work to be done 4 light green--nothing else can be done, but not as good as hw 5 white? --indicate no work can be/to be done? I don't intend for this to be overly granular, no sense in creating anything more to maintain. I also hope you find the underlying code a little bit easier to read and maintain than the static html table was. My main itch was to eliminate the nasty horizontal scrolling. By only selecting the cards I care about that's now easy. Nick --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
