Re: [Dri-devel] Website update needed...
Someone should really fix this so it no longer refers to the sourceforge CVS server: http://dri.sourceforge.net/doc/cvs.html - dri.sourceforge.net + dri.freedesktop.org I assume that is correct. Liam --- 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
[Dri-devel] Website Wiki
Good day José First off I am using http://dri.sourceforge.net/wiki which resolves to: http://dri.sourceforge.net/cgi-bin/moin.cgi/ I assume this is correct, if not ignore me. g First off looking good, looking useful. There does seems to be some recursive linking going on ie pages linking to themselves, which is pointless and user unfriendly. Eg go to the status page page and there is a status link under each category that links to the status page. Clicking on EditText does not allow me to fix this. I don't have the emails dealing with this at hand, so I'm reading them via web archive atm. It appears that [[FullSearch()]] is dragging in Status as well as what it should. I've ssh'ed in and had a look around in ~/wiki but can't see how this works. Liam --- 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
Re: [Dri-devel] the relationship between Local Graphics Memory and Frame buffer?
Now I am reading intel northbridge 440BX spec(look page 88:Memory System Address Space) And i have a box with 440BX I look /proc/iomem,i find that Framebuffer's size is 16MB(i open vesa before kernel using vga=788) And the local Graphics Memory's size is 64MB(through PMBASE Reg (24h) ;Dev 1(that's pci bridge)) to PMBASE Reg(26h);Dev 1). the rest is Rendering Buffer,Depth Buffer,and Video Capture Buffer. I want to ask : the rest 48M buffer is really located in display card? OS(like kernel) can manipulate framebuffer through mapping the buffer to Virtual Memory. But Can OS manipulate the rest buffer directly,or only Graphics card can do so? I don't know the specifics of 440BX but it is possible to utilise the on card ram of your graphics card for eg a really fast swap file. So that makes me lean towards yes. Liam it depends --- 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
Re: [Dri-devel] Website
On Fri, 19 Sep 2003 12:20:53 +0100 José Fonseca [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2003 at 06:52:23PM +0200, Alexander Stohr wrote: i want to propose to integrate a link to the new WIKI pages to the Help FAQ section of the DRI homepage. I've added a link to the Wiki next to the HELP FAQ. further there was some sort of uncertainty to which XF86 version the current driver snapshots do apply. maybe some clarificatiion is needed in that area. Mmm.. a http://dri.sourceforge.net/cgi-bin/moin.cgi/SnapShots is needed. as Liam is possibly unavailabel for a longer time (see below) i am now openly asking the website maintaince task to the audience. even postponing that task a bit due to current CVS movements onto the new server might be a viable way. Taking that into account, I think it would be better to move some of the main website content into the Wiki, since it allows further editing. I'm thinking of transitional topics such as the Status, Contribute and some of the FAQs. I agree with people putting content onto the website themselves, I certainly don't have time to do it myself. Already the developers do some good content work themselves. PS: the current site is good works - thanks Liam. Indeed. I merely manageged not to mess up the already working website. I do however understand how it all fits together in terms of style sheets, php, etc and will happily explain it to anyone who needs to know. I may also be able to make time for the transition to a wiki, due to work taking an OSS turn and with a wiki and collaborative technologies being considered. Liam it depends --- 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
Re: [Dri-devel] Updated configuration design doc
I updated the configuration design document to reflect the current state of the implementation. The new document is available at http://user.cs.tu-berlin.de/~felixyz/dri/dri_config_design_rev4.txt if anyone is still interested given a mostly complete implementation. ;-) Maybe someone wants to add this to the documentation section of dri.sf.net. I would make a HTML version too, if there is interest. I've been really busy so I have a huge backlog of DRI email to read. I'm perfectly happy with dri config being mentioned / explained / documented on the website. Well html is good if you want it on the web site. Liam it depends --- 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
[Dri-devel] Website
Been real busy lately, so I'm going to unsubscribe from dri-users, and filter out bugzilla-daemon to delete without reading. Otherwise I just won't be able to read all the posts, this makes it a third less emails I have to read. Although now that I look at it, while dri-devel seems to be abused somewhat ie dri-user type questions are posted to dri-devel. The number of posts seem to indicate that more driver development (talk) is being done. Bottom line: If someone asks about the website they need to ask on dri devel in a normal posting to it. Liam it depends --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] TAKE MY NAME OFF YOUR LIST
On Wed, 16 Jul 2003 15:52:41 -0500 linsblues [EMAIL PROTECTED] wrote: REMOVE MY NAME FROM YOUR LIST Chill out man. Allow me quote 2 lines from teeh email you just sent to the list: List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/dri-devel, mailto:[EMAIL PROTECTED] See it´s not so difficult now is it? Liam --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SiS news
I just saw this on extremetech today: http://www.extremetech.com/article2/0,3973,1101038,00.asp Looks like SiS is spinning off it's graphics chip division. perhaps this could mean better access to databooks! Now might be a good time to ask if they've considered it, get the idea out there while everything is being re-arranged... Liam it depends --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Weekly IRC meeting reminder - Now
Pretty much now... This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ Liam it depends --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] known issues w/Tualatin?
I just upgraded my 2x933 p3 to 2x1400 p3-tualatin, and now whenever I start up Q3A the machine hangs hard. On one occasion, Q3A started, but the sound was all screwy, and on exit q3a segfaulted. xmms, however, still played sound just fine. The other few times I tried, it instantly locked up hard requiring reboots. With the 933 cpus, there never was any problem like this. 64mb ddr Radeon vivo @ agp 4x Asus cuv4x-d (I checked, and the vrm can go down to 1.3v, the new cpus are at 1.45v--should be fine). Temps nice, cool, and stable. Kernel 2.4.20 (w/1-line cosmetic patch to correctly report the cache size). I am running X 4.2.x with dri cvs from a while ago--so I'm wondering if there have already been some known issues solved that an update would fix? The only thing I can think of is perhaps the prefetching that the tualatin does? Just an ignorant guess. Any suggestions? Stupid question: Does your motherbaord suport Tualitin? There are motherboards that don't support it. (eg most before tualatin was released) Bios upgarde _may_ fix this problem if it exists. Liam it depends --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] web page on CVS
on the web page, titled CVS fro the DRI, linked via CVS Web Page on the documentation page there is a comment for the mesa-4-0-4-branch with states: A Stable branch to be included in XFree86 4.3 XF86 4.3.0 is already out a few months, so that line obviousely needs an update. Thanks. Fixed (deleted). Liam it depends --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: VA Releases DRI Docs under MIT License
Did anyone else notice this? No. http://sourceforge.net/forum/forum.php?forum_id=217795 I'll read it. Maybe I've been hiding under a rock...but I think this was done 6 months ago and none of us noticed because the only notification was given to the news column of the DRI projects page. I don't think many people read that page, is the bug database still there? Anyway, we should update the documents we are distributing from the DRI project to use this latest version with the licensing update. Well if all it entails is deleting the old license and inserting the new version, I can do that. I assume only those files in the updated-dri-docs.tar.gz need to be changed on the website. Liam it depends --- 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] Re: XFree86 bugzilla available
Hi Philip Are you going to put your time where your mouth is? g I'm sure that having someone who looks after the admin of the DRI project is a good idea. If only for the reason as having someone to fiddle with the website, ie leaving the dri developers more time to code drivers. Heck I might even be able to handle it if you're prepared to help, seeing as how the website now seems to be under control. Or, someone could just leave it as is, disable it and forget about it because sourceforge's bug tracking system sucks. [1] I don't think we ever found out how to disable it. Just another aspect of its suckage - you can't turn it off. Sounds like the real problem is that none of the DRI sourceforge admins found out how to fully use the bugtracking system there. Yes, there is a way to disable it so that it no longer appears on http://sourceforge.net/projects/dri There's lots of other things you can do with it too, that probably no one on the list has checked into. Liam it depends --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
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. g 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
[Dri-devel] DRI website in CVS driver_naming / features.
http://g7-mac3.fy.chalmers.se/cgi-bin/twiki/view/Forte/WebHome I haven't looked at it That was supposed to read: I haven't looked at it *yet*. That's because the video drivers have had the PCI ID to name mappings changed from Radeon xxx SDR/DDR to Radeon 7200. To my knowledge, it is impossible to distinguish an original Radeon 32/64 SDR/DDR card from a Radeon 7200 card, as all that was changed is the marketing name on the box, and the name mapping in the video driver, etc. If they changed the subdevice ID of the 7200, or bumped the chip revision, then they might be able to be distinguished, however I'm not sure it matters since programatically they're identical. Ja which is why I'm wondering why this is still going on, I've updated the radeon_naming page. Originally the page treated the cards as DRI treated them, ie by which driver they use, hence a 7(0/2/5)00 was a r100 because that was the driver they used. 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. Good to know I can bother you when I get to that (after PHP). g I wasn't going to bother with dummy data, may as well do it properly if I'm going to do it all. 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
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. g 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
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! g 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. g 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
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. g 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.g 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
[Dri-devel] Re: dri_driver_features.phtml dri_radeon_features.html
On Tue, 11 Mar 2003 18:34:16 -0700 Brian Paul [EMAIL PROTECTED] wrote: Smitty wrote: Hi Brian In light of your well maintained: http://dri.sourceforge.net/doc/dri_driver_features.phtml I think it's about time that: http://dri.sourceforge.net/doc/dri_radeon_features.html crawled into a hole and died. Do you want to pull in anything from this page or can I get rid of it (permanently)? As far as I'm concerned you can remove the later. It goes into more detail than I think is necessary. Perhaps, its got until the end of the week, then it's gone, if anyone wants it, some of the info in it they'd better grab it before then. The status page seems redundant too: http://dri.sourceforge.net/dri_status.phtml When one clicks on Status on the left (or page header) I think the new table page should come up. Disagree here, the dri_drivers_page won't fit in there, the status page links to some info / websites, that would have to make its way into driver_features first. But I do think that better billing can be given to driver_features on dri_status. 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
[Dri-devel] Re: dri driver features page - radeon_naming
The DRI website contains a few other inaccuracies about ATI's Radeon video hardware. Nothing mission critical, but it is incorrect: http://dri.sourceforge.net/doc/radeon_naming.html Radeon VE a.k.a Radeon 7000, is not R100, it is RV100. So what does this mean for users of DRI? Another thing missing is the original Radeon LE, which was made by a third party in the Asian region. This card is claimed to have no TCL unit, however it is a Radeon QD and is identical to any other Radeon R100 cards (which are also QD), and does in fact have a TCL unit. I believe the BIOS and/or Windows drivers for this card simply disable the TCL unit, but since the chip is a QD, like all other QD boards, it has a TCL unit. It's not missing: * Radeon DDR / LE Hidden right in front of you. g The only difference I know of between this board, and the real Radeon 7200 aka Radeon 64 DDR, is the type and speed of the memory, and that the TCL unit is somehow disabled via software. 7200 is SDR. * Radeon 8700 (FireGL) It's really called FireGL 8700 and FireGL 8800, and both are as stated on the page Radeon R200 based chips, but neither was ever marketed as Radeon 8700 or Radeon 8800, so that will just confuse anyone reading it. It is more correct to list this card the way that ATI names it, under it's FireGL name. Done. At the bottom of the page: * 7X00 denotes a R100 based card. Should be removed, as Radeon 7000, is RV100, not R100. We are in disagreement about the relevance of the V. Also, ATI just released 3 new cards this week, none of which are supported in X yet, but which are likely incredibly easy to add support for once the PCI IDs are known. The Radeon 9200 Pro, Radeon 9600 Pro, and Radeon 9800 Pro Also non-Pro versions of these cards. Radeon 9200 Pro == RV280 Only problem is that we're beginning to embrace ATI's marchitecture, eg a RV280 is a RV250 on a card with AGP 8x. What is the point of this card? From what spec's I can gather it's going to be smacked around by the recently renamed R9100, so much for numbering schemes. Radeon 9600 Pro == R300 RV350 Radeon 9800 Pro == R300 R350 Just thought I'd post this to help improve the accuracy and completeness of that Radeon page. It is certainly becoming accurately and completely confusing. Someone over at ATI is playing silly buggers with a once understandable numbering scheme. I think their product line is becoming too large in an attempt to achieve greater market segmentation. I'm trying to strike a balance between keeping it simple and providing all pertinent information. 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
[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
[Dri-devel] Re: future of DRI? - why no one plays with Glide3. - documentation.
On Sun, 2 Mar 2003 19:34:27 -0500 (EST) Mike A. Harris [EMAIL PROTECTED] wrote: On Sun, 2 Mar 2003, Smitty wrote: OK but here is my take on it, people will work on what they are interested in, so if someone wants to work on R128 and ATI does give out docs for that chip then they should give it to him. Whats the chance of ATI delegating some of this function to TG, ie just give all their hardware programmers guides etc that they are willing to let people see to TG with the understanding that TG only allow people who should see them to get hold of them. I think ATI is more than capable of determining who the are and are not willing to provide their hardware specifications to. I of course am not an ATI employee, and I do not know what their detailed reasoning is for access to their hardware specifications, nor do I care really, it's their documentation and they've got their own right to decide who gets what, and under what circumstances. Surely TG can respond quicker than a juggernaut like ATI, and then Jon Smirl would have got his docs already and made some progress. I don't think response time is an issue at all. This also makes sense in terms of concentrating development of OSS 3D drivers, allowing for higher productivity through division of labour, knowledge concentration, etc, rather than scattering the docs thinly accross the world to individuals. It doesn't compel those who have no interest in DRI but it sure helps those who do. It's a no brainer that the more widely available hardware docs are for any hardware, the more likelyhood of them being put to use by one or more people in the OSS community. That isn't a debateable topic I don't think. This whole issue however has nothing to do with who is the arbiter of access to vendor foo's documentation. Any particular vendor may or may not permit access to some/all/none of their documentation either freely and publically, or via NDA to specific individuals under whatever criterion they wish to decide upon. A bunch of people whining on a mailing list is not going to change that at all. In general, someone who goes ahead and works on the code and makes improvements WITHOUT a vendor's documentation generally has a better chance at actually getting it. Those who do nothing but whine on mailing lists that they can't do work on the code because they don't have the docs, are more likely to never see them. I don't think that any vendor is planning on providing hardware documentation widespread or to specific individuals based on a popular vote of some mailing list. There are certain realities that people must learn to accept and to deal with, and one of them is that some video hardware vendors do not want to provide any access to their hardware specifications at all. Others don't want their documentation widespread and public for whatever reasons they may have (none of our business really IMHO), but they may want to support the open source community nonetheless, and so they provide access to their documentation under an NDA agreement that they are comfortable with. It allows them to protect whatever it is they're wanting to protect, and it allows open source progress to be made as well. We're lucky to get specifications from any vendor who is willing to provide them to us under _ANY_ terms. I'd love to see more vendors providing specs, and doing so more openly, and preferably without NDAs. Ragging on vendors who do permit access to docs under NDA to people of their choosing, for not providing them to the world, is more likely to dry up access to specs for _EVERYONE_, and make binary only drivers the only way of getting modern hardware to work. In other words, I believe that whining about these certain realities, is equivalent to shooting one's self in the foot. Mike you're quite the downer at the moment, been a rough weekend? g I couldn't care two hoots about whether or not ATI sits on the hardware documentation or starts distributing it to univertsities as teching aids. What I'm saying is that if they'd decide gee this document can be released without problem, along with this pile over here and this lot over here can probably be released for use only for writing OSS drivers then they should go ahead and do it. It would make life a lot simpler for all concerned. Why should people have to fight to get documentation when ATI is in reality quite happy to give out certain docs, but because they have ceated an awkward process. At the end of the day an NDA isn't much protection, eventually the doc will fall into the hands of someone they don't want it to, whether someone has to steal it off someone who has signed a NDA, find it in the trash, bribe the night staff. It pretty much is an all or nothing approach. If they're prepared to release docs to members of TG, why don't they release them to TG directly? And I certainly wasn't imlying
[Dri-devel] Re: future of DRI? - why no one plays with Glide3.
(oh, and please, I prefer being referred to by my first name.) one Molton many Ian's g From: Daniel Vogel [EMAIL PROTECTED] To: Smitty [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: [Dri-devel] Re: future of DRI? - why no one plays with Glide3. Date: Sat, 1 Mar 2003 16:35:15 -0500 a V3 gets smacked around by a TNT2, FWIW, a Voodoo 3 clearly outperforms a TNT2 with Unreal Tournament 2003 (on Windows, using D3D). It's a PITA to develop for though ;) OK how about GF256? I still have lots of cards to name. g Liam it depends --- 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
Re: [Dri-devel] S3TC (again)
Can we add this to the FAQ, please? The FAQ is editable by anyone isn't it? No, but anyone can add a FAQ, if they could edit / delete them that would be none too wise, which is why I advise not to mess it up (because then I have to fix it). Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC (again) - FAQ
OK, I don't exactly want to stir up this hornets nest *again*, but a couple of things aren't entirely clear to me and I'd appreciate any clarifications. As I understand it, the situation is as follows: The S3TC algorithm is patented and therefore no-one can distribute an implementation of the algorithm without a licence from the patent holders. S3TC decompression must be implemented in the hardware (otherwise what's the point), therefore hardware which uses S3TC can be assumed to have a valid licence to use the code, otherwise the patent owners would be down on the hardware manufacturers like the proverbial ton of bricks. Patent law is actually more complicated than that. I'm not in a position to go into it, but it gets complicated when you have multiple components (i.e., software and hardware) working together to implement something. As far as I'm aware, the main users of S3TC are modern games with their vast arrays of textures -- presumably such games come with the textures precompressed, or are able to compress them and cache the compressed textures themselves. Presumably again, the authors of the games have paid for a licence to use the S3TC algorithm from the patent holders. Now, if an OpenGL application has a pile of textures already compressed with the S3TC algorithm, then I don't understand why the dri drivers can't simply offer the S3TC interfaces to the hardware, pass the compressed textures to the hardware and let the hardware get on with its licensed decompression of the textures as required. Likewise, if the OpenGL application passes compressed textures to the S3TC API then how it gets hold of the compressed textures in the first place is it's own responsibility -- the OpenGL API just passes them on. Look at the ARB_texture_compression and EXT_texture_compression_s3tc specs again. You can specify uncompressed textures and have the driver compress the AND you can specify compressed textures and have the driver decompress them (to read them back into the application). For example, Quake3 can use the S3's vendor-specific extension (can't remember the name of it right now), but it does NOT have ANY textures pre-compressed. It expects the driver to do the work. Can we add this to the FAQ, please? Instructions at teh bottom of: http://dri.sourceforge.net/help.phtml Alternatively if you know how it works go straight there: http://dri.sourceforge.net/faq/faq_add.phtml No one appears to be abusing it so I'm happy to let it be open. Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI Mailing list maintanence / maintaner
I think spam filtering for dri-devel and dri-users would be a good solution -- IMO, that would be better than moderation. For dri-patches, the Reply-To is dri-devel. I'd rather have just commit messages and nothing else on dri-patches. Any comments/replies to specific patches, or posts dealing with CVS should go to dri-devel anyway. That's why I suggested limiting just dri-patches to sourceforge addresses. I have only been glancing at this thread, but basically it comes down to this - If the spam bothers you that much setup spam filtering on your personal machine and be done with it. We waste more time and bandwidth talking about what should be done (with the list) then actually doing what really should be done (with dri). Just my thoughts ... As stated in my previous mail, I do use spamassassin, and as such I do not have a problem with spam. If you're not interested in the discussion on despamming, then simply hit DEL on the messages that do not interest you, and you'll lose no time at all. If other people wish to discuss it, they can, and will. Freedom of speech. Please - what one minute here! I hold the freedom of speech very close to my heart for specific reasons I won't go into. What I wrote above in no way indicates that I want such a freedom restricted or otherwise removed. That's very nice, but there are limits to free speech. What I did write above is an indication of my insight into the problem: 1) Moderating a list restricts the flow of information (thus in some way can be viewed as a restriction of speech ... see above). It can be viewed as that if you are trying to view it in that way. Not if you apply the reasonable man test. The moderating refers to the deleting of Spam / UCE. 2) Limiting the mailing list interaction via mail addresses limits the flow of information (thus in some way can be viewed as a restriction of speech ... see above). See above. 3) Implementing a mailing list wide spam filter can remove potentially beneficial e-mails (thus in some way can be viewed as a restriction of speech ... see above Besides I know it will never happen unless we take the lists off of sourceforge and host them else where ... or so the little birds tell me). Everything has a cost, so what if one in a thousand emails get vapourised, enough emails disapear into the ether, get lost already that this makes no difference, just resend it. Email is not a system whereby 100% of email has to get through, 99.9% is just fine, especially if it gets rid of a decent amount of spam. Stating that ... too much energy has already been wasted ... on spinning wheels. As aposed to implemting more filters / spamassassin, the reason for whih appear to be related to SF as a whole and not anyone on this list. Liam it depends --- 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
[Dri-devel] DRI Mailing list maintanence / maintaner
Hi Rich Is there anything that can be done to cut down the spam on dri-devel? Several other mailing lists I'm on hold submissions by non-subscribers for approval. I'd even be willing to sort the non-subscribed emails, so that everyone else could avoid them... That would be great, its really starting to get on my tits now. What you've mentioned has been suggested by Alex in response to one of my emails about this. I've tried contacting the list mainatiner privately but it would appear that the maintainer listed under dri-devel list info is incorrect. I've just started running bogofilter on all incoming email, myself, though yeah, it'd be nice if it weren't so necessary. I'm on the dri-digest(s) option so I just live with it. Or am I just being obnoxious? Less so than the spammers. :) I skipped your email because of the subject line. g Liam it depends --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI Mailing list maintanence / maintaner
Is there anything that can be done to cut down the spam on dri-devel? Several other mailing lists I'm on hold submissions by non-subscribersfor approval. I'd even be willing to sort the non-subscribed emails,so that everyone else could avoid them... That would be great, its really starting to get on my tits now. What you've mentioned has been suggested by Alex in response to one of my emails about this. I've tried contacting the list mainatiner privately but it would appear that the maintainer listed under dri-devel list info is incorrect. I've just started running bogofilter on all incoming email, myself, though yeah, it'd be nice if it weren't so necessary. I'm on the dri-digest(s) option so I just live with it. Or am I just being obnoxious? Less so than the spammers. :) I skipped your email because of the subject line. g I'd be happy to see postings restricted to subscribers too. Unfortunately, I don't know what the list-admin password is. Maybe Daryll or Rik do? I could do it, but I don't think it's a good idea to restrict those who are non-members of the list. Cross postings from the xfree86 lists are sometimes useful. Well Rich already wanted to proof the emails / kill the spam for the list, Alex recomended splitting the list in two, subscribed vs unsubscribed, allowing anything posted by a subscriber through, and filtering the unsubscribed postings. I mean I've heard of Viagra and Propecia (I think) but what the heck Phentermine and Xenical are is beyond me. I assume filtering of sf mailng lists is not possible because filtering on: viagra, porn, mortage - would catch about half of the spam. Liam it depends --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Configuration File Example.
snip scary plaintext example 1) Requires special parser which is too syntax sensitive 2) Users editing the file could hose it rather easily compared to existing formats. Ja I know I was teasing the We want XML crowd by going to the extreme in the opposite direction, trying to pull them back to the centre. For a new config file, I personally think it makes the most sense to use one of either: 1) XF86Config style file, and use libxf86config to parse it, possibly extending the lib slightly as needed. I'd be perfectly happy with this. 2) One of the XML-is-my-favourite TLA ideas I'd be less than happy with this, XMHell is not my favourite thing. Either one has a good arguement on both sides. You're trying to drive in the middle of the road, be careful. Reinventing a new format though buys nothing. I'm of the faith that good GUI/TUI config tools should be handling everything for configuration. End user edited config files == bug reports out the wazoo. I'd prefer to not ship some specialized config format at all than to ship one that wasn't well thought out, and also keeps the principle of least surprise. I couldn't care less whether there is or isn't a GUI / TUI configuration program. What I do care about is that the configuration files must be stored in a file which can be edited, run through a script, etc. All the configuration files on my box which I've ever had to edit / bothered to look, have never been in XML, and I don't see a good enough reason to start now. KISS principle. Also, a bit of open source philosophy - reuse what exists already, don't reinvent. Well I'd consider XML to not be simpler than XF86Config-4, besides which it is uneccessary, what happened to the don't implement it if you don't need it philosophy? cheers Liam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Configuration File Example.
Howzit? How about this for something which can be edited by a GUI program which can change the settings, and which I / you / world+dog can read, understand and edit easily in a text editor? GUI *and* CLI editable without having to squint at it. Anyone see any problems if so feel free to educate me. #No spaces except between the connfiguration option and the choice #The only configuration options are those in brackets #Explain how Global config is overwriten by Device which is overwritten #by Program. Global Begin Anisotrophic_texture_filtering(Y/N) Y Bilinear_filtering(Y/N) Y Trilinear_filtering(Y/N) Y AGP_speed(1/2/4/8) 1 End; Device 0 Begin AGP_speed(1/2/4/8) 2 End; Device 1 Begin AGP_speed(1/2/4/8) 4 End; Program Quake1 Begin Trilinear_filtering(Y/N) N Double_buffering(Y/N) Y End; Program UT Begin Trilinear_filtering(Y/N) N Double_buffering(Y/N) Y Vertical_sync(Y/N) Y End; Liam it depends --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Configuration file format survey
Hallo We've been discussing general issues regarding the new DRI configuration system recently on IRC. The most user-visible issue is the configuration file format (until there is a GUI tool ;-). In any case we need a more structured (nested) format than win.ini since we want to be able to set parameters per driver/screen/application or any combination of those. I take it that you set your options for the driver, andoverride them on a per screen basis, whih acre in turn overridden on a per application basis? If so I like that. We tentatively decided to use XML for the configuration file as well as for the drivers' specification of available parameters. Other alternatives which were discussed AFAIR are a Lisp-like syntax as in the mesa config file, python dictionaries (see Ians mail Configuration idea) or something completely home-made. Unfortunately there seem to be no IRC logs of relevant meetings :-( If anyone has serious objections to XML, please let us know (mail to dri-devel will suffice ;-). Ja, I like .conf style, plaintext. If you want to implement it in XML then I'd definitely want a plain text file which I can edit by hand, in case graphical editing program gets broken, is unavilable, no GUI is available etc. If you can't do it via GUI and the command line its not a good thing. Liam it depends --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Re: SUCCESS! Radeon 8500 DRI under RH 7.3! - documentation
I think this needs to go to dri-devel. That's where the busy person lurks, and it seems to be a good start. Actually there has been some work to create a script which will identify the card and advise which driver to download, but holiday season plus busy people does not make these things happen very fast. I think this can be very simple on linux: `lspci -n | grep Class 0300 | cut -d -f 4` (I don't trust /proc/pci parsers, because the format can change anytime) According to /path_to_kernel_source/drivers/pci/pci.ids, Class prefix 03 is for display controllers, suffix 00 means VGA controllers, suffix 02 means 3D controllers. So we have the vendor and product IDs separated by a colon. Of course, we must fill a table with the ID-s (and maybe the device classes, when 0300 isn't good for all cards). And this is, where everyone can contribute. cheers Liam --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Slackware - kernel modules situation
Does the quotation below accurately reflect the situation eith kernel modules or not? If not please spell out the correct situation. The information on the web site is wrong in that place, and cause me a great deal of confusion. The kernel modules are now included as part of the XFree86 source code. Just head to Are you talking about dri.sf.net? If so a URL and the correction Yes I am. On dri.sf.net/downloads.phtml it says You can download the kernel modules for the latest XFree86 release right here. This should probably be changed to You can download the Linux kernel modules for XFree86 4.2.x here. Kernel modules for subsequent versions of XFree86 can be found in the XFree86 source tree in the directory xc/programs/Xserver/hw/xfree86/os-support/linux/drm. I think this is factually correct ;) It seems to be the current state with XF86 4.2.99, I've no idea whether the newer modules will be merged into the kernel (2.4.20 contains modules for XF86 4.0 and 4.1, but the 4.1 modules seem to work fine with 4.2) or will remain in the X source tree. cheers Liam --- 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
[Dri-devel] AGP modes
http://grassomusic.de/english/luefter.htm: AGPx2 can use lower signal levels if the graphics card asks for it, 1.5V instead of 3.3V (AGPx4 uses 1.5V high state always) Wonder if this has anything to do with why some cards on some motherboards work at some AGP multipliers but not others. Liam it depends --- 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
[Dri-devel] Do we have a 3DNow!/SSE switch so that I can test without SSE?
Seams to me that SSE support in Mesa-5.0/5.1 brakes several things on Athlon systems. On Athlon MMX and 3DNow! are shared. Even SSE is mixed in. But more parallel...;-) When did this happen I was under the impression state changes were required to get between the various instruction extension sets. Got any links? Liam it depends --- 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
[Dri-devel] Re: non-NDA documentation.
Howzit? Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. Heres a suggestion. Can people holding non-NDA chipset documentation please all send it to smitty and he can put it up on the site? If people are paranoid about being sued, I'll happily host it on mnementh.co.uk I'll quite happily stick just about anything up on the website if it's of a decent quality / standard. Not just up to me though. here is some driver documentation for VT8601A, without NDA: http://www.viavpsd.com/product/Download.jsp?motherboardId=3D21 (filename: DS8601A182.pdf) maybe thats a good starting point for new developers who have a notebook or thinclient with this chip. they could start writing a dri driver without waiting for docs. Somewhere I found info that the Blade 3d should be almost as good/fast as an i810, heres a forum for mvp4/ple133 mini-itx-board linux users: http://linitx.org/forum/ I'll also happily link to just about anything if it's of a decent quality / standard. Again its not just up to me though. Of course it'll need more than just this. g Liam it depends --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI site overhaul: What about the DRI Beginner's Guide etc. sections?
Howzit Dieter? Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. Any progress? With what excatly the guide in the subject line - I've never touched that. With the website see below. When will we see the move? Merged already. I pointed someone at the new site and first thing was 404 Not Found... Please give a URL, although iirc /site_update is no longer valid, I don't regard this as a problem as the correct URL is now just: http://dri.sf.net Liam it depends --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Ati Radeon 8500 - DRI howto.
Hello Bache Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. I've made a small howto for ati radeon 8500 with direct render support. I want opinions and suggestions, changes that can make the doc better. Please take a look at: http://looner.mine.nu/~bkw/dri_8500.txt I haven't had a look yet, but heard good things from those who had. If you will look after your howto I'd like to link to it from the main site as dcoumentation. Or put it on the same server if you no longer have any interest in it. Liam it depends --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri_data_flow and control_flow diagrams + explanations website
btw is the DDX Driver what causes the XServer to be single threaded? I think there are more fundamental reasons. Better change that back then. Also sticking up dri_driver_features table by Brian Paul, it may not be complete but it is full of info already. Yes, looks good. I'd change the Mach64 column for PPC to something like 'yes (DMA problems)' and the others (except both Intel chipsets) to 'untested'. Not my baby, if / when it is updated I'll put up the new version. cheers Liam --- 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
Re: [Dri-devel] dri_data_flow and control_flow diagrams + explanations website
This has been sitting around for a long time, since I got pulled into the website side of things. I wish to put this up as high level design documentation. Any comments? The two documents look great! Up they go. They match many of my personal notes about architecture :) OK then. btw is the DDX Driver what causes the XServer to be single threaded? Do we still need the old data flow control flow diagrams? ie data_flow.jpg, control_flow.jpg control_flow_poster.jpg or are they now redundent? They are as I recall out of date. Anyone know of any copyright issues? Anything that is wrong just shout as the diagrams are done in a vector based graphics program. Also added Debian packages link. Also sticking up dri_driver_features table by Brian Paul, it may not be complete but it is full of info already. cheers Liam --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri_data_flow and control_flow diagrams + explanations
This has been sitting around for a long time, since I got pulled into the website side of things. I wish to put this up as high level design documentation. Any comments? and yes n2s is note to self. Liam it depends dri_flow.tar.gz Description: Binary data
[Dri-devel] Re: driver feature table
Hi Brian Attached is an updated table. Good work, when everyone stops pointing out typos etc please email (cc) me a copy, and I'll put it up sometime (wee bit busy atm). Liam it depends --- 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
[Dri-devel] Re: http://penguinppc.org/~daenzer/debian/dri-trunk/
Why don't you just use deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ This is new to me, I guess it wouldn't be a bad idea to mention them somewhere on dri.sf.net. Who is them? g DRI CVS snapshot packages, so based on 4.2.0. What is it it? Details are needed if you want it (a link) on the website. Liam it depends --- 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
Re: [Dri-devel] Re: Typo on DRI website - archives
otherwise alphbetically eg Manufacturers Distros (I'll fix distro's now) Then you only have to fix status.phtml (Supported Cards) to make it equally to links.phtml (Graphics Card Manufacturers). Well spotted, I'll make the status.phtml alphabetical. cheers Liam --- 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
[Dri-devel] Re: Typo on DRI website - archives
1. For the mailing list info, there is a link to the old Geocrawler archives. I think that should probably be removed because SF.net has th= eir own archives now and they also include the content from the old Geocraw= ler archives. You can already get to the SF.net archives by clicking on the mailing list name and then choosing archives on the following page. It might be nice to add an archive link right next to every mailing list, = so for example: dri-devel [Archives] dri-user [Archives] Well did this. What about the main central archive? http://marc.theaimsgroup.com/?l=3Ddri-develr=3D1w=3D2 It is fast and dany. I've added your link but, only the one to dri-devel, I'm reasonably sure they can figure out how to get dri users / announce / patch. This is not good though: ?l=3Ddri-develr=3D1w=3D2 Liam it depends --- 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
[Dri-devel] Spam on this list, list email addresses are out in the open.
Howzit? Having noticed the spam on this list, when I was working on the Mailing list page ( subscribe / unsubscribe / preferences ) this struck me as odd: To send mail to the list send to [EMAIL PROTECTED] Now is this not vulnerable to email harvesting web bots which makes the list more likely to be spammed? Perhaps dri-devel AT lists DOT sou An image of [EMAIL PROTECTED] Something to consider? Something else to consider. Is it not possible to strip out the html sections of emails to the lists? Liam it depends --- 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
Re: [Dri-devel] Re: Typo on DRI website - archives
Op Saterdag, 28 September 2002 20:27:01 Dieter Nützel het geskryf: Am Samstag, 28. September 2002 19:57 schrieb Smitty: What about the main central archive? http://marc.theaimsgroup.com/?l=3Ddri-develr=3D1w=3D2 It is fast and dany. I've added your link but, only the one to dri-devel, I'm reasonably sure they can figure out how to get dri users / announce / patch. This is not good though: ?l=3Ddri-develr=3D1w=3D2 True, only cut'n paste from my bookmarks ;-) No it's not you, its the verdomde website. g (I had a look at it.) Can you please sort all your stuff (links) in alphabetical order like Graphics Card Manufacturers for example? Or do it all weighted? But who decides? Links page is definitely weighted where possible eg Projects OS otherwise alphbetically eg Manufacturers Distros (I'll fix distro's now) but it's not much of an issu on a really short section eg disto, you can see all of them in a glance. g I decide. With the help of anyone who cares to offer an opinion. cheers Liam --- 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
[Dri-devel] Re: Typo on DRI website
I would say that Effecting a full scale 'all in one go' transition is VERY hard. I would suggest letting Liam make the poage official, and continue refining the layout. I don't see how a transition in one go is very hard at all. The DRI website is fairly small, all you have to do is cut-n-paste the existing content and re-arrange it into new pages as you see fit. In terms of getting a working site not at all, in terms of making everyone happy not so easy. How do you think I made the current website? If you can't handle cutting and pasting, the you shouldn't be designing websites ... That's not quite how I did it, needless to say the content has been cleanly seperated from layout by hand. The original layout of content was so illogical that there is really no way to transition gradually and still have things make sense. Now you are contradicting yourself. You just said it was hard to make a transition in one go, now you say it is impossible to make a gradual transition. Which is it then? neither which is why he gave up g I seperated it - content done in one go (cut and paste), layout, styling, editing, tweaking, etc done in phases. In other words both ways. Liam is a braver man than I - I gave up after doing a significant amount of re-organisation, because I couldnt face the problem of doing a phased update. I don't think anyone wants a phased update. For a site as small as the DRI site, a one-go replacement makes sense. That is also what I told you originally when you asked me about it. Phased as in looks - the content's all there except for the outdated bits that have been removed or the new bits that have been added. I think that unless anyone has a MAJOR complaint about the new site, it should become the default. Well, I for one don't think so. The current site didn't replace the previous site until I had adressed all the problems people had with it. I went through several revisions of the site on a different server until it went live on dri.sf.net. btw what about now? I don't think the standards should be lowered just because you guys can't handle making revisions to the site before it goes live. I'm not worried about standards it validates at w3c. g I must confess that I am not surprised that the developers have STILL not given Liam a complete list of supported features - despite being aske long ago by him, and several times, more recently by me. I must say that I am not surprised either. The developers have better things to do, such as actually working on the drivers (imagine that), than to compile lists of supported features. David is working on something that may well make this very painless... I can download the linux kernel and Hack HAck Hack - its truely open, specs and all. I cannot do this with DRI - there are no specs. all I can do is poke blindly. As I said above, if you were really serious about becoming a developer you would be able to obtain documentation from the companies. Obviously you must be doing something wrong ... Don't be petty. I recall from this list lots of people struggling to get documentation. ATI doesn't want HyperZ / iDCT implemented iirc. There's the whole S3TC issue, obviously 3d card manufacturers are being anal about there doc's. Liam it depends --- 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
[Dri-devel] Re: Typo on DRI website
I think it is much too early for this kind of criticism. While the updated website is far from perfect and finished, I definetely think it is a clear improvement with respect to the former version. I don't see how it is too early for criticism. Liam has indicated several times that he would like to use the site update as is. If it is too early to criticize an apparently finished product, then when should I criticize it? Not too early, but not quite that simple for all intents and purposes the website is finished and has been finished several times. For some reason this always brings out the comments that are needed. These are implemented (or not) depending on how well they are motivated for / against and then the cycle begins again when I squeak up again - I wonder why this keeps happenning g A few other people had already raised the same issues as me even earlier in the game. I am simply trying to provide some _constructive_ criticism as to how the site update can be improved so that it can replace the current site. (see below) it is important to get the message out Yes it is important to get the message out and that is what the mailing lists are for. I am pretty sure that anyone how follows dri-devel is aware of the site update. Yup I've had a large number of I like, typo here (small things) responses, but the bigger more serious changes / requests are few and far between and they disagree! (frames vs no frames; combining pages vs splitting them). But my thanks to all. and I would consider any change that makes the website more alive (+the information can actually be found on it) a change for good. There are few things more discouraging that a unmaintained website. If Liam would address the problems I mentioned, then maybe the site would go live soon. *If* g Liam it depends --- 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
[Dri-devel] Re: Typo on DRI website.
I would also recommend that you work together with Nick Leippe. Just a quick note to say that I'm still here and happy to help. My modified version is up for grabs to pick and choose from still at http://lfm.sourceforge.net/dritest/ Sorry I managed to miss a whole bunch of posts, reading dri-digest quickly means I sometimes skip whole messages, sometimes the whole digest. Not trying to ignore you, heck I even missed some of my supporters giving Frank a hard time. And as I mentioned colour banding is there already, and the layout is now a lot like yours the latter after Frank's emails. If you already have a sourceforge login, you should have all the access you need to copy the source files if you want anything from them. Got that, don't think I'll be doing that though I had a look at the source of one of your pages, I spent quite a bit of time cleaning up the html by hand of things such as tables, I don't want to do that again. Besides, as I mentioned earlier, at Pawel's suggestion and with his help the site now makes use of CSS, and I re-implemented that PHP header / footer file thing of Frank's, which is where I stuck the CSS, so now the content is pretty much seperated from the formatting and you can change the font style / size / colours etc from one file. Easy maintanence is becoming a reality. Liam it depends --- 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
[Dri-devel] Re: Typo on DRI website.
Howzit Frank? Quite frankly (no pun intended) IRC logs are about the only thing out of place, and when I look at that page I wonder if I should remove them, however your idea to split documentation back out of help will draw attention back to them on that page meaning they can be safely removed. Ok, I would remove CVS and IRC Logs from that page. They should re-appear on the Contribute page. IRC is already gone, I'm leaving CVS there (for now at least) because you know who you are is working on scripts to pull CVs, compile etc I must disagree on this point (I need persuasion perhaps a really good example / implementation where it works well) because help status pages are the longest pages they could benefit from it the most (at all) but I like your other suggestions so much that they are about to become shorter and the colour banding makes it a dead simple after that. If you don't want to add it then that's ok. But I still feel it is hard to get an overview of what one can find on a page. Maybe put a more detailed site outline on the home page. (see below) Another way to give a better overview might be to change the font to something more crisp and readable. I really like Arial or Helvetica for reading stuff on the web. You could also try increasing the font size by one. Yeah I must have a look at that, the CSS is not behaving perfectly now that it is inserted via PHP, but this could just be me, the pages on my machine are obviously not rendered as they will be when they are being served up via the webserver so its difficult to guage the effects of changes. But heck it's one file to change cant be that hard. g It would also be good if the titles for items on a page were a bigger font size, in addition to being bold/underlined. That would make them stand out a lot better. As above. A few other things I can think of to change in the current site are: I think you misunderstood me, the points below apply to the current site, not your site update. They are just my ideas for what should change, but it appears you have already addressed a lot of them. I should have payed closer attention to your site update before writing them up. Understood. I'm sort of lost I understand the php header funcion and what it did / does but HTML headers? What I mean is that it should output the title for a page. On your site that would be the two horizontal bars with the title in between. So then the source for a page is basically: ? dri_header (Downloads); ? [ HTML content here ] ? dri_footer (); ? Then if you want to change the basic appearance of a page (title, header/footer) you can do it in those two functions. Also saves you from reusing the same header/footer HTML in every page over and over again. Did this already (guess what I was doing monday night instead of economics) There is no About DRI page. There is currently What is the DRI text on the home page already. Junk on the home page? Please be more specific, there is obviously some confusion here are we looking at the same page? Sorry, I ment the current site, not your site update. However, looking at yours I think you should remove the stuff below the Mailing Lists section. It shouldn't really be necessary to explain the different links, I just put that on the original page as a filler. Well actually this is similar in concept to your content navigation bar, or at least it could be extended to do this, comments? There is one downloads page already?? Although it does have IRC logs, and a CVS section (waiting on someone here). More confusion, same page? Yes, your Downloads page is good. I would remove CVS and IRC Logs. Also I would put the config files as the very last item, because I doubt many people downloads those. CVS stays for now (see above) IRC is long gone, will move config files. - remove the Report Problems stuff from the Help FAQ page since we don't use the SF.net bugtracker anyway. Will do, I read about this on the mailing list, but I'm not going to remove it just because I think nobody wants it. Thinking about this, a better idea might be to say that bugs should be reported on the dri-devel mailing list. If we do that and it results in too much traffic/crappy bug reports it can be removed later. But giving people some way to report bugs is probably a good idea. Must still add some text about report bugs to dri-devel. In the end this leaves us with these pages: 1. Home - with the About DRI text, a nice intro to the project I think this is how it is. 2. Status - the status of the hardware we support With 5 this is how it will be. 3. Downloads - downloads of drivers, kernel modules, and other files Pretty much identical already. 4. Documentation - all of our documentation for developers and end users This I like it was a dubious call to combine help faq documentation. 5. Contribute
Re: [Dri-devel] Re: Typo on DRI website.
Ok, I would remove CVS and IRC Logs from that page. They should re-appear on the Contribute page. IRC is already gone, I'm leaving CVS there (for now at least) because you know who you are is working on scripts to pull CVs, compile etc Why do you need to leave the CVS information there? It can be garnered from different sources :) To get a response out of you g That's where'd I'd put a list of the scripts to d/l. I just started doing a code review of the r200 driver, hopefully I'll get around to writing some more scripts within the next few weeks. Well I think r200 is a wee bit more important than scripts, you are free to disagree and work on your scripts though. g If not, I'll bug Thomasz and have him write something :} Hello Thomas. cheers Liam --- 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
Re: [Dri-devel] Re: Typo on DRI website - XFree86 NDA's
Speaking of the new web site, could someone please remove the section in the FAQ that says that various NDA'd documentation can be obtained by becoming an XFree86 Project member. I'm sure someone could do that, could you point out where this is, I'm certainly not about to read all the FAQ entries to find this. Just found it. Liam it depends --- 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
Re: [Dri-devel] Re: Typo on DRI website - XFree86 NDA's
Speaking of the new web site, could someone please remove the section in the FAQ that says that various NDA'd documentation can be obtained by becoming an XFree86 Project member. I'm sure someone could do that, could you point out where this is, I'm certainly not about to read all the FAQ entries to find this. Just found it. Development Issues 3. How can I obtain hardware documentation? Appears to be locked, don't think I can touch this. Liam it depends --- 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
Re: [Dri-devel] Re: Typo on DRI website.
Which reminds me /dri/htdocs/ is a real mess and I can't clean it up because I don't have rights to delete things (I think) because the permisions set are for the dri / sourceforge *login* not the *group* dri. I don't understand. As it is now: % ls -l drwxrwsr-x2 mdaenzer dri 4096 Aug 5 16:41 IRC-logs -rw-rw-r--1 fworsley dri 4149 Apr 24 15:31 about.phtml -rw-r--r--1 spyro1 dri 13619243 Jun 24 08:45 backup_imolton.tar.gz drwxrwxr-x4 fworsley dri 4096 Aug 14 13:08 doc -rw-rw-r--1 fworsley dri 5744 Mar 13 2002 doc.phtml ... they're all dri group. Is that wrong? spyro1 and fworsley own a few files which aren't group-writable - I can't fix that. They'll have to do 'chmod g+w themselves. That would be what I was on about. cheers Liam --- 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
[Dri-devel] DRI meeting now! #dri-devel
Liam it depends --- 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
[Dri-devel] Re: Typo on DRI website.
On Sun, 22 Sep 2002 21:24:37 -0700 Frank Worsley [EMAIL PROTECTED] wrote: That hasn't happened (accepted and moved) so I haven't asked. hint I think there is two problems here ... 1. Since this is an open-source project there is no single person to approve the website. Basically I don't think you will get 'approval' from the group as a whole until your new site has some major advantage that everyone is going to get excited about. Apparently right now this is not the case, either because nobody cares about the changes you are trying to make -or- because you haven't achieved those proposed changes in your site update ... Understood. See 2. I care more about how it looks. 2. The main problem Ian Molton and you seem to have with the current site is that content is hard to find. That is probably a good point, but I think the way you have reorganized the content is even worse. No offence intended but no, I just think the orignal site looks none too nice so does he AFAIK. I am looking at the your site update right now and every page is very long, with a multitude of things on a page - many of which don't really seem to be related. For example, on the downloads page IRC Meeting Logs and Binary Snapshots. Also, since the pages are very long it is hard to see what you can find on a page. Quite frankly (no pun intended) IRC logs are about the only thing out of place, and when I look at that page I wonder if I should remove them, however your idea to split documentation back out of help will draw attention back to them on that page meaning they can be safely removed. Have you considered adding a horizontal line of content links to the top of the page? One link to an anchor for each major item on the page. No I have not, but I have just learnt what content links means. I believe adding such a contents link line to the current site would make it much easier to navigate. For example on the current Help FAQ page there could be a line right below the title, with links to FAQ - Report Bugs - Mailing Lists. This makes it immediately obvious to anyone what they can find on that page, without having to scoll and potentially miss things. Bug reports will be dissapearing (at your request so bad example g) I must disagree on this point (I need persuasion perhaps a really good example / implementation where it works well) because help status pages are the longest pages they could benefit from it the most (at all) but I like your other suggestions so much that they are about to become shorter and the colour banding makes it a dead simple after that. Removing the frames from the current page is also a no-brainer since the top and bottom links line for all major pages already exists. It is also easy to update those links if they change since they are inserted by a PHP header/footer function for each page. Ja but if you really don't like frames / can't use them you are catered for so it is not an issue. A few other things I can think of to change in the current site are: - make the PHP dri_header function output all HTML headers and the actual page title that is user visible. It doesn't do the latter right now cause I was being stupid. I'm sort of lost I understand the php header funcion and what it did / does but HTML headers? - put the What is the DRI text from the About DRI page on the home page. Remove the About DRI page and the existing junk on the home page. There is no About DRI page. There is currently What is the DRI text on the home page already. Junk on the home page? Please be more specific, there is obviously some confusion here are we looking at the same page? - combine the Resources and Downloads pages into one Downloads page with sections Binary Packages, Kernel Modules, Config Files, Other Libraries and Utilities Thereby remove the old kernel module sources from the new page. There is one downloads page already?? Although it does have IRC logs, and a CVS section (waiting on someone here). More confusion, same page? - add a new Contribute or Developer page that includes our call for developers from the Status page (remove that from the Status page), a link to the developer FAQ and our mailing lists, link to IRC meeting times and logs, links to the developer sections of the Documentation page. - remove the Report Problems stuff from the Help FAQ page since we don't use the SF.net bugtracker anyway. Will do, I read about this on the mailing list, but I'm not going to remove it just because I think nobody wants it. - add the content links line to each of these new pages. No. see above - remove the frames (if people really dislike them that much) Some do, some don't. As you said can't make everyone happy. In the end this leaves us with these pages: 1. Home - with the About DRI text, a nice intro to the project I think this is how it is. 2. Status - the status of the hardware we support With 5 this is how it will be.
[Dri-devel] Re: Typo on DRI website.
Mike A. Harris wrote: There's a typo on the Radeon features webpage: http://dri.sourceforge.net/other/radeon_dri_features.html At the bottom it has IcDT Gatos Should be iDCT (Discreet Cosine Transform) IIRC I wasn't worried how I spelled it originally as it was RFC stage I put (sp?) nobody commented on that for a while, anyway a new version (17 July 2002) of the features list was made then started working on the dri website the new version is reachable from: dri.sf.net/site_update/ Brian Paul wrote: Fixed. Yes it is / was. g Which reminds me /dri/htdocs/ is a real mess and I can't clean it up because I don't have rights to delete things (I think) because the permisions set are for the dri / sourceforge *login* not the *group* dri. I was going to ask for a way around this once the site update had been completed, accepted and moved to dri.sf.net. That hasn't happened (accepted and moved) so I haven't asked. hint Liam it depends --- 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
[Dri-devel] DRI Website update - URL
Howzit? Thanks to all those who have been helping me, this has got done a lot quicker than it otherwise would have, and the DRI site is still standing ;-). Anyhow: http://dri.sourceforge.net/site_update/ All comments, suggestions, requests are welcome. Liam it depends --- 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
[Dri-devel] Have a sneak peak at the new DRI website and give your opinions.
email me and I will email you the updated version, it is currently less than 70K uncompressed (it uses the existing site) this version may be up to double that -I'll try to keep it down in size. Liam it depends --- 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
[Dri-devel] Re: Fast Writes
This worked for me, but my Radeon 7500 QL is ok with Fast Writes. What dose this do, just curious? IIRC an AGP feature which must be supported by both the chipset and the graphics card, just makes things faster, like side band addressing. Thanks to the help of Stefan and others I got my r200 to work, from Stefans lspci logs I was able to figure out why I lost my signal, it was hardware configuration related. I had to disable Fast Writes for AGP, simple solution took a bit of time to find, but anyone else having problems make sure to check that :o) Which makes perfect sense for Michal Kozlowski problem, old chipset (no / buggy fast write support) and new graphics card (with fast write support). As he (MK) said: sending commands to the AGP card directly, not having to go through memory, improving speed. Liam it depends --- 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
[Dri-devel] Website updates
Howzit? Busy going over the website doing some updating, and have a few requests. 1. have a look at the radeon features list, I think the status of a few of those features has changed. 2. Anything else on the website that you can spot that needs updating. Liam it depends --- 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
Re: [Dri-devel] Re: Fast Writes
Which makes perfect sense for Michal Kozlowski problem, old chipset (no / buggy fast write support) and new graphics card (with fast write support). This issue is also present for me, I get the same behaviour (X-server crashes, and blanks the screen) on my box, even though I've got a relatively new chipset (it's a Via KT266A) Maybe it's a general problem with Via Chipsets. Has anybody successfully tested these drivers with fast write enabled in the bios? If yes, what mainboard chipset are you using? Well I'm reasonably sure that they would work under windows perhaps I should have added No fast write support in your chipset driver (agp) cheers Liam --- 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
[Dri-devel] Re: what is hyper-z?
Howzit? what is hyper-z? a proprietary texture-compression function of the r200? well, as you expected, performance is exactly the same after the checkout as before HyperZ has 3 components: Hierarchical Z Discards hidden pixels instead of sending them to be rendered. Z-Compression Performs lossless compression on the Z co-ordinates. Fast Z-Clear Uses a fast method of clearing the Z buffer. Texture compression is something else, ie S3TC or FXTC The Radeon (R100) supports S3TC. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: The Radeon LE? (Mike Mestnik) aka Radeon naming scheme
# # List of PCI ID's # # Maintained by Martin Mares [EMAIL PROTECTED] and other volunteers from the # Linux PCI ID's Project at http://pciids.sf.net/. New data are always # welcome (if they are accurate), we're eagerly expecting new entries, # so if you have anything to contribute, please visit the home page or # send a diff -u against the most recent pci.ids to [EMAIL PROTECTED] # # Daily snapshot on Tue 2002-07-09 10:00:05 # This isn't the only place to find PCI IDs but it seems to explain all the hardware I have. You can take a look at the list if you want, but there's not mention of a card maid by ATI with an LE in it's name. The name really isn't important it's the meaning behind the name. I've got a Radeon 7500 QW Product ID 0x5157, and I also have A Radeon QL Product ID 0x514C, I didn't look at the sub device to see if That was accurate. I would like to know what the Product ID of your Radeon LE card is and I'd like to add it to the data base. If it is 0x514C then where did you learn that it's also called an LE, I'm just curious? Please in the future make it clear what your talking about to avoid confusion, it seams to me that the LE's work while the QW's don't It could be that they have different Product IDs, or that they just need to be treated as if they did. Thank you for your help in sorting this ought. I refer to my earlier email explaining the Radeon naming scheme. This is from the webpage version which I dont think Ian has had a chance to put up yet: snip Radeon Naming Scheme Original Radeons: Radeon VE (1 texture pipeline, no TCL) Radeon SDR Radeon DDR / LE Rereleased Radeons: Radeon 7000 (1 texture pipeline, no TCL) Radeon 7200 (SDR) Radeon 7500 (DDR) The only differences between the releases are more RAM and higher clock speeds (possible due to a manufacturing process shrink) on the 7X00 cards. You also get fancy versions of most of these cards eg VIVO, AIW, etc, this is just added functionality ie stick on a tv tuner, a couple of chips. The reason for the renaming is to simplify matters for end users i.e. bigger number = better / faster. Furthermore 7X00 denotes a R100 based card and 8X00 denotes a R200 based card. snip The key line here is: Radeon DDR / LE In other words they are the same card. Legend has is that ATI handed off sonme R100 chips to various companies to make Radeons with them. Up until this point all Radeons were made by ATI. These Radeons would be known as Radeon LE. They differed in that they had a different clock speed, and the silkscreen logo on them was without ATI, ie it only had Radeon on it not ATI Radeon. But the major diffence is that the BIOS had been modified so that the HyperZ functions (see other email) would not work under DirectX, but would still work under OpenGL. Basic product differentation. But *nix doesnt have Direct X so it doesnt matter. AFAIK you can flash your Radeon LE with the Radeon DDR BIOS and then it obviously wont have this problem. WRT to the 8500LE, as has been pointed out its clocked lower, I think this card is more similar to the ATI 8500 than the Radeon LE is to the Radeon DDR. I assume that I'm going to have to add this at some point to the Radeon naming scheme page. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 8500 binary snapshots now available - Status page.
Great work Keith. What I've done so far is to extend the existing radeon interfaces to accept validate the new state required for the r200, and a couple of other minor changes. This is probably the minimal set of changes to get a working r200 driver. It would seem that driver development for the R200 similar to the R100, considering how quickly this driver came out. Is this correct? A large part of this difference is presumably due to HyperZ - something that we can't implement in an open driver. Could you please explain why this is, I'd like to know and I'll add it to the documentation, I assume the same holds true for the R100. Do you think a R200_dri_features page (like the one for the R100) would be in order, would you like one? Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Radeon SourceForge d/l binaries (the ones everyones bitching about)
Hei some my friends reported that this method still not work for Radeon cards (Xserver starting but dri not work). Testing in progress... :) Me neither (I have a radeon) however it works as root / su (even in a virtual terminal under X logged in as a normal user where it wont work) which makes me think permissions, this even happens if I just install the TG binary packages. I mentioned this in a previous email, hence: This curently works as root on my box. But apperently its fixed with the latest binary packages from SF, although when I tested 20020624 last night it killed X, so... Will try 20020625 tonight. Liam it depends --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: website. (Jens Owen)
On Sun, 23 Jun 2002 22:52:09 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Smitty wrote: I want to get started putting up the new site, but no-one has told me how to access the webspace... I've given my sourceforge details and been added to the project... Ian, I can't help you with access details, but I'd like you to stage this below the current main site until we've all had a chance to look at the new format and get familiar with it. I use the current site quite a bit, and this would ease any transition for me. From what little I've seen of the new site I wouldnt worry too much about that. If you can use the old one you can use the new one. Don't be that way. I'm not being any way, I'm not actually doing the new site I am contributing to it though, I have spoken to Ian, who's doing it, I have seen screenchot.png, I have given my inputs, requests, etc. Hence: From what I've seen of the new site I wouldn't worry too much about that. Think facelift not functionality changed. (except via a nicer / better / whatever interface point of view) Jens wants an orderly transition with the opportunity to check the new website is everything that is claimed for it. If it's not, we'll have a chance to fix it before it going live. This is just common sense. That would be somewhat insulting if I was in any doubt about my (or lack there of as the case may be) common sense. g My message is now what it was then: Be calm, don't panic / worry / etc. cheers Liam --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon SourceForge d/l binaries (the ones everyones bitching about)
Well after beeing told to upgrade to XF4.2 from XF4.1 I did so: So XF4.2 Indirect rendering install the latest / last binary package from TG XF4.2 with direct rendering (no TCL) compile (not install) the latest binary package (20020623) from SF copy every file to its proper location except radeon_drv.o XF4.2 with direct rendering and TCL hey presto it works! (and is of course way faster than indirect and faster than non-TCL) Now you can use the old (TG) or the new (SF): atimisc_drv.o radeon_dri.so but this must be the old (TG) radeon_drv.o glxgears works says stuff about pagefliping quake3 works This curently works as root on my box. of course after playing mix and match with all these files as root I've also to mess up my user account but its backed up so I'll fix that - I dont think that'll be the case with anyone else. thanks to: Matti Valtonen for his valuable input: read your XFree86.0.log you tool note: he was more polite than that Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Website [update!] - frames colour
Also, the frames need a bgcolor in the body. This is a pet peeve of mine, since I have my default background set to gray. Well if I can see them then I can grab them and resize them. g I can also see this line in the old / original site? Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Website comments
From: Keith Whitwell [EMAIL PROTECTED] snip - There's no easy link to the sourceforge projects page. yes and add the hosted by SF pic below (with some space) redline2 (finishes off the menu frame nicely) - The 'status' page has disappeared change Hardware to Status in the menu frame. (makes more sense) - The 'resources' page has disappeared put a link to the 'resources' page in the menu frame. can you find the extra's package I can never find it on the old page - put it on the new one here? - All of the links in the 'developer' page point back to the 'developer' page. a lot of not implemented links eg documentation (under construction I know) - The 'help us' link dangles help us link is broken (should this be here - see below - jens) snip From: Jens Owen [EMAIL PROTECTED] snip 2) Your plea for help is spread out over the entire site. Please make sure all potential new developers are aware they should read the developer FAQ before starting in with questions on the devel list. Jens explained this to me in very simple language to me a while back when I asked about promoting DRI at university. (search archive) You could use this to explain it to all the three year olds out there who are interested in the DRI project. g From: Alexander Stohr [EMAIL PROTECTED] snip DRI Logo doesnt represent a link to home. it should be for convenience Yes all of them please, Can we have this back please : Random logo of the moment. Click here to add yours! I don't normally like fancy stuff like this, but seeings as this is a 3D graphics project, and is not required for the site to run I like it. The previous design had some headers and footers, i dont think they are required any more to help if the menu bar grafics didnt load, but for the sake of e.g. pure textmode browsers without frames they are still helpful. Further i would like some copyright statment, in the footer, even if the pages are free. Knowing the origin is important as soon as there is at least one mirror site and for people who do print or quote the pages its as well of interest. From: Leif Delgass [EMAIL PROTECTED] snip The header/footer navigation links are also useful if another site links to a URL other than the homepage, since you don't get the frameset in that case. Also, the frames need a bgcolor in the body. This is a pet peeve of mine, since I have my default background set to gray. Well if I can see them then I can grab them and resize them. g I can also see this line in the old / original site? Some comments of mine not related to others comments: In the menu frame: Home will get next to redline.png given half a chance, bump it to the next line? As a matter of personal preference I would change the br between the items in the menu bar to p to space it out a bit, I would'nt like to read that one a 14 when it gets a couple more items in it. I've attached a slightly modified menu.html which fixes the inline and spaces it out a bit. I think it's an improvement over the old site. Sorry Frank but I couldnt stand the way the old menu frame looked under Opera g Liam it depends menu.html Description: Binary data
[Dri-devel] Re: Re: website. (Jens Owen)
I want to get started putting up the new site, but no-one has told me how to access the webspace... I've given my sourceforge details and been added to the project... Ian, I can't help you with access details, but I'd like you to stage this below the current main site until we've all had a chance to look at the new format and get familiar with it. I use the current site quite a bit, and this would ease any transition for me. From what little I've seen of the new site I wouldnt worry too much about that. If you can use the old one you can use the new one. It'll just look better, have some updated content, etc. Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: agpgart, nFORCE (Al Tobey)
It's just a guess on the agp gart; the IDE and sound both are clones of the AMD chip, so why not the gart?. The big whiz-bang feature of the nFORCE chipset is the crossbar memory controller that supposedly doubles the bandwidth of DDR (double double data rate). Why would they bother creating the rest from scratch? Nevertheless, being a graphics chip company, nVidia might very well decide to create their own GART. Because Sound IDE are normally South Bridge stuff, so if they are in an AMD chipset board, they would be in the SB, and the Memory controller, AGP, would be in the NB. Unless nVidia / AMD tells you that it is the same, don't hold your breath. Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: radeon cvs problem (ahg@eng.cam.ac.uk) - binary packages
Just upgraded to the latest radeon dri-cvs (using the binary packages on SF) and now the X server won't start. This used to work fine with the 20 May TCL snapshot. The kernel module seems to load OK: Jun 19 16:30:36 localhost kernel: [drm] AGP 0.99 on Unknown @ 0xec00 64MB Jun 19 16:30:36 localhost kernel: [drm] Initialized radeon 1.3.1 20020611 on minor 0 but the X server crashes. A full XFree86.0.log is below. For comparison, the 20 May TCL produces an identical log (up to the moment it crashes) apart from: Is there any significance in the different return value from drmOpenDevice? I was using XF4.1 told that wasnt good enough and had to upgrade to XF4.2. So I did, although I'm not sure I'm getting it 100% right. Tried XFree86.org's tarballs with install script but that didnt work too well. Currently installing: XFree86-4.20-16mdk.i586.rpm XFree86-server-4.20-16mdk.i586.rpm XFree86-libs-4.20-16mdk.i586.rpm (ie rpms from cooker) over a plain install of MDK8.1 with 3D acceleration. I then get a working XF4.2 but without direct rendering. Install a new binary TCL .bz2 package off SF and I get an identical XFree86.0.log. I must still try an old TCL binary from TG instead of SF and see what happens. So you are not alone, the error has been reproduced. Although in my case I suspect the root of the problems is me. On a side note: radeon_dri.so is 5.2MB in the SF d/l and radeon_dri.so is 1.8MB in the TG d/l. Any explanation? Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Difference betwwen the packaging of the Radeon TCL binaries (TG) and the Linux Intel x86 Packages:
Howzit? Having a bit of an issue with the packages from: http://dri.sourceforge.net/snapshots/radeon-20020615-linux.i386.tar.bz2 On a clean install of Linux Mandrake 8.1 XFree 4.1 Kernel 2.4.8 etc Radeon SDR 32MB / AMD 756/758 Linux Intel x86 Packages: radeon-20020615-linux.i386.tar.bz2 Using the above breaks X with not a whole of info in /var/log/XFree86.0.log using: ./install restore - doesnt help. extras package: to /usr/X11R6/bin/XFree86 -doesnt help Radeon TCL binaries (TG) radeon-20020502-i386-Linux.tar.gz Using the above works perfectly. But now with the branch merged into the trunks (discontinued) there will be no more updates... Any ideas? Want me to grep any logs, etc and send the output in, just specify the log, what to search for etc. Bearing in mind that everything is now fine with TG binaries currently installed, and I don't really want it to break it again. Liam it depends --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: agpgart, nFORCE (Al Tobey)
On Sun, 23 Jun 2002 20:15:35 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: On Thursday 01 January 1970 00:59, Smitty wrote: Hallo Dieter It's just a guess on the agp gart; the IDE and sound both are clones of the AMD chip, so why not the gart?. The big whiz-bang feature of the nFORCE chipset is the crossbar memory controller that supposedly doubles the bandwidth of DDR (double double data rate). Why would they bother creating the rest from scratch? Nevertheless, being a graphics chip company, nVidia might very well decide to create their own GART. Because Sound IDE are normally South Bridge stuff, so if they are in an AMD chipset board, they would be in the SB, and the Memory controller, AGP, would be in the NB. Unless nVidia / AMD tells you that it is the same, don't hold your breath. Alan Cox and someone on LKM had something going. Watchout for -ac kernel changelogs and nFORCE there. Have you thried with agp_try_unsupported=1? modules.conf: [-] alias char-major-10-175 agpgart alias char-major-10-240 agpgarti810 [-] # agpgart is i386 only right now pre-install mga /sbin/modprobe -k agpgart pre-install r128 /sbin/modprobe -k agpgart pre-install radeon /sbin/modprobe -k agpgart options agpgart agp_try_unsupported=1 [-] Dankie Dieter Danke ;-) But I dont have an nForce, I have and Irongate (756/ 758). AMD 750 (751/756) Irongate C3-6 (=C5 with working bypass) ;-) Ag ja 751 (been a while since I've bothered to actually read the numbers) g Bypass does work on my board at least it does under Win98 after enabling it. cheers Liam --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tuxkart, and bug reports.. (David Willmore)
Howzit? I see that there is a very active development community and three big projects in the works (radeon, radeon TL, and mach64). Yes I've slowly realise that this is what goes on in the DRI project, a thought has been rattling around in my head of late of a simple list of who is working on what project and more specifically what they are doing eg fixing bug xyz, adding feature abc, etc. That might make it easier for new developers who come along and say I want to help on xyz / abc and he can be referred to some one relevant. Might be a good idea to keep the list private, to prevent developers being swamped by email, bug reports, etc. Hey Jens? g The re-write of the web pages should help, as well. The recent discussion on what the data/call flow charts should look like--if captured on the web site--would be an invaluable resource to get more 'power users' bootstrapped. That's the plan it is progressing, although the guy doing the website itself is a little busy at the moment. Update the web site. Having an almost undocumented web page with nightly tarballs or anon CVS access is pretty user hostile. This is all part of the plan. Oh, and I have an nVidia Riva ZX that nVidia doesn't care to support. Anyone want it? Nice little 8M AGP card looking for a loving developer... ;) A loving developer - that defnitely counts me out. g Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)
1.) MK II: _ \ +-+ | | X11/OpenGL Based Application | | | (Using 3D Direct Rendering) | | +-+ | | | | V V | +--+ ++ | | OpenGL Library | | XLib | | +--+ ++ | | | | | | | | V | | Application | | +-+ | |--User | | | GLXLib | | |Process | | +-+ | | V || | | | +-+ VV | | | | OpenGL| ++ | | | | Renderer | | DRILib | | | | +-+ ++ | | | | | || | | | | V VV V V | | +-+ +-+ | | | DRM Lib | | Protocol Encode | | | +-+ +-+ | || || _/ VV VV MMIO IOCTL SHM X Transport I would say in the most common case (single thread, single 3D context) there is only one arrow between the application and a combined Xlib/OpenGL box. This single arrow can be thought of as the primary system:display.screen connection, to use X11 DISPLAY semanitics. Which is the equivilent to the top two arrows in this diagram. OpenGL Lib XLib are just shown seperately. Okay, but this is another example of where the number of arrows is just plain confusing... nice play on words. First I want to get all the facts then I'll make it less plain and less confusing. It'll also be less confusing when I implement the alignment i was carry on about earlier. 2.) One thing that I would like to be able to show is, when you have one line going into a box and two lines coming from it, is a branch occuring or is it an either or situation. ie a choice is made and only one path is taken. It depends. There are a large number of actual entry points in each of this libraries. Some entry points may never pass data along. Others may use one or both of the paths. Doesn't it just. But it worked out ok for the X Server internals so I'd like to do it here. The X Server case is a very cut and try case, and even it isn't really implemented that way. All I'm trying to convey here is arrows can't tell the whole story, so we can't put an exact definition on what an arrow really means. Consequently, I can't give you detailed and precise feedback on how to make the arrows and boxes should look. So, use your judgement as to which looks prettier :-) It's an abstraction, it'll never mirror reality perfectly. I'm going to be doing some reading, if that resolves it I wont have to bother you about this again 3.) We need access to X Server internal data structures that the kernel doesn't have. So the X Server cant handle its resources independantly, it must co-operate / co-ordinate with DRI? ie X Server talks to kernel on its own, what does it do when there is no DRI? I believe the resource management example we looked at was window offset and cliplist. Window cliplists are controlled and updated by the X Server. Every time a window is moved, the X Server recomputes clip lists for all affected windows. The 3DDRP has to get this information from the X Server somehow. OK this could be a gross oversimplification but if I understand correctly there are two RM paths, one for 3D (3DDRP DRM Lib) and one one for 2D (X Server DRM Lib). Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)
Howzit Jens? 3 Parts to this email. 1.) MK II: _ \ +-+ | | X11/OpenGL Based Application | | | (Using 3D Direct Rendering) | | +-+ | | || V V| +--+ ++ | | OpenGL Library | | XLib | | +--+ ++ | | | | | | | | V | | Application | | +-+ | |--User | | | GLXLib | | |Process | | +-+ | | V | | | | | +-+ V V | | | | OpenGL| ++ | | | | Renderer | | DRILib | | | | +-+ ++ | | | || | | | | | |V V V V V | | +-+ +-+ | | | DRM Lib | | Protocol Encode | | | +-+ +-+ | || || _/ VV VV MMIO IOCTL SHM X Transport I would say in the most common case (single thread, single 3D context) there is only one arrow between the application and a combined Xlib/OpenGL box. This single arrow can be thought of as the primary system:display.screen connection, to use X11 DISPLAY semanitics. Which is the equivilent to the top two arrows in this diagram. OpenGL Lib XLib are just shown seperately. 2.) One thing that I would like to be able to show is, when you have one line going into a box and two lines coming from it, is a branch occuring or is it an either or situation. ie a choice is made and only one path is taken. It depends. There are a large number of actual entry points in each of this libraries. Some entry points may never pass data along. Others may use one or both of the paths. Doesn't it just. But it worked out ok for the X Server internals so I'd like to do it here. I've attached the latest WIP of control_flow.png to help show this. I did *not* receive an attachment. But you've seen it now... RM = Resource Management or = 1 of these 2 paths are followed = both of these 2 paths are followed 2D = 2D commands data 3D = 3D commands data lines in columns indicate individual paths while, lines not in columns are agregations of paths. eg's in my bit of exploded ascii art and the X Server. This becomes somewhat of an issue when you have multiple line entering and leaving a box, so if the lines should match up and don't or vice versa - let me know. I'll probably understand this question better after I see your WIP. Yup it's all part of the same question. 3.) DRMLib whats the differnce between the one in the X Server and the one in the 3DDRP? They both talk to Kernel SAREA (SHM IOCTL). Functionally they are identical, i.e. the same source code. The only distinction, and it's not critical to the diagram, is the DRMLib used in the X Server needs to be a dynamically loaded X module. The one used by the 3D client driver is statically linked into the 3D client driver's shared library. Hmmm, thinking about this some more, I wonder if the staticly linked DRMLib will be a problem if we ever try to support direct rendering to multiple heads. If each head required a different driver, then the drm symbols would colide. Sorry, just thinking out loud... Assumptions: a) The DRM Lib in the X Server gets its inputs from the RM path which comes via the X Transport between it and the 3DDRP. b) In the 3DDRP (aplpication's user process) everything except XLib has either direct or indirect access to the DRM Lib in the 3DDRP. c) Now by looking at XLib in the 2D only Program and in the 3DIRP it is not concerned with the RM path / the DRM Lib in the X Server. Would it not be better (simpler / faster) to do resource management via the DRM Lib in the 3DDRP than via the DRM Lib in the X Server? Whether it would or whether it would not and why would be useful, I think it is a reasonable question even though it has assumptions. Liam it depends N2S: hw / sw accel. * (in)direct Rendering explane dif's. ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)
Hei Jens Remember this? +---+ | X11/OpenGL Based Application| | (Using 3D Direct Rendering) | +--++ | OpenGL Library | XLib | | +++ | | | GLXLib | | +-+---++| | |Mesa | DRILib || | | | +++---+ +-+ | Protocol Encode | | Mesa Driver | | | | +-+---+-+ | | DRM Lib || +---+-+| | | | V | | | X Transport V V V MMIO IOCTL SHM Well I'd like to explode it. This is what I have so far: +-+ | X11/OpenGL Based Application | | (Using 3D Direct Rendering) | +-+ | | V V +--+ ++ | OpenGL Library | | XLib | +--+ ++ | | | | | | | V V | | | +-+ | | | | GLXLib | | | | +-+ | | | | | | V V V | | +-+ ++ | | |Mesa | | DRILib | | | +-+ ++ | | || | | | || V V V || +-+ || | Protocol Encode | || +-+ ||| V|| +-+|| | Mesa Driver ||| +-+|| || || |V V| | +-+ | | | DRM Lib | | | +-+ | || || || || || |V || | X Transport VV V MMIO IOCTL SHM Comments? One thing that I would like to be able to show is, when you have one line going into a box and two lines coming from it, is a branch occuring or is it an either or situation. ie a choice is made and only one path is taken. I've attached the latest WIP of control_flow.png to help show this. RM = Resource Management or = 1 of these 2 paths are followed = both of these 2 paths are followed 2D = 2D commands data 3D = 3D commands data lines in columns indicate individual paths while, lines not in columns are agregations of paths. eg's in my bit of exploded ascii art and the X Server. This becomes somewhat of an issue when you have multiple line entering and leaving a box, so if the lines should match up and don't or vice versa - let me know. DRMLib whats the differnce between the one in the X Server and the one in the 3DDRP? They both talk to Kernel SAREA (SHM IOCTL). Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] missing file - cntrl_flow.png
I've attached the latest WIP of cntrl_flow.png to help show this. Wasn't paying enough attention. g Liam it depends cntrl_flow.png Description: Binary data
Re: Re: [Dri-devel] Understanding the flow of data to the Graphics hardware.
Howzit Jens? Did you see the flow chart at http://dri.sourceforge.net/doc/control_flow_poster.jpg Yes, and I've worked through it. I am referring to: http://dri.sourceforge.net/doc/data_flow.jpg IMHO it doesnt make it any clearer what happens once the 2D 3D data arrives at the X Server (with its Decode Dispatch, DDX Driver, Mesa Software Renderer). Yes I can see that the data arrives at the X server, something happens to it and then it leaves (transformed). What happens in there is what I'm after. What is the sequence in those various paths through the X Server which I laid out in my previous email. Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI Links Page Submissions
Howzit? A links page was requested and this is what I have so far, have I missed anything, is anything unneccessary? If so I think you know what to do about it. Links to Projects Companies related to DRI: Chromium Project (The) http://chromium.sourceforge.net FbDri http://fbdri.sourceforge.net GATOS General ATI TV and Overlay Software http://gatos.sourceforge.net/ Mesa http://www.mesa3d.org Tungsten Graphics, Inc. http://www.tungstengraphics.com Utah-GLX http://utah-glx.sourceforge.net VA Software http://www.valinux.com XFree86(TM): Home Page http://www.xfree86.org Xi Graphics Home Page http://www.xig.com Graphics Card Manufacturers: 3dfx http://www.3dfx.com 3Dlabs http://www.3dlabs.com ATI http://www.ati.com Intel http://www.intel.com Matrox http://www.matrox.com NVidia http://www.nvidia.com Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Understanding the flow of data to the Graphics hardware.
Howzit? I would like to confirm my understanding of the various data paths between applications (both direct and indirect rendering) and the graphics hardware. First I have the path of 3D data between the 3D direct rendering program and the graphics hardware which is pretty simple. Direct rendering program (3D stuff) | Direct rendering (3D data) | 3D data | Graphics hardware Second I have the path of 2D data between the 3D direct rendering program and the graphics hardware. Here I would like some clarification where I have question marks. Direct rendering program (2D stuff) | X protocol encode (2D data) | 2D data | ? X-server ? ? Decode and dispatch ? ? DDX Driver ? | 2D data | Graphics hardware Third I have the path of 2D data between the 3D indirect rendering program and the graphics hardware. Again I would like some clarification where I have put question marks. Indirect rendering program (2D stuff) | X protocol encode (2D data) | 2D data | ? X-server ? ? Decode and dispatch ? ? DDX Driver ? | 2D data | Graphics hardware Lastly I have the path of 3D data between the 3D indirect rendering program and the graphics hardware. Again more clarification where there are question marks. Indirect rendering program (3D stuff) | OpenGL encode (3D data) | 3D data | ? X-server ? ? Decode and dispatch ? ? DDX Driver ? | 2D data | Graphics hardware Are the, ? encode , lines processes ie they create / produce the 2D (X Protocol encoding) or 3D (OpenGl encoding) data? The main thing I want to know is what happens between the Encoding and the Graphics hardware. Please point out any errors. This information will be used as part of the documentation for DRI in the form of a flow chart. cheers Liam ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Website (Michel Dnzer)
Howzit? On Fri, 2002-05-24 at 19:54, Smitty wrote: =20 6) What is required in order to produce drivers for other architectures - If people tell me this, I will add it to the 'help us' section of the site. Do you mean other architectures as in other OSs or as in other processor architectures for an already supported OS? The former depends on how similar that OS is to Linux, the latter on how similar that processor architecture is to the ones already supported. In general, the latter will be much easier because there are relatively little dependencies on the processor architecture and the most important kinds are already supported. Probably both. Although other OS's would probably be BSD or *nix. the hardware that supports eg a Radeon would probably either have its own drivers or would be running Linux / BSD / *nix. cheers Liam ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Website
Howzit? 1) I *NEED* info about what cards have what features supported by DRI, like the radeon driver does already. Don't we all. g 2) rehash the voodoo5 glide compilation to a generic voodoo guide Can not help here. 3) Can people help me compile a list of janitorial tasks that could be undertaken by new developers? perhaps installation cleanups, or trivial driver tidyups ? * 4) Can people who have information about the intimate details of card HARDWARE (eg. register locations, DMA engines, etc.) please send me them, so that I can add them to the developer documents? * 5) Can someone with a nice package re-draw the DRI flowcharts? the Precision Insight ones look like Fischer Price 'my first flowchart'... Will give this a go, but be warned of two things. One I will probably get some things wrong which will need to be fixed / pointed out by a developer. It is unlikely that it will look anything like Fischer Price I think that we still don't have that here. 6) What is required in order to produce drivers for other architectures - If people tell me this, I will add it to the 'help us' section of the site. Perhaps someone could set up a mailbox that people wanting support for other architectures could send messages to, so that demand can be guaged. * * I support making lists of these things and am also willing to make them if I am supplied with the information, even if not for the exact reasons that you want them for. DRI documents: -- 1. Introduction to the Direct Rendering Infrastructure - Brian Paul, August 2000 http://dri.sourceforge.net/doc/DRIintro.html 2. Dri term glossary. http://dri.sourceforge.net/doc/glossary.html 3. Data flow diagram http://dri.sourceforge.net/doc/data_flow.jpg 4. Control flow diagram http://dri.sourceforge.net/doc/control_flow.jpg http://dri.sourceforge.net/doc/control_flow_poster.jpg. 5. A Multipipe Direct Rendering Artitecture for 3D. Jens Owen, Kevin E. Martin. September 1998 http://dri.sourceforge.net/doc/design_high_level.html 6. Direct Rendering Infrastructure, Low-Level Design Document. Kevin E. Martin, Rickard E. Faith, Jens Owen, Allen Akin http://dri.sourceforge.net/doc/design_low_level.html 7. The Direct Rendering Manager: Kernel Suport for the Direct Rendering Infrastrucure. Rickard E. Faith http://dri.sourceforge.net/doc/design_high_level.html http://dri.sourceforge.net/doc/drm_low_level.html 8. Hardware Locking for the Direct Rendering Infrastructure. Rickard E. Faith, Jens Owen, Kevin E. Martin http://dri.sourceforge.net/doc/hardware_locking_low_level.html 9. A Security Analysis of the Direct Rendering Infrastructure. Rickard E. Faith, Kevin E. Martin http://dri.sourceforge.net/doc/security_low_level.html 10. DRI Extension for supporting Direct Rendering Protocol Specification. Jens Owen, Kevin Martin http://dri.sourceforge.net/doc/dri_extensions_low_level.txt If anyone wants a particular document updated let me know. Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI documentation
Howzit? There are a few other documents on the Insights Page that I didn't bother duplicating on the DRI page. It might be a good idea to do this now, since the Insights Page might not be around forever. Would that be ok with VA Linux/Precision Insight regarding copyright issues? I don't work for VA Linux anymore, so I can't give you any specific permissions--however, I will point out that the original low level design documents on that page are under the following license: Copyright =A9 1998-1999 by Precision Insight, Inc., Cedar Park, Texas. All Rights Reserved.=20 Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. So, you can copy them to the DRI site--but we can't modify them. Still, they might be useful to new developers trying to get some idea on early design decisions. -=-=-=-=-=-=-=-=-=- Now this poses a wee bit of a problem for any attempts to update theses kinds of documents doesnt it? Or does it? If I read it, gain an understanding of the DRI system / infrastructre and use my newfound knowledge to create my own document from scratch that's ok right. Problem is this isnt very abstract, and I'm not going to gain an encyclopeadia type knowledge of the subject matter and create a new original / vastly different document, its going to be what it is, an update of the original. Think if I /we bother them nicely they'll let me use their original as a base / template? I have no problem putting: Orignal by: Precision Insight, Inc., Cedar Park, Texas. or something to that effect but: Copyright =A9 1998-1999 by Precision Insight, Inc., Cedar Park, Texas. All Rights Reserved.=20 Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. is IMHO a bit too much, especially as they dont seem to be doing any maintainance. Ideas, comments? Liam It depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon Card Features DRI Checklist. (Damien Miller)
Hwozt damien? btw the list is now up on the (card) status page of dri.sourceforge.net. It would be really good if the status included what features are supported by the hardware. This may make it easier for interested parties to jump in and pick up pieces that they want to work on. I'm not sure I follow (I might but I'm not sure) could you be more specific. The list as it stands has the features of the Radeon, with the DRI status of each. Let me explain how I compiled the list: Tried asking the developers for features, no response which is probably a good thing, coding should be their first priority. (see archive) I let it rest for a while then came up with this plan of action. Got settings from latest ATI drivers (Win98) via config screens registry settings. Got features from ATI brochures. Googled - not much help, (try it). Drew up my list, ordered it, posted it, got some reponse, compiled it and finalised it and the status, created and hand tweaked the html table, sent it to Fank. From that you can see that DRI only became involved late in the process. You are most welcome to suggest features to be added to the list (see archive) as well as answer the Unsure of Status features. Liam it depends ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon Card Features DRI Checklist. (Ian Romanick) Spam
Howzit Ian? First off, dankie. snip Noted, used, and added a few mechanisms to deal with: I think Nvidia proprietary Texture === Cache -- Automatically supported by the hardware. Not according to Michael Ntlworld, and he backed it up. Oh and I won't post such a massive email, I'll use links.g btw the list is now up on the (card) status page of dri.sourceforge.net. One last thing, is that there is a whole list of 11 items of which status is listed as Unsure of Status. Once finished (up to date at least), the fact that this list is created I can get moving on the Rage 128, and then the Mach 64 feature lists. Spam About the spam we've been getting on the list I've heard good things about SpamCop: http://spamcop.net I believe that you need the email headers and I'm on the DRI *digest* option... Liam it depends ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon Card Features DRI Checklist.
Howzit? Here is my beta list of features I would apreciate feedback on what should be on the feature checklist, the grouping and most importantly the *status* of these features. I would like a bit more input on the status of the features, otherwise I am going to use what I have and make the final ascii version / html table which will be from contributors (below) and some editing formatting by me for comment to catch the bugs. This is about as simple as I can make it. Simply put Yes / No, HW / SW, or any other apropriate comment next to the feature. Thanks for their help and input to: Ian Romanick [EMAIL PROTECTED] Michael [EMAIL PROTECTED] Jens Owen [EMAIL PROTECTED] Added: Pixel shader Programmable texture blending modes - Projective Textures-- Changed: Mapping === Environment Bump --- Dot Product 3 Bump-- Emboss Bump Clarifcations, see: Re: [Dri-devel] Radeon Card Features DRI Checklist. Clarifications part 1 ATI R100 (Radeon) = Anti-aliasing = Full Screen Line Edge Double Buffering --- Filtering = Anisotrophic texture --- Bilinear --- Trilinear -- KTX buffer region extension Key Frame Interpolation Gamma Control -- Guard Band Clipping Mapping === Environment Bump --- Dot Product 3 Bump-- Emboss Bump Dual-Parabloid - Cubic Envionment --- Mip Perspectively Correct Texture -- Page Flipping -- Pixel shader --- Programable texture blending modes - Single-Pass Multi-Texture -- System Memory Blits Superscalar Rendering -- Specular Highlights Table Fog -- TCL Back Face Culling -- TCL Hardware --- Twin Cache Architecture Texture Units per pipeline (3) - Triangle Setup Engine -- True Colour Rendering -- Texture === Cache -- Compositing (De)Compression Projective Textures Vertical Sync -- Vertex Skinning Volume Textures W Buffer --- W Fog -- Z Plane === Z Fog -- Z Mask - Fast Z Clear --- HierachicalZ --- HyperZ - Z-buffer: 16, 24, 32 bits -- 8 bit Stencil -- Effects? Fog Effects Texture Lighting --- Video Textures - Reflections Shadows Spotlights - LOD Biasing Texture Morphing --- Video Features == Adaptive De-interlacing - Motion compensation - IDCT (sp?) -- Driver Optimisations 3DNow! - SSE SSE2 --- Liam it depends ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon Card Features DRI Checklist. Clarifications part 1
Howzit Ian? Thanks for your response. I'm not the most qualified to answer this, but I think most of the more qualified people are pretty busy adding some of these features. :) Noted. But if yours is the only response and / or there are no differing answers guess what, you will become correct (most qualified) by default. g What exactly do you mean? seems to have a suspiciously high corelation with the marketing blurb features. g In other words it's from ATI's brochures on their various cards. I'll try and clarify. ATI R100 (Radeon) = Mapping === Bump --- No. Will be possible once (if) the extension is added to Mesa. By this I am assuming you mean environment bumpmapping. Yes, Environmental bumpmapping. Emboss - What exactly do you mean? If you are refering to Nvidia's NV_texgen_emboss extension, then it will likely never be supported due to Nvidia's IP. It was in ATI's brochure, I grabbed it out of this brochure point: * Emboss, Dot Product 3 and Environment bump mapping (that's letter for letter, same layout - you decide please) Please see this ATI page on how to do it in HW with OpenGL http://www.ati.com/developer/sdk/RadeonSDK/Html/Tutorials/RadeonBumpMap.html#EMBOSS PC Paradox: (http://www.pcparadox.com/Editorials/BumpMapping/Bump2.shtml#emboss) Emboss Mapping The real name for emboss mapping is Multi-Pass Alpha Blended Bump Mapping. So as you can see, emboss mapping sorta stuck as the name. (and the acronym MPABBM really didn't seem to fit either :) Well there is a reason that emboss mapping has that weird funky name. The name is actually a great description of how this technique gets around the whole lighting problem I discussed on the previous page. But first I'd like to start off by saying that emboss mapping was the first method used to simulate bump mapping in real time, and thus was lacking in many ways. These small problems made emboss mapping look dullish and took an unnecessary amount of time for such a simple rendition of the effect. Ok, now emboss mapping achieves the bumpy effect by creating a monochrome version of the texture map being bumpified and then applying it to the polygon and shifting it slightly. To help you visualize this effect, think of a drop shadow effect, where lettering on a page has a black set of the same lettering offset just a little bit. Drop shadowing and emboss mapping are essentially the same. In emboss mapping once the monochrome version of the texture has been shifted, it is then cut and blended with the original and applied to the texture, giving it the bumpy effect. There are many limitations to emboss mapping, and here are a few. Emboss mapping only supports polygonal objects and can not be applied to a volumetric or multi-lit surfaces. Also Emboss mapping is limited to lighting coming from a certain angle (45 to -45 degrees). It can not handle more than one height of bumps because the bumping has to be uniform across the entire object. And most importantly, Emboss mapping can really slow down your CPU because of all the converting and FPU calculations it has to do to shift a texture perfectly. System Memory Blits What exactly do you mean? I'll dig up a decent definition for you, it is however from DX. Superscalar Rendering -- What exactly do you mean? Perhaps they describe the fact that the R100 renders as super-scalor rendering because it has two pipelines? From Lost Circuits: (http://www.lostcircuits.com/video/atifury/3.shtml) SuperScalar Rendering Engine The RAGE 128 uses two graphics pipelines working in concert to process two pixels each clock cycle. This kind of parallelism is typical of a superscalar architecture. Consequently, the two RAGE 128 engines which render the scene in parallel, is referred to as a Super Scalar Rendering Engine. The speed of rendering is very close to twice that of single pipelined graphic chips. Twin Cache Architecture What exactly do you mean? From PC Insights: (http://www.pcinsight.com/reviews/aiw128/aiw1283.asp) Twin Cache Architecture Of all the 3D features of the Rage 128 chip, the Twin Cache Architecture seems to stand out the most because it is unique to the Rage 128. The Rage 128 uses an 8KB buffer to store texels that are used by the 3D texel engine. In order to improve performance even more though, ATI engineers have also incorporated a 8KB pixel cache used to write pixels back to the frame buffer. From Lost Circuits: (http://www.lostcircuits.com/video/atifury/3.shtml) Twin Cache Architecture Like microprocessors, the on-chip cache in graphics chips is growing dramatically. The RAGE 128 has not only incorporated significantly more on-chip
[Dri-devel] Radeon Card Features DRI Checklist.
Howzit? Here is my alpha list of features I would apreciate feedback on what should be on the feature checklist, the grouping and most importantly the *status* of these features. (I deliberately included everything bar the kitchen sink that I can find so that I dont have to add them in future. Which means that some of it is marketing blurb.) This is about as simple as I can make it. Simply put Yes / No, HW / SW, or any other apropriate comment next to the feature. Feel free to point me to any existing list(s) indicating the level of suport that these features currently enjoy. ATI R100 (Radeon) = Anti-aliasing = Full Screen Line Edge Double Buffering --- Filtering = Anisotrophic texture --- Bilinear --- Trilinear -- KTX buffer region extension Key Frame Interpolation Gamma Control -- Guard Band Clipping Mapping === Bump --- Cubic Envionment --- Dot Product 3 -- Dual-Parabloid - Emboss - Mip Perspectively Correct Texture -- Page Flipping -- Single-Pass Multi-Texture -- System Memory Blits Superscalar Rendering -- Specular Highlights Table Fog -- TCL Back Face Culling -- TCL Hardware --- Twin Cache Architecture Texture Units per pipeline (3) - Triangle Setup Engine -- True Colour Rendering -- Texture === Cache -- Compositing (De)Compression Vertical Sync -- Vertex Skinning Volume Textures W Buffer --- W Fog -- Z Plane === Z Fog -- Z Mask - Fast Z Clear --- HierachicalZ --- HyperZ - Z-buffer: 16, 24, 32 bits -- 8 bit Stencil -- Effects? Fog Effects Texture Lighting --- Video Textures - Reflections Shadows Spotlights - LOD Biasing Texture Morphing --- Video Features == Adaptive De-interlacing - Motion compensation - IDCT (sp?) -- Driver Optimisations 3DNow! - SSE SSE2 --- ciao Liam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] New cards (GPU's) from old card makers? DRI support?
Howzit? aceshardware First there was the merger announcement by Creative and 3DLabs and the disclosure of their upcoming 76 million transistor GPU this holiday season. Then SiS surprised us at CeBit with their new SiS330 series of DirectX 8-compliant 3D accelerators. As if that wasn't enough, rumors of Matrox's return to the 3D gaming segment began to surface. And who could forget all the speculation -- and seemingly more -- surrounding the Imagination Technologies, STMicro, and VIA triangle? But just when you thought things couldn't possibly get any more interesting, another old player in the industry, Trident, has re-emerged with a new DirextX 8.1 3D graphics accelerator. /aceshardware So up to five new GPU's / architectures which leads to the obvious question(s); Are there any plans to implement drivers for these cards? Have any of the manufactureres made an approach or started asking questions about DRI? Or is this all completely off the radar screen at the moment? I love competition. cheers Liam P.S this had better not degenerate into another (near) flame fest carrying on about deferred / software / direct (emidiate) rendering, where people start mixing up their hardware concepts. g ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Downloadable Radeon TCL binaries (20020409) work with LM8.1.
Howzit? System specs: HW: AMD 751/756 (750 / Irongate) mother-board (GA-7IXE4) Radeon 32MB SDR vid card Duron (Morgan) CPU SW: Linux Mandrake 8.1 fresh install install source RPM (kernel 2.4.8 Xfree 4.1 with 3d acceleration) download: radeon-20020409-i386-Linux.tar.gz run install script as root No problems reported startx no problems Although to get it to take a shutdown (reboot) seems to be neccessary. Nice work, Frank Worsley Alan Hourihane on the install script, Tungsten Graphics for the TL for the Radeon and all the rest who work(ed) so hard on the DRI for Radeon. cheers Liam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Athlon/Kt133/Radeon QD system locks with 1GB ram
Hmm.. Another thing to check - are you sure your power supply is adequate ? Radeon chip has a fan on it for a reason. Actually the fan is there to make the Radeon look faster, it runs cool at the .18 process on wich it was manufactured. Power draw I wouldnt know, then again I run my radeon / Duron system off a 235watt ps. cheers Liam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Sorta OT: Congrats on DRI success Block Diagram Feature Checklists (Doc) proposals.
Howzit? First let me thank you for DRI bringing 3D to my Linx box, its been a while but the wait was worth it. Mandrake Linux obviously follows DRI. I have the following proposals regarding the Documentation of the DRI project. Firstly a block diagram showing how the the various aspects of 3D on Linux fit together. ie how DRI, XFree86 4.1, the window manager, Linux Kernal, OpenGL, the actual drivers for various graphics chipsets etc fits together. This I feel would make it easier to see the big picture of 3D accelleration on Linux, making it easier for people to see where things are going wrong. Secondly a Feature Checklist page for each graphics chipset / graphics card (where apropriate) showing the HW features of each card and whether or not they are implemnted in DRI / driver or the status of said function. I am willing to generate these html pages for the DRI website provided I am provide with plaintext (preferably (g)zipped) stating the name of the graphics chipset, its manufacturer, a list of its features, and the status of each of these features. You will receive a nicely formatted, simple, indexed, html page in return for each chipset / card with a hopefully easy to read / understand tabel showing the features and their status. I'm not looking for flames but the last time I checked the DRI website it had a list of cards and the status of their support, but no mention of features - I feel that this would represent an improvement. cheers Smitty ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Card Motherboard / Chipset directory.
How about a directory / database of cards and the motherboards / Chipsets that are known to work, preferably with some info on how they were gotten to work eg distro patches applied. IMHO the biggest problem people seem to have is incompatibilities between chipset and graphics card, and if you can rule that out by seeing that it (your set-up) has worked for someone else and how they got it to work, you'd be more than half-way to a running system. Liam IT depends ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
