Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
| This is encouraging to hear. Have you heard any rumblings about where | the common code base would come from? I was thinking more about the intellectual-property issues than the shared-code issues. There has been some encouraging efforts by ARB members to share source recently. nVidia, ATI, 3DLabs, and Apple have all brought forth sample implementations of their respective shading languages into the ARB. While these aren't the common code base, they are at least a step in that direction. I know it sure helps an old fart like myself understand a spec better if I can chew on some source code. Another thing MS has definitely done a better job of is requiring formal testing and certification of drivers. We've definitely fallen behind that curve with OpenGL conformance tests. The Bylaws Working Group is trying to come up with new rules for licensing that will make sharing easier (for open-source developers as well as closed-source vendors). I sure hope the new rules from the Bylaws Working Group make life easier for someone. ;-). Suzy --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
On Thu, 2003-03-06 at 15:49, Suzy Deffeyes wrote: I sure hope the new rules from the Bylaws Working Group make life easier for someone. ;-). Maybe it will be easier now MS have resigned, although that puts them in a nice position to avoid declaring patent interests and destroy OpenGL by submarine patenting games --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
On Thu, Mar 06, 2003 at 05:06:41PM +, Alan Cox wrote: | Maybe it will be easier now MS have resigned, although that puts them in a | nice position to avoid declaring patent interests and destroy OpenGL by | submarine patenting games Microsoft caught a lot of flak over their intellectual-property claim for the vertex-programming extension, but in fact they did everything properly according to the ARB rules. (Their disclosure even used the recommended language, word-for-word.) It's the rules themselves that need updating. The ARB isn't the only standards organization from which Microsoft has resigned recently. One likely reason is that they intend to pursue patent licensing more aggressively. In the case of OpenGL, this adds to the risk, but it's not a new problem. Non-ARB companies like Pixar own significant patents that could be used to sabotage open 3D APIs, and in the past even some ARB members refused to allow patented technology into OpenGL. (Anisotropic filtering is one example.) The ARB is rewriting its intellectual-property policy to help deal with the situation. It's difficult to maintain a balance; we need enough incentive for patent-holders to participate in the standards process that we can offset the potential loss-of-revenue from royalty-based licensing. There may also be some antitrust issues that have to be addressed. Allen --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
On Saturday 01 March 2003 07:19 pm, Alan Cox wrote: Old SiS - public Trident - public Drivers - none. Old SiS - Utah-GLX. They had an alpha of a driver for that chipset (I happened to have one, but not the time to pursue improving upon it at the time...). As for me and helping out, I've been a bit overwhelmed with the concerns around me- I've been for all intents and purposes unemployed for well over a year now and I've been trying to keep a house over my head, etc. Not really conducive to working on code that doesn't put food in your mouth and a roof over your head. What makes the situation with some of the older chips worse is that they're not suited, as you've noticed, to what DRI offers. They're almost better off with something else- of what, I'm not precicely sure yet. -- Frank Earl --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
Allen Akin wrote: Microsoft bears a lot of the burden for D3D by collecting and maintaining the common code (as well as nontechnical stuff like patent licensing and sublicensing). SGI didn't do that for OpenGL in the early days, and by the time it understood the problem, most hardware vendors had already invested in independent driver code bases for OpenGL. So today there's not as much sharing in the OpenGL world as there might have been. Some improvements are possible, though, and are being discussed in the ARB. Allen, This is encouraging to hear. Have you heard any rumblings about where the common code base would come from? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
Hi, Jens! On Wed, Mar 05, 2003 at 09:52:58PM -0700, Jens Owen wrote: | Allen Akin wrote: | Microsoft bears a lot of | the burden for D3D by collecting and maintaining the common code (as | well as nontechnical stuff like patent licensing and sublicensing). SGI | didn't do that for OpenGL in the early days, and by the time it | understood the problem, most hardware vendors had already invested in | independent driver code bases for OpenGL. So today there's not as much | sharing in the OpenGL world as there might have been. Some improvements | are possible, though, and are being discussed in the ARB. | ... | This is encouraging to hear. Have you heard any rumblings about where | the common code base would come from? I was thinking more about the intellectual-property issues than the shared-code issues. The Bylaws Working Group is trying to come up with new rules for licensing that will make sharing easier (for open-source developers as well as closed-source vendors). Allen --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
On Sun, Mar 02, 2003 at 01:35:08PM +, Ian Molton wrote: On Sun, 2 Mar 2003 11:58:44 + José Fonseca [EMAIL PROTECTED] wrote: To me, thats arse backwards. It should be that the documentation eases people into develpoing the code. not the other way round. But there *are* specs for the Voodoo 3, so what are you complaining about!? I'm sorry to give such breaking news, but things just _don't_ appear by themselves. Not a DRI driver, not documentation, ... *nothing*. I wasnt complaining about the voodoo3. At the time I wanted to help fix problems on my radeon 7500. I gave up, however, when it was clear no-one would give me any specs at all, unless I did something like rewrite half the driver to 'prove' myself. (the mail archives are full of stuff like that). Indeed. The mail archives show alot of people which started with the same or less resources and background as you have but did substancial constributions. Don't blame the system just because you aren't motivated or able to do the same. I agree that documentation is important and there is alot that can be done in that field, but then why don't developers-wanna-be, instead of whinning about lack of documentation, don't do something about it? Because when you're a 'developer wanna-be' you dont have the knowledge to DO anything about it. To write documentation? You probably didn't read a _single_ word of what I said in my previous post about it. Your loss. BTW, Doxygen documentation for a subset of the radeon driver, the core of Mesa, the full DRM are in the forge - under the embedded Mesa umbrella. Thats a really logical place to find them. really. (well, the mesa core, ok, but the radeon driver stuff should be under the DRI umbrella. Stop the irony. As I said above is still being written, so what do you care where I'm commiting it? The code documentation is being written in _purpose_ for the embedded Mesa and of course it's there that it is being commited to. It will, at some point and to the extent allowed by the shared code, be merged into the original sources. Anyway, once it's finished the resulting HTML pages should be hosted somewhere on DRI website, so it doesn't even matter where the documentation sources are. Note that documentation only helps until a certain point. No matter how much documented the existing code base is, No, its a matter of how documented the HARDWARE is. the code I dont really care about. Not hard to figure out code. You surely never looked to the Voodoo 3 specs, or you wouldn't say that. An existing DRI driver has much more relevant information for a developer than the hardware specs. The hardware specs basically consist of an introductory scheme of the hardware architecture plus a bunch of tables to describe the meaning of each hardware register. In rare cases, an actual programmer's manual is written, but most of the content is dedicated to 2D graphics (setting up modes, etc.), and very little to 3D. Hardware specs are only good for one thing: to write a small function around a certain functionality, and forget about them. Once these functions are written, there is very little need to look back to them. Again I feel that I'm telling things which are pretty obvious for someone who has been contact with the DRI development for some time. If you haven't realized this by now, I have little hope I can convince you otherwise, so as far as I'm concerned this thread ends here. You can get back now to your dri-has-no-docs-and-developers/ihvs-are-elitists speech for all I care. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- 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: future of DRI? - why no one plays with Glide3.
On Mon, 3 Mar 2003 14:58:01 + José Fonseca [EMAIL PROTECTED] wrote: You can get back now to your dri-has-no-docs-and-developers/ihvs-are-elitists speech for all I care. No thanks. I'll just continue reverse engineering my e740. --- 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: future of DRI? - why no one plays with Glide3.
On Mon, Mar 03, 2003 at 02:58:01PM +, José Fonseca wrote: ... An existing DRI driver has much more relevant information for a developer than the hardware specs. except for the fact that the dri cvs tree, seems to have some sort of auto-applied strip for source code on commit. As strip binaryname strips out debug information, this auto-strip seems to strip out almost all code comments. What an amazing space-saving tool... [ half :- for the humor impaired ] --- 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: 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. - documentation.
On Mon, 3 Mar 2003, Smitty wrote: 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 Neither really. ;o) I'm just expressing my opinion on how things are, and what we can realistically expect now, and in the near future, at least from my perspective. I might not be 100% correct, but it's how I see things from my current viewpoint anyway. 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. Absolutely. I think they'd (any vendor, not just ATI) do that if they really wanted to do that. I think the fact that some vendors do not do that is indicative that they don't want to do that however, or they would. ;o) 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. I don't see it as a fight at all. Aside from the very few vendors who have publically released documentation (such as 3Dfx Voodoo 3, some older Intel docs, etc.), ATI is one of the vendors who provides docs to more people under NDA than any of the other vendors, with the exception of the cards mentioned above and some other older things here and there. In other words, if the alternative to a vendors docs under NDA, is no docs at all from the vendor, I don't think we should complain. 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. Well, if people do not honour the NDAs that vendors give, it is a no brainer what will happen. If someone leaks documentation and breaks the NDA and it gets back to the vendor, the vendor is most likely just going to do one of: 1) Not provide documentation to people anymore period 2) Make the NDA more restrictive and provide documentation to less people 3) Provide watermarked docs under NDA to individuals. If docs leak, they can then sue the person who leaked them, as it is obvious due to the watermarking 4) Force developers to work right in the vendor's headquarters in a monitored room with access to docs that don't leave the premises (such as some of the Serverworks IDE work, etc.) 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? I really don't understand your point here. You are suggesting that ATI release docs to TG, and then let TG decide who gets them and who does not get them. ATI is capable of deciding who they want having their docs, and if they wanted TG to be the people to decide that, they would ask TG to do that. The fact that that has not taken place means that they are capable of deciding this on their own, and that that is not an option that they consider doing. I don't see the point of it anyway. What I was doing was putting forward a suggestion that TG may be able to get docs out of ATI easier (without screwing over ATI in the preocess). And my suggestion, is that if ATI wanted docs to go into the hands of random open source developers through TG, that they would themselves just give docs to those random open source developers, which is the way it is now. Developers get the docs from ATI, or they do not get the docs from ATI. I completely fail to see how/why/what TG has anything to do with this whatsoever. It was just a suggestion, maybe after I learn C I'll care, and argue my points with a lot more conviction. If you do not know C, the documentation would be useless to you in any case. It always seems to be the people who don't even know how to write helloworld.c that are the ones who complain about a vendor like ATI not providing them with hardware documentation that they couldn't do anything but make paper airplanes out of anyway. $0.02 -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to
Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
On Sat, Mar 01, 2003 at 04:56:18PM -0800, Jon Smirl wrote: --- Linus Torvalds [EMAIL PROTECTED] wrote: A simpler, more direct, infrastructure to the low-level driver might help. X has served us well for a long time but I just don't think it is sufficient to be the standard video platform for desktop Linux over the next ten years. We're not going to replace X overnight, but we need a path to slowly evolve it. I am amazed at the rate of change in the kernel, but X hardly seems to change at all. How can we speed things up? I agree that X is very complicated to work on. Mozilla has the same problem, everything is connected to everything. There is no way to work on a piece of Mozilla without working on the whole thing. Mozilla is trying to fix this but they still have a long ways to go. What are you speaking about ? X is pretty simple to do a driver for, it is well documented, there are multiple examples around and you have only to provide a few functions to have it working fine. As opposed to this, the DRI is quite complex. You have to first write the X driver initialization code, which include context swapping, and then the drm kernel drivers. Both of these really are somewhat complex things, and you can't really test them until you have the mesa drivers in place, and these are a nightmare to do, or even to understand how they work. And looking at the existing code is not much of a help, since they are huge. For me, a layered approach where each piece can be compiled, used and tested independently would make X much more manageable. Something like this: Yes, but it is not X that is the problem, it is the DRI, for X, things are quite simple. You follow the DESIGN document, you first set up the frambuffer code, and can already see info from X, then you do the mode switching, and finally the 2D accel stuff. In each of these phases, you get immediate feedback from X. And even Xv support is easy to test. Kernel level - fusion of DRM and FB, libDRM OpenGL - Mesa + DRI Xserver rest of X I'm sure people with more experience on X can divide it in a better way, but the key is in dividing it into smaller, more digestible chunks. These layers need to build and run independently. The DRI tree has close to 10,000 files in it right now and DRI isn't even a complete X tree. That's an awful lot of code to read and understand as a single package. But if you only look at the X drivers, they are quite small, and well documented. Friendly, Sven Luther --- 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: future of DRI? - why no one plays with Glide3.
On Sun, Mar 02, 2003 at 02:38:09AM +, Ian Molton wrote: On Sat, 1 Mar 2003 15:11:06 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: No, if that was all, it wouldnt be so bad... The project has no real documentation, theres no support from anywhere, and there is little help from hardware manufacturers. Even where there is, it doesnt encourage people to join in. What a bunch of lies!!! Have you ever been in http://dri.sourceforge.net/doc/ !? We have weekly meetings in IRC! You want encouragement from hardware manufacturers!? It's obvious that you need encouragement, but don't blame anybody except yourself. With DRI you need to 'prove' you have manly balls by blindly fixing something without any documentation. only then will you stand any chance of ever seeing any documentation. To me, thats arse backwards. It should be that the documentation eases people into develpoing the code. not the other way round. But there *are* specs for the Voodoo 3, so what are you complaining about!? I'm sorry to give such breaking news, but things just _don't_ appear by themselves. Not a DRI driver, not documentation, ... *nothing*. I agree that documentation is important and there is alot that can be done in that field, but then why don't developers-wanna-be, instead of whinning about lack of documentation, don't do something about it? When I first started with DRI and Linux (about 1.5 yrs ago) I made an huge effort to analyize about ~3 yrs worth of mails archives of two mailing lists (dri-devel and utah-glx-dev) and all the old documentation, but it was worth it. I've got a much better understanding of the architecture and the outcome was the DRI Developer's FAQ that you can read at http://dri.sourceforge.net/doc/faq/ which has all the guidelines on how to get started with DRI. Funny coincidence, the idea was given by a guy also whining about documentation, but it took somebody to atually do it. BTW, Doxygen documentation for a subset of the radeon driver, the core of Mesa, the full DRM are in the forge - under the embedded Mesa umbrella. Note that documentation only helps until a certain point. No matter how much documented the existing code base is, it will still be _hard_ to write a driver from ground up, as it take alot of lines of code, and the proporcional debugging time. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- 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: future of DRI? - why no one plays with Glide3.
On Sat, Mar 01, 2003 at 06:47:26PM -0800, Linus Torvalds wrote: | ... | At some point that won't be true any more. And maybe it's just me, but | with programmable vertex and pixel shaders it looks like the onus is | shifting onto the _user_, and it's more likely that the hardware designs | won't be changing as radically as they used to. That's possible. I often wonder whether Sutherland's Wheel of Reincarnation is still spinning. It may be that once we understand which graphics primitives *should* be hardwired, because they're flexible enough to cover the needs of the market and the performance advantages are compelling, then programmability will fall out of favor. (This has happened many times already in the graphics world, both 2D and 3D.) Or it may be that commercial issues (like the constraints of Microsoft's business model on the hardware vendors) will stop us at this stage, and graphics will begin to look a lot more like general-purpose computing. (As you suggested.) Only the first case permits long-term improvement that's much better than Moore's Law. I'd like to think we still have a few more spins of the Wheel to go, but at the moment the evidence for that is weak. | ... | If and when a driver decides that they can do something better _without_ | the help of generic code, it just expands the functionality itself - | without breaking anything else, and without taking the overhead of having | to go through any generic code that conditionally calls to the direct | stuff. Sure. Vertical modularity, rather than horizontal. It works well as long as there's not too much shared state that has to be kept in sync for all the code paths. (By the way, this is one area where I suspect current low-level 3D APIs are making life unnecessarily difficult for us.) | Once you get rid of the legacy stuff in OpenGL, drivers are pretty much | the same level of complexity for OpenGL as for D3D. Which is one reason | why several groups are able to use OpenGL subsets for embedded apps. | | I'll take your word for it. I'm not an expert on it -- I'm just going by what I've heard in open ARB discussions. Embedded OpenGL-subset drivers are dropping below 50KB these days. (Depends a lot on the underlying hardware, of course.) Allen --- 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: future of DRI? - why no one plays with Glide3.
On Sun, Mar 02, 2003 at 12:57:42AM -0500, Daniel Vogel wrote: | On Sat, 1 Mar 2003, Allen Akin wrote: | | Once you get rid of the legacy stuff in OpenGL, drivers are pretty much | the same level of complexity for OpenGL as for D3D. | | I guess you also had to take away mandatory software fallbacks and the | imaging subset. ... Sure, and all the other stuff that's important to OpenGL apps that's not important to D3D apps. (Antialiased lines come to mind.) Otherwise we wouldn't be making a valid comparison. | ... In reality though, every IHV I've talked to stated their | OpenGL drivers being far more complex to maintain. Sure, because their drivers *do* have to include all the stuff that's important to OpenGL apps and not important to D3D apps. :-) There's at least one other important reason. Microsoft bears a lot of the burden for D3D by collecting and maintaining the common code (as well as nontechnical stuff like patent licensing and sublicensing). SGI didn't do that for OpenGL in the early days, and by the time it understood the problem, most hardware vendors had already invested in independent driver code bases for OpenGL. So today there's not as much sharing in the OpenGL world as there might have been. Some improvements are possible, though, and are being discussed in the ARB. Allen --- 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: 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] Re: future of DRI? - why no one plays with Glide3.
On Sun, 2003-03-02 at 01:55, Jon Smirl wrote: --- Alan Cox [EMAIL PROTECTED] wrote: People were saying that ten years ago. They were wrong then, and I suspect they are wrong now. Looking out five years wouldn't OpenGL 2.0+ make a better core graphics API for Linux than XLIB? Hardware is certainly trending towards the 3D model. If you care which one of the two, your higher level abstraction is wrong IMHO. I'd like to see Linux turn XFree inside out. Instead of OpenGL/DRI being bolted onto X, bolt X onto OpenGL/DRI. Radeon already uses DRI to do some of the rendering stuff when also doing 3D. You can choose to implement your XAA accelerations with 3D primitives, or you can go up a layer higher. There is definitely scope for a server which treats all the 2D objects as textures. It makes stuff like alpha a lot lot simpler but at a memory cost. --- 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: future of DRI? - why no one plays with Glide3.
On Sun, 2003-03-02 at 19:15, Allen Akin wrote: | Once you get rid of the legacy stuff in OpenGL, drivers are pretty much | the same level of complexity for OpenGL as for D3D. Which is one reason | why several groups are able to use OpenGL subsets for embedded apps. | | I'll take your word for it. I'm not an expert on it -- I'm just going by what I've heard in open ARB discussions. Embedded OpenGL-subset drivers are dropping below 50KB these days. (Depends a lot on the underlying hardware, of course.) Indeed Fabrice Bellard wrote an open source one, coming in at a whole 68K tar.gz. http://fabrice.bellard.free.fr/TinyGL/ --- 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: future of DRI? - why no one plays with Glide3. - documentation.
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 A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- 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: future of DRI? - why no one plays with Glide3.
Ian Molton wrote: On Sat, 1 Mar 2003 15:05:37 -0500 (EST) Mike A. Harris [EMAIL PROTECTED] wrote: Look at the Intel i8x0 driver for example. The Intel specs are publically available, and Intel funds development of the driver. The hardware is readily available too. Yet there is not any major contributions to the code at all other than what is produced by funded development. I think, sadly, its because the hardware is shit. even on windows, i8x0 performs worse than a voodoo 3 by a LARGE margin... The newer chipsets (supported by the i830 driver) are a lot faster than the originals. Additionally, the driver until recently (ie before the last lot of changes done by David Dawes I) didn't do a good job of setting up tiling, which was vital to decent performance. I don't have one up running to give numbers, but they have come along considerably since the i810/i815. Keith --- 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: future of DRI? - why no one plays with Glide3.
On Sun, 2 Mar 2003 11:58:44 + José Fonseca [EMAIL PROTECTED] wrote: To me, thats arse backwards. It should be that the documentation eases people into develpoing the code. not the other way round. But there *are* specs for the Voodoo 3, so what are you complaining about!? I'm sorry to give such breaking news, but things just _don't_ appear by themselves. Not a DRI driver, not documentation, ... *nothing*. I wasnt complaining about the voodoo3. At the time I wanted to help fix problems on my radeon 7500. I gave up, however, when it was clear no-one would give me any specs at all, unless I did something like rewrite half the driver to 'prove' myself. (the mail archives are full of stuff like that). I agree that documentation is important and there is alot that can be done in that field, but then why don't developers-wanna-be, instead of whinning about lack of documentation, don't do something about it? Because when you're a 'developer wanna-be' you dont have the knowledge to DO anything about it. BTW, Doxygen documentation for a subset of the radeon driver, the core of Mesa, the full DRM are in the forge - under the embedded Mesa umbrella. Thats a really logical place to find them. really. (well, the mesa core, ok, but the radeon driver stuff should be under the DRI umbrella. Note that documentation only helps until a certain point. No matter how much documented the existing code base is, No, its a matter of how documented the HARDWARE is. the code I dont really care about. Not hard to figure out code. it will still be _hard_ to write a driver from ground up, as it take alot of lines of code, and the proporcional debugging time. Of course. --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003, Smitty wrote: The 3Dfx Voodoo 3 and Banshee specs are available, as are docs for other 3D hardware. Who is working on that right now? 3Dfx released the source code of Glide3 for example. I dont think a single line of code has been written for Glide3 for 2 years now. Probably because, 3DFX is dead, I completely realize that 3Dfx is dead. My point is that even when they were alive still at the end, there wasn't much going on with the 3Dfx drivers. a V3 gets smacked around by a TNT2, Not with open source drivers it doesn't. Glide is not neccessary if you have OpenGL or DirectX, and Glide is low level 3dfx only. I'm also well aware of that. A useless API for old and slow not to mention dead technology. Yes, it is. But you missed my point. The point being that code exists and nobody is hacking on it. I'm not *blaming* anyone. Volunteers work on what volunteers are interested in working on. That's obviously not Glide3. Point is, there is code and docs that have been available to people that have not seen much contributions at all except by funded development. Look at the Intel i8x0 driver for example. The Intel specs are publically available, and Intel funds development of the driver. The hardware is readily available too. Yet there is not any major contributions to the code at all other than what is produced by funded development. This is hardware that is brand new, and by a company that is not dead. Forgive my bad example of choosing 3Dfx and Glide3. Which is probably why Molton is trying to instigate a divorce from Glide for the V3. I certainly support that move. Anholt was working on Glide3 recently a bit as well. I dunno how far he got, but I've been meaning to ask. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- 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: future of DRI? - why no one plays with Glide3.
On Sat, Mar 01, 2003 at 03:05:37PM -0500, Mike A. Harris wrote: On Sat, 1 Mar 2003, Smitty wrote: a V3 gets smacked around by a TNT2, Not with open source drivers it doesn't. got some specs on how the V3 performs, with glxgears? google only pulled up results from someone who said their setup seemd to not be configured properly. (68 FPS) --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003 15:05:37 -0500 (EST) Mike A. Harris [EMAIL PROTECTED] wrote: Look at the Intel i8x0 driver for example. The Intel specs are publically available, and Intel funds development of the driver. The hardware is readily available too. Yet there is not any major contributions to the code at all other than what is produced by funded development. I think, sadly, its because the hardware is shit. even on windows, i8x0 performs worse than a voodoo 3 by a LARGE margin... --- 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: future of DRI? - why no one plays with Glide3.
Mike A. Harris [EMAIL PROTECTED] wrote: On Sat, 1 Mar 2003, Smitty wrote: Which is probably why Molton is trying to instigate a divorce from Glide for the V3. I certainly support that move. Anholt was working on Glide3 recently a bit as well. I dunno how far he got, but I've been meaning to ask. Ian Molton got a Voodoo3 3k from me but he yet did not manage to have the time for necessary work on that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003 03:56:42 +0200 Smitty [EMAIL PROTECTED] wrote: Which is probably why Molton is trying to instigate a divorce from Glide for the V3. Well, more a merge of glide into the driver, at least short term. (oh, and please, I prefer being referred to by my first name.) I have two other projects taking precedence right now though, sadly. I *do* intend to get it going though. --- 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: future of DRI? - why no one plays with Glide3.
On Sun, 2003-03-02 at 04:05, Mike A. Harris wrote: On Sat, 1 Mar 2003, Smitty wrote: Yes, it is. But you missed my point. The point being that code exists and nobody is hacking on it. I'm not *blaming* anyone. Volunteers work on what volunteers are interested in working on. That's obviously not Glide3. Point is, there is code and docs that have been available to people that have not seen much contributions at all except by funded development. Look at the Intel i8x0 driver for example. The Intel specs are publically available, and Intel funds development of the driver. The hardware is readily available too. Yet there is not any major contributions to the code at all other than what is produced by funded development. I think the Intel 8x0 is also a bad example. Precisely because the XFree86 and DRI drivers are funded by Intel that volunteer work shifts to other areas (fbdev, DirectFB). Secondly, these old Intel chipsets are not a natural choice for doing 3D (70-100 fbs with glxgears :-). Not worth concentrating on with regards to 3D. AFAIK, there are at least 2 versions of the i810 framebuffer driver publicly available, both of which are not possible without the public docs. For the more popular cards, volunteer work exists, not in the hundreds, but significant enough to make a dent. Take Matrox for instance. A significant amount of code is contributed with regards to DirectFB and mplayer. Once in a while, people will request for specifications concerning ATI cards in various mailing list. Whether they'll spend significant developer effort is anyone's guess. I'm not advocating open sourcing hardware specs. If manufacturers do, that's excellent. If they don't, I respect that decision. Tony --- 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: future of DRI? - why no one plays with Glide3.
On Sun, 2003-03-02 at 07:11, Linus Torvalds wrote: On 2 Mar 2003, Antonino Daplas wrote: AFAIK, there are at least 2 versions of the i810 framebuffer driver publicly available, both of which are not possible without the public docs. I don't think that answers Mike's criticism that open-source developers don't tend to work on DRI. And I think he's right. The reason you find open-source people working on fbdev and mplayer etc is because those tend to be _easier_ projects to get into. Don't get me wrong, I completely agree with Mike when he said that, to paraphrase, hundreds will not flock to code for DRM except for a stout few. I just meant that nobody is contributing to i810 development because it is a dead-end chipset for DRI. However, I still believe enough in open source that if Intel did not provide drivers for them, nor pay a coder to do it, someone in the multitude will. Tony --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 2003-03-01 at 23:11, Linus Torvalds wrote: Quite frankly, DRI is the project from hell when it comes to getting into it, and I think that's largely because you have to have all the pieces in place to get something working, and you have to understand a wide range of different issues (you can't just understand hardware, you also have to have some understanding of OpenGL). In addition even if you know the pieces its a lot of work to make it do anything - but getting better. DRI now has credible documentation but it still has stuff like each card using its own vertex arrays, texture manager and the like. Thats one reason I'd love to see the C++ framework proposed. Hell I can draw triangles on my SiS6326, its just there isn't a way to plug that code into an existing framework yet. Add to that the fact that for many of the common chipsets documentation is hard to get (common here not being in absolute numbers, but in the kind of hw that people who are really interested in 3D would want to buy), and it's no wonder that there aren't that many people working on it - there are just a lot of things working _against_ new people. Old SiS - public Trident - public Drivers - none. I _suspect_ that the fact that most modern graphics cards are designed mainly for DirectX might make the whole thing slightly worse (ie just from causing some additional disconnect between what the hardware does and what the interfaces are). DirectX affects 2D mostly - it means some of the line drawing hardware is broken for X. A simpler, more direct, infrastructure to the low-level driver might help. I suspect that is why MS started doing D3D in the first place, Mesa vertex lists seem suspiciously D3D like to me --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 2003-03-01 at 20:28, Philip Brown wrote: got some specs on how the V3 performs, with glxgears? google only pulled up results from someone who said their setup seemd to not be configured properly. (68 FPS) On the voodoo gears is a fine way to measure your monitor refresh rate. The voodoo is suprisingly snappy. Even my old Voodoo2 beats the Matrox G400 --- 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: future of DRI? - why no one plays with Glide3.
On 2 Mar 2003, Alan Cox wrote: Thats one reason I'd love to see the C++ framework proposed. Hell I can draw triangles on my SiS6326, its just there isn't a way to plug that code into an existing framework yet. I think this is the perfect example of hard to get into. A person who knows what he's doing, has documentation, hardware and motivation, and _still_ finds it hard to actually get started at doing anything. Yeah, you can't expect to get Doom 3 working overnight. But if there was some _simple_ way to get some very basic initial stuff working in a driver, that might make people more able to get into it. Linus --- 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: future of DRI? - why no one plays with Glide3.
--- Linus Torvalds [EMAIL PROTECTED] wrote: A simpler, more direct, infrastructure to the low-level driver might help. X has served us well for a long time but I just don't think it is sufficient to be the standard video platform for desktop Linux over the next ten years. We're not going to replace X overnight, but we need a path to slowly evolve it. I am amazed at the rate of change in the kernel, but X hardly seems to change at all. How can we speed things up? I agree that X is very complicated to work on. Mozilla has the same problem, everything is connected to everything. There is no way to work on a piece of Mozilla without working on the whole thing. Mozilla is trying to fix this but they still have a long ways to go. For me, a layered approach where each piece can be compiled, used and tested independently would make X much more manageable. Something like this: Kernel level - fusion of DRM and FB, libDRM OpenGL - Mesa + DRI Xserver rest of X I'm sure people with more experience on X can divide it in a better way, but the key is in dividing it into smaller, more digestible chunks. These layers need to build and run independently. The DRI tree has close to 10,000 files in it right now and DRI isn't even a complete X tree. That's an awful lot of code to read and understand as a single package. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- 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: future of DRI? - why no one plays with Glide3.
On Sun, 2003-03-02 at 00:56, Jon Smirl wrote: X has served us well for a long time but I just don't think it is sufficient to be the standard video platform for desktop Linux over the next ten years. People were saying that ten years ago. They were wrong then, and I suspect they are wrong now. Too many people think X11 == XFree86. XFree86 is an *implementation* (arguably two with kdrive) of X11. change in the kernel, but X hardly seems to change at all. How can we speed things up? X changes, its just its very good at not breaking stuff and Xfree itself tends to be deeply conservative, perhaps overly so. XFree86 has been acquiring render extensions, rotation, resize on the fly, a sophisticated security model for partitioning untrusted applications, and much more, its just nobody noticed most of these except maybe the new font stuff. I agree that X is very complicated to work on. Mozilla 2D XFree86 is *easy* to work with. It took me a day to learn how to write input drivers, it took me a couple of days to learn how the X driver model worked to rewrite the Cyrix driver to actually work. You can write a 2D Xserver in under a week. You might spend a while longer debugging it because all the hardware has crazy bugs. 2D XFree you copy a driver example, fill in your PCI idents and your mode switch code. Compile, debug and you have an unaccelerated X server. You plug in a set of standard Xaa routines one at a time and you get more and more acceleration. You copy the Xv example code fill in the blanks and you get video overlay support. Since XFree 4.0 you don't have to touch the core code, you don't have to duplicate a ton of stuff and you don't need to know zip about DDX, MI and the other core layers. Alan --- 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: future of DRI? - why no one plays with Glide3.
--- Alan Cox [EMAIL PROTECTED] wrote: People were saying that ten years ago. They were wrong then, and I suspect they are wrong now. Looking out five years wouldn't OpenGL 2.0+ make a better core graphics API for Linux than XLIB? Hardware is certainly trending towards the 3D model. I'd like to see Linux turn XFree inside out. Instead of OpenGL/DRI being bolted onto X, bolt X onto OpenGL/DRI. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- 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: future of DRI? - why no one plays with Glide3.
On 2 Mar 2003, Alan Cox wrote: Since XFree 4.0 you don't have to touch the core code, you don't have to duplicate a ton of stuff and you don't need to know zip about DDX, MI and the other core layers. Yeah, I don't think regular X is problematic. The Xv stuff used to be quite messy, but even that seems simpler these days (although I also haven't had any real reason to worry about it any more, so maybe I just _think_ it's cleaner these days). The lack of commit rights to the X tree might be a problem for some, but I don't think regular 2D X has anywhere _near_ the kind of lack of people and time that DRI ends up having. Partly because the problem set is simpler, I'm sure. But also largely because the abstraction issues _have_ been worked on for a long time and it's just easier to do a driver these days as a result. Linus --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003, Jon Smirl wrote: I'd like to see Linux turn XFree inside out. Instead of OpenGL/DRI being bolted onto X, bolt X onto OpenGL/DRI. It might not even be that painful to try. X largely should support things like that simply thanks to the fact that people have already worked hard at embedding X on top of other things, notably the X on Darwin stuff. And with Keith already having an embedded DRI working on top of fbdev.. The proof is in the pudding. Linus --- 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: future of DRI? - why no one plays with Glide3.
On Sat, Mar 01, 2003 at 03:11:06PM -0800, Linus Torvalds wrote: | | ... you have to understand a | wide range of different issues (you can't just understand hardware, you | also have to have some understanding of OpenGL). | ... | Look at the size of a 3D driver today, and _especially_ look at how it | actually needs at least three totally separate parts - the generic OpenGL | part, the card-specific part, and the kernel part. None of which are in | any way independent from each other (the generic OpenGL part should be, | but as can be seen from what both Nvidia and ATI have done, it ends up | being tied into the low-level driver _anyway_ because of issues like | feature reporting). This is largely because there's a *much* greater emphasis on performance in the 3D world than in the 2D world. There's too much competitive advantage to be gained by exposing hardware peculiarities and by avoiding certain kinds of abstraction. For example, it's usually too expensive (in terms of call overhead and data transfer/reformatting) to use layering as technique for driver implementation. 3D systems tend to have vertical modules rather than layers -- selected execution paths are mapped as closely to the hardware as possible. This means that there's a lot of device-dependent code starting right underneath the API, and consequently less code shared between drivers. Graphics programmability eliminates layering altogether and moves application logic very close to the hardware, at least until the Wheel of Reincarnation spins again. :-) | A simpler, more direct, infrastructure to the low-level driver might help. | I suspect that is why MS started doing D3D in the first place... There were two key factors that led to D3D: A lack of technical understanding of 3D (leading some people at MS to claim that OpenGL could never be used for games), and a business model that required monopoly control of the API (in order to force the hardware to be commoditized). As Microsoft learned what it was doing wrong technically, D3D rapidly appropriated features and design concepts from OpenGL. Around DX7 it reached parity on the things that were necessary for gaming, and started to diverge rather than converge. D3D adopted programmability more quickly than OpenGL. There were many reasons for this, but a couple of interesting ones are (1) once D3D no longer had a target to copy, it was less clear which special-purpose functionality should be put into the API, so general-purpose programmability offered a way forward; and (2) Microsoft's business is based on product differentiation in software rather than in hardware. Once you get rid of the legacy stuff in OpenGL, drivers are pretty much the same level of complexity for OpenGL as for D3D. Which is one reason why several groups are able to use OpenGL subsets for embedded apps. Allen --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003, Allen Akin wrote: This is largely because there's a *much* greater emphasis on performance in the 3D world than in the 2D world. There's too much competitive advantage to be gained by exposing hardware peculiarities and by avoiding certain kinds of abstraction. Well, hey, that used to be the answer for 2D too. A lot of people thought that the layering in XAA would hurt performance. I think you're right, but I also think it's all partly because hw changes are stil happening at breakneck speeds, and so the equation keeps on changing on what the right layering is. At some point that won't be true any more. And maybe it's just me, but with programmable vertex and pixel shaders it looks like the onus is shifting onto the _user_, and it's more likely that the hardware designs won't be changing as radically as they used to. For example, it's usually too expensive (in terms of call overhead and data transfer/reformatting) to use layering as technique for driver implementation. I'm actually not a huge fan of layering as a technique anyway - the fact is, the upper layers just tend to do the wrong things. But you can have high-level helper functions - things that aren't called directly the generic layer, but that exist solely to make it easier to build up a driver. If and when a driver decides that they can do something better _without_ the help of generic code, it just expands the functionality itself - without breaking anything else, and without taking the overhead of having to go through any generic code that conditionally calls to the direct stuff. This is largely what the Linux kernel approach to filesystems usually is (the exception being pathname lookup, which is just something that the VFS layer does on its own, and the filesystem is required to play along with the VFS rules). So each filesystem gets to do its own read() however the hell it wants to, but the VFS layer exports helper functions that 95% of all filesystems use, and thus they don't usually actually need to do much. Almost all filesystems use the generic_file_read() function directly, for example. The flexibility is that the helper functions end up working more like available templates, rather than forcing the VFS layering down the throat of a filesystem. I think a similar approach works just about anywhere, except it's usually _harder_ to come up with good helper functions than it is to just force subsystems to act some way. Once you get rid of the legacy stuff in OpenGL, drivers are pretty much the same level of complexity for OpenGL as for D3D. Which is one reason why several groups are able to use OpenGL subsets for embedded apps. I'll take your word for it. Linus --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003, Jon Smirl wrote: X has served us well for a long time but I just don't think it is sufficient to be the standard video platform for desktop Linux over the next ten years. We're not going to replace X overnight, but we need a path to slowly evolve it. I am amazed at the rate of change in the kernel, but X hardly seems to change at all. How can we speed things up? I believe it can be done by creating an X devlopment community/environment that is more conducive to future progress, and more open, accepting, and encouraging of new developers. The DRI project IMHO works pretty good in this aspect for ages now. For me, a layered approach where each piece can be compiled, used and tested independently would make X much more manageable. Something like this: Kernel level - fusion of DRM and FB, libDRM OpenGL - Mesa + DRI Xserver rest of X I'm sure people with more experience on X can divide it in a better way, but the key is in dividing it into smaller, more digestible chunks. These layers need to build and run independently. I can't agree more. I think X should be broken into several pieces personally that are independant of each other. The drivers should be decoupled from the huge monolithic sources IMHO, and built separately against a DDK of some kind. Not unlike the existing XFree86 sdk that I don't believe anyone uses currently. I'm investigating this currently in my tinkerings. I'd like to split up X sources sometime in the future into at least: 1) fonts 2) docs 3) video drivers 4) various applications not needed at X server build/install time 5) X server and everything else That's just phase 1 idea. I think it oculd be broken down much finer than that. The benefits IMHO would be large. The DRI tree has close to 10,000 files in it right now and DRI isn't even a complete X tree. That's an awful lot of code to read and understand as a single package. Agreed. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003 15:11:06 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: Quite frankly, DRI is the project from hell when it comes to getting into it, and I think that's largely because you have to have all the pieces in place to get something working, and you have to understand a wide range of different issues (you can't just understand hardware, you also have to have some understanding of OpenGL). No, if that was all, it wouldnt be so bad... The project has no real documentation, theres no support from anywhere, and there is little help from hardware manufacturers. Even where there is, it doesnt encourage people to join in. With DRI you need to 'prove' you have manly balls by blindly fixing something without any documentation. only then will you stand any chance of ever seeing any documentation. To me, thats arse backwards. It should be that the documentation eases people into develpoing the code. not the other way round. --- 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: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003, Allen Akin wrote: Once you get rid of the legacy stuff in OpenGL, drivers are pretty much the same level of complexity for OpenGL as for D3D. I guess you also had to take away mandatory software fallbacks and the imaging subset. In reality though, every IHV I've talked to stated their OpenGL drivers being far more complex to maintain. -- Daniel, Epic Games Inc. --- 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: future of DRI? - why no one plays with Glide3.
On Sun, Mar 02, 2003 at 12:57:42AM -0500, Daniel Vogel wrote: I guess you also had to take away mandatory software fallbacks and the imaging subset. In reality though, every IHV I've talked to stated their OpenGL drivers being far more complex to maintain. The question is does that really mean one or both of, 1) we have to pay our OpenGL developers more 2) we dont have enough people on staff who understand OpenGL -- all our people are trained on the latest microsoft stuff as #1 priority --- 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
