From: Jon S. <jon...@ya...> - 2003-02-28 18:03:10
|
It is a fact that Microsoft Longhorn and the Mac GUI are moving towards 3D hardware for their base GUI. It is also a fact that it will take a lot of effort and probably several years to move X in the same direction. Personally I don't want to see Linux in the position of having the new 3D effects in Windows and the Mac and not being able to respond. I'm willing to put some time and effort into this and maybe other are too. I don't buy the "support old hardware" argument for stopping the forward progress of DRI. With that argument we'd still all be running in X86 real mode and the Athlon-64 would be pointless. Backwards compatibility is important and fallbacks should be provided, but it's not a reason for stopping the use of new hardware features. So what is the best design for achieving this? The project has to have DRI at it's core since it's the only choice for 3D acceleration on Linux. We also have to preserve X Windows compatibility for all of the existing apps. My first thought would be to get DRI running standalone (like the fbdri project but sync'd to CVS) then modify X to load on top of the standalone DRI. After that works rework the 2D X driver to use the DRI API instead of using the hardware directly. The reasoning behind a standalone DRI is to make it easier to build a 3D windowing system. To create a 3D windowing system a mechanism is needed to get existing X windows into textures so that they can be transformed. If it proves too hard to alter X, standalone DRI would allow X to be replaced with something like NanoX. Another solution would be to leave everything as is. Then 3D enable the root window and start hacking on the existing X windowing system. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Daniel V. <vo...@ep...> - 2003-02-28 20:00:18
|
> So what is the best design for achieving this? The > project has to have DRI at it's core since it's the > only choice for 3D acceleration on Linux. Ironically, the only real choice for 3D acceleration on Linux is using NVIDIA and ATI's (non DRI) binary drivers. Does DRI have a future with neither NVIDIA nor ATI participating? Are people actually talking to them about why they don't use it and what has to be done to remedy this fact? Shouldn't this be a top priority? Without support for recent cards, DRI will become completely obsolete. -- Daniel, Epic Games Inc. |
From: Jon S. <jon...@ya...> - 2003-02-28 20:26:06
|
--- Daniel Vogel <vo...@ep...> wrote: > Does DRI have a future with neither NVIDIA nor ATI > participating? I really don't understand ATI's position on Linux drivers. They have better hardware but they are losing because of their drivers. I can't think of a better solution than having a couple hundred highly skilled, performance obsessed, unpaid hackers fixing their code for them. ATI and Nvidia have both disassembled each other's drivers so there are no secrets between the two. Another argument could be that a another chip manufacturer could clone a chip and use the drivers for free. I don't see that happening given the complexity of the chips. Finally ATI could be afraid of patent issues by opening the source. But this would just make the patent issues slightly easier to find, they'd still have the same problems with closed source. If they were being accused the lawyers would get the source anyway. What about bad fixes to the code? ATI can just control the CVS and only apply patches that they are happy with. ATI should continue with their paid developers, just make their changes public too. Linux programmers like to fix things when they are broken. I just removed the ATI radeon drivers from my system and went back to the DRI ones. About once a day the ATI driver will lock up. If I had the source I would have poked around and tried to fix it. Without the source I threw the drivers in the trash. ATI is really underestimating the skills of some of the hackers in the Linux community. Some really good code comes out of those long Siberian/Finnish winters. They are also missing the opportunity to lead in a fast growing market. Just look of the cover of Business Week. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Mike A. H. <mh...@re...> - 2003-02-28 20:56:38
|
On Fri, 28 Feb 2003, Jon Smirl wrote: >> Does DRI have a future with neither NVIDIA nor ATI >> participating? > >I really don't understand ATI's position on Linux >drivers. They have better hardware but they are losing >because of their drivers. I can't think of a better >solution than having a couple hundred highly skilled, >performance obsessed, unpaid hackers fixing their code >for them. This is not an argument against such a possible source code release, but I'm merely trying to be realistic here. I don't see 100 unpaid hackers hacking feverishly on anything X related right now. Why would 100 unpaid hackers come out of the woodwork all of a sudden? Quite unrealistic. What would really happen, would be the existing DRI team members, and others closely working on DRI _right_now_ would look at it likely, and probably work on it, and possibly a small number of new people too. I doubt there would be even 5 new people touching the code if that. >ATI and Nvidia have both disassembled each other's >drivers so there are no secrets between the two. Is there evidence to support this claim, or is it merely conjecture? >Another argument could be that a another chip manufacturer could >clone a chip and use the drivers for free. I don't see that >happening given the complexity of the chips. Another argument is that the binary drivers of both companies most likely contain 3rd party intellectual property, and patented techniques, some of which they themselves may have patented, and others which they have possibly licensed from other companies, perhaps many companies. Would all of those companies want to have their IP instantly open sourced and free for all to see/use? While I would love nothing more than to see that, I highly doubt that either ATI or Nvidia have the legal rights to open source the entire source code of all of their drivers. Parts of them perhaps, but I doubt all of them, and even then parts of them would be patent encumbered still. >Finally ATI could be afraid of patent issues by opening the >source. But this would just make the patent issues slightly >easier to find, they'd still have the same problems with closed >source. If they were being accused the lawyers would get the >source anyway. Not ATI - any vendor. You assume perhaps that there are perhaps patents being violated and these companies want to hide something, and by opening their code they could get sued. A more likely hypothesis is that they have licensed patented technology themselves and have the right to use it in their products, drivers, etc. but do not have the right to give it to other people or distribute the source code. That is not at all unrealistic to assume. There is also the threat that the code might contain something unknowingly is patented, such as a technique totally invented on one's own, that just coincidentally was invented by someone else first and patented. Opening up source code can cause other companies to jump in and see which of their patents you might have violated so they can sue you. Again, this isn't an argument against opening of such code, but rather an attempt to explain some real life reasons why some companies do not do so. >What about bad fixes to the code? ATI can just control the CVS >and only apply patches that they are happy with. ATI should >continue with their paid developers, just make their changes >public too. I'm sure if there weren't other reasons already that this would not be a problem. >Linux programmers like to fix things when they are broken. I >just removed the ATI radeon drivers from my system and went back >to the DRI ones. About once a day the ATI driver will lock up. >If I had the source I would have poked around and tried to fix >it. Without the source I threw the drivers in the trash. I agree with you, and many people on this list would want to twiddle with the source as well. We're the minority however. Most people do not want to hack on source code of software that doesn't work for them, even fewer on device drivers, and even fewer on video drivers. >ATI is really underestimating the skills of some of the hackers >in the Linux community. Some really good code comes out of >those long Siberian/Finnish winters. They are also missing the >opportunity to lead in a fast growing market. Just look of the >cover of Business Week. I completely disagree here. For the above paragraph to be true, ATI would have to be sitting there in Markham thinking "Well, we would release the source code of our binary drivers, but the open source community isn't talented enough, so we wont." Not only do I think that is not the case of what they think, I think it is not even in the equation. I have no idea what ATI, Nvidia, Kyro, or any other video hardware vendor's explicitly detailed reasons are for not releasing the complete source code to their drivers is, however I do understand enough to be able to piece together several legal and other reasons why they would. None of those reasons result in me thinking any of these vendors doubts the open source community is capable of hacking on source code. I would bet money, that the number 1, 2, and 3 reasons are entirely legal reasons surrounding intellectual property and other issues. While I totally am on the side of the fence that would love to see source code released of such drivers from _all_ vendors, I don't expect them to fully release the code of their drivers as I understand the legal and some other aspects. At least ATI contributes both source code and specifications to the open source community, and Nvidia contributes largely to the 2D only "nv" driver even though they do not providing hardware specs. Over time perhaps more and more will be released from different vendors. Time will tell I guess. One thing is certain though, and that is that no amount of community begging, petitioning, and other similar requests are going to get hardware companies to violate intellectual property laws just to oil a squeaky wheel. Instead, lets thank them for what they do give us, and politely request things of them that are realistically something they might be willing to, and legally able to provide us in the future, rather than a nonrealistic white card, which they're not likely to be legally able to do. Just my thoughts. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: Jon S. <jon...@ya...> - 2003-02-28 21:21:14
|
--- "Mike A. Harris" <mh...@re...> wrote: > On Fri, 28 Feb 2003, Jon Smirl wrote: > > I don't see 100 unpaid hackers hacking feverishly on > anything X Obviously you wouldn't see 100 people working full time but you might get detailed bug reports or patches from 100 people. I know I get patches from all over the place for code I have written. A couple of months ago I wanted to make a few changes to the ATI Rage128 framebuffer driver. It took me a month to get ATI to give me the register specs. I still can't get the 3D spec and this is for five year old hardware. I fixed a couple of bugs in the framebuffer. I just left the others alone since I can't get them to tell me how to reset the card from protected mode. I just don't understand what is to be gained by keeping the Rage128 hardware programming spec secret. After all a device driver for a board has the best copy protection in the world. But in ATI's defense they are much better than Nvidia. I gave away my NVidia hardware and I won't be buying any more. > While I would love nothing more than to see that, I > highly doubt > that either ATI or Nvidia have the legal rights to > open source > the entire source code of all of their drivers. > Parts of them > perhaps, but I doubt all of them, and even then > parts of them > would be patent encumbered still. We don't know if NVidia or ATI have incorporated 3rd party code into their drviers. There are other solutions. 1) ATI could simply open source their hardware spec and let us write the drivers 2) ATI could shift resources and contribute to the DRI code base instead of working on their own. 3) ATI can license their patents for royalty free use when developing drivers for their hardware. Other uses would require fees, like the new W3C patent position. Again, no knock on ATI. They are doing the best of the bunch. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Mike A. H. <mh...@re...> - 2003-02-28 23:07:00
|
On Fri, 28 Feb 2003, Jon Smirl wrote: >> I don't see 100 unpaid hackers hacking feverishly on >> anything X > >Obviously you wouldn't see 100 people working full >time Obviously. Not even part time. I doubt you'd see more than 20-30 people "working" on it at all. And by that I mean making any significant contributions, not a oneshot bug fix. I mirror what Gareth Hughes said. There aren't hundreds of performance obsessed hackers itching to hack on DRI source code, wether it is the existing open source code, or wether the sources for both ATI, and Nvidia's drivers were released. In fact, I'll go one step further, and say that I believe if ATI and Nvidia *both* released the _entire_ source code to their drivers, and published their complete video hardware specifications on the front page of slashdot, that practically zero work would be done with any of it except perhaps by existing people already members of the DRI project, or hacking on DRI a fair amount on this list already. I bet it would draw next to zero new developers. I also doubt that any performance improvements would be made to those currently closed source drivers any time soon. More likely, the code would be used to improve all video drivers, including the Matrox ones, and other video hardware as well. That would take a LONG time to do too. It would probably take enough time for experienced DRI people alone to even get a hold on the full driver source code base enough to make use of it. >but you might get detailed bug reports or patches from 100 >people. I know I get patches from all over the place for code I >have written. Detailed bug reports? LOL. 95% of all XFree86 related bug reports from people are pure useless garbage. Missing tonnes of information, and quite often you have to dig the information out of the person, and they get increasingly frustrated with you and upset and flame you so you don't even want to look at their problem anymore. Patches? Not many. A few patches come in (specifically related to DRI that is), yes, but they are very few (IMHO) compared to the work the DRI and XFree86 projects do. Quite frankly, the collective code of the kernel interfaces, DRI, Mesa, etc. used in implementing open source 3D is quite complicated in nature, and there aren't 100's of people out there IMHO who grok it enough to be able to make as many contributions as you might think. Having more code out there doesn't mean there are going to be more people hacking on it. >A couple of months ago I wanted to make a few changes to the ATI >Rage128 framebuffer driver. It took me a month to get ATI to >give me the register specs. I still can't get the 3D spec and >this is for five year old hardware. I fixed a couple of bugs in >the framebuffer. I just left the others alone since I can't get >them to tell me how to reset the card from protected mode. You might not have been able to get them, but many of us do have them. While it would be nice if hardware vendors would release specs openly, it is their decision. The fact that they allow ANYONE to have them is FANTASTIC, or we would have little to no open source drivers at all. Be thankful to those companies that do allow some developers to have access to documentation. >I just don't understand what is to be gained by keeping the >Rage128 hardware programming spec secret. After all a device >driver for a board has the best copy protection in the world. That's their business really. I've got the Rage 128 specs, and many other X developers do too. If other people can demonstrate their abilities to work on X or DRI, and show enough initiative to work on the code *without* the specs, they are much more likely to get them. I know several people who hack on the ATI drivers who do NOT have the specs, and they manage to do pretty good without them all things considered. ATI would probably give them the specs based on their track record if they asked. >We don't know if NVidia or ATI have incorporated 3rd >party code into their drviers. I am pretty sure that it has been acknowledged that they have. >There are other solutions. >1) ATI could simply open source their hardware spec >and let us write the drivers To be honest.. ATI provided many developers with Radeon R200 specifications prior to the hardware even being released. I don't know specifically how many people had them or have them now, but I do know that most if not all of the developers who have them, have full time jobs, and do not have time to spend 8 hours a day working on video drivers. The largest development efforts will come from people who can afford to spend hours every day working on them, and that is only most likely going to happen if it is funded development work under contract, such as the work that Tunsten Graphics is doing for The Weather Channel right now. Or the Intel i8x0 driver work that's been done. There is open source work being done by volunteers, and I think it is fantastic too. The Mach64 project, talk of Savage driver, and others on the way for older hardware. I just don't think it is realistic to expect that source code is going to materialize merely because specifications are made available. 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. Don't get me wrong here, I want DRI to succeed, and to be as open source as possible. But I think people need to be realistic about it and get off the fantasy clouds they're living in. My general experience of seeing people ask for specifications for various hardware, more times than not the person does nothing with them, or they fix one bug that bothered them then go away. That's either with specs that are open already, or with specs that they were able to convince a vendor to give to them. It'd be great if specs were all opened, but I don't think that there will be 100's of developers standing in line to hack on code if they were published on tomorrow's slashdot front page. There would be a very small handful. And hopefully they'd put together a successful project around it, but it wouldn't happen very quickly IMHO. Not without funding. >2) ATI could shift resources and contribute to the DRI >code base instead of working on their own. Let me play devils advocate... What would they get out of it? >3) ATI can license their patents for royalty free use >when developing drivers for their hardware. Other uses >would require fees, like the new W3C patent position. I'm not talking about ATI's patents. I'm talking about other company's patents to which ATI may have licensed perhaps to use in their own hardware or software. They may not have legal rights to divulge this information. I fully believe that vendors can benefit the most from having open source drivers and specifications. I do not however believe that if a vendor releases specs or source that it will result in an overnight sensation of a stampede of new developers entering the foray. I also understand the various complex webs of legal issues such vendors may face due to licensing of patents, cross licensing agreements and other legal issues, and I respect their positions even though it would please me greatly more than anything to see all specs and sources opened up. Someone should really turn this topic into an FAQ we can point people to every 3-4 weeks when the topic comes up again. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: Jon S. <jon...@ya...> - 2003-03-01 02:26:35
|
--- "Mike A. Harris" <mh...@re...> wrote: > >> I don't see 100 unpaid hackers hacking feverishly Since you have the specs, tell me how to reset a Rage128 from protected mode so that I can add it to the framebuffer driver. I know about going into real mode and calling C000:3. This can't be done from a device driver. vbios.vm86 does it from the command line and it's a 500K program. My application calls for multiple Rage128 in a single machine. Only the first one gets reset by the BIOS at power on. I need to know what register to poke to reset the card, how to set up it's RAM controller, and whatever else is needed to do a reset. I even tried disassembling the VBIOS to figure this out. The necessary info is part of the source of the VBIOS ROM. Tell me the sequence needed and this unpaid hacker will add a reset function to the Rage128 FB driver for free. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Sven L. <lu...@dp...> - 2003-03-01 09:50:17
|
On Fri, Feb 28, 2003 at 06:26:35PM -0800, Jon Smirl wrote: > --- "Mike A. Harris" <mh...@re...> wrote: > > >> I don't see 100 unpaid hackers hacking feverishly > > Since you have the specs, tell me how to reset a > Rage128 from protected mode so that I can add it to > the framebuffer driver. > > I know about going into real mode and calling C000:3. > This can't be done from a device driver. vbios.vm86 > does it from the command line and it's a 500K program. > My application calls for multiple Rage128 in a single > machine. Only the first one gets reset by the BIOS at > power on. > > I need to know what register to poke to reset the > card, how to set up it's RAM controller, and whatever > else is needed to do a reset. I even tried > disassembling the VBIOS to figure this out. The > necessary info is part of the source of the VBIOS ROM. > > Tell me the sequence needed and this unpaid hacker > will add a reset function to the Rage128 FB driver for free. BTW, does the int10 and such stuff from the X driver not do this for you ? I agree, this would be too late for the fbdev driver, but still, you could add a register write dump to the bios emulator to see what it does write to the registers or something such. That said, things like memory timings and such will be board dependant. Friendly, Sven Luther |
From: Peter \Firefly\ L. <fi...@di...> - 2003-03-01 13:32:30
|
On Sat, 1 Mar 2003, Sven Luther wrote: > > Tell me the sequence needed and this unpaid hacker > > will add a reset function to the Rage128 FB driver for free. > > BTW, does the int10 and such stuff from the X driver not do this for you Only for the first card, I gather. > ? I agree, this would be too late for the fbdev driver, but still, you > could add a register write dump to the bios emulator to see what it does > write to the registers or something such. Of course he could :) I would do something like that I were him. It shouldn't be too hard. A couple of days' work, judging from past reverse engineering tasks I have done. -Peter "Of course, I'm not unbiased, but in my humble opinion, I've gotten close to something that I can be really proud of." -- Knuth on The Art of Computer Programming. |
From: Sven L. <lu...@dp...> - 2003-03-01 13:44:52
|
On Sat, Mar 01, 2003 at 02:31:30PM +0100, Peter Firefly Lund wrote: > On Sat, 1 Mar 2003, Sven Luther wrote: > > > > Tell me the sequence needed and this unpaid hacker > > > will add a reset function to the Rage128 FB driver for free. > > > > BTW, does the int10 and such stuff from the X driver not do this for you > > Only for the first card, I gather. What use is it for then ? Since the first card will be initialized by the BIOS anyway. I thought the whole point of it was to be able to initialize the other cards. > > ? I agree, this would be too late for the fbdev driver, but still, you > > could add a register write dump to the bios emulator to see what it does > > write to the registers or something such. > > Of course he could :) I would do something like that I were him. It > shouldn't be too hard. A couple of days' work, judging from past reverse > engineering tasks I have done. BTW, do you know of a tool for snooping what a windows driver writes to the graphics MMIO registers ? Friendly, Sven Luther |
From: Peter \Firefly\ L. <fi...@di...> - 2003-03-01 14:01:52
|
On Sat, 1 Mar 2003, Sven Luther wrote: > What use is it for then ? Since the first card will be initialized by > the BIOS anyway. I thought the whole point of it was to be able to > initialize the other cards. The only use is to serve as a very obfuscated documentation of the registers on the card ;) > BTW, do you know of a tool for snooping what a windows driver writes to > the graphics MMIO registers ? Not a good and user friendly one. Maybe Numega Soft-ICE can do it? I would use a patched version of Bochs... I would patch it to give it free access to the video I/O ports and the video memory and emulate the rest (so it wouldn't boot out Bochs). ssh into it from another machine. The terminal window on the other machine allows you to access the "front panel" of the simulator + also a debugger for the simulated code, if you add the right patch. You can tail the log from yet another ssh terminal window. -Peter "Of course, I'm not unbiased, but in my humble opinion, I've gotten close to something that I can be really proud of." -- Knuth on The Art of Computer Programming. |
From: Jon S. <jon...@ya...> - 2003-03-01 16:01:18
|
--- "Peter \"Firefly\" Lund" <fi...@di...> wrote: > On Sat, 1 Mar 2003, Sven Luther wrote: > > BTW, does the int10 and such stuff from the X > driver not do this for you > > Only for the first card, I gather. X does it on the cards using VM86 mode. X is a user space app. I want to do it from the framebuffer device driver. VM86 mode is not accessible from a device driver. I have a user space app (500K) that does the reset. Non-86 platforms are forced to use an x86 emulator to reset the card. X Windows has an X86 emulator embedded in it for this purpose. It is just so pointless carrying around and maintaining tens of thousands of lines of code simply to reset video cards. We can add the same reset code to X and get rid of the real mode emulation for the ATI cards too. > Of course he could :) I would do something like > that I were him. It > shouldn't be too hard. A couple of days' work, > judging from past reverse > engineering tasks I have done. There are many variations (50?) of the Rage128 hardware. Desktop, mobile, TV tuner, US, European, TV OUT, DVI, etc. I would need one of each to do the reverse engineering. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Ian M. <sp...@f2...> - 2003-03-01 01:49:11
|
On Fri, 28 Feb 2003 15:56:41 -0500 (EST) "Mike A. Harris" <mh...@re...> wrote: > > I don't see 100 unpaid hackers hacking feverishly on anything X > related right now. Why would 100 unpaid hackers come out of the > woodwork all of a sudden? Quite unrealistic. If you stood a chance in hell of writing a COMPLETE driver, I recon dozens of people would come out of the woodwork. without specs though, it'll never happen. |
From: Daniel V. <vo...@ep...> - 2003-02-28 21:32:48
|
> Does DRI have a future with neither NVIDIA nor ATI participating? > Are people actually talking to them about why they don't use it and > what has to be done to remedy this fact? Shouldn't this be a top priority? To clarify: I meant what has to be done to make DRI (direct rendering *infrastructure*) attractive for IHVs. I didn't mean to imply what has to be done to get NVIDIA or ATI to release open source drivers and whatnot. The open source/ closed source discussion has been beaten to death and is irrelevant to this thread. My point was/is that without NVIDIA or ATI using the DRI infrastructure it is doomed to fail. -- Daniel, Epic Games Inc. |
From: Mike A. H. <mh...@re...> - 2003-02-28 22:27:01
|
On Fri, 28 Feb 2003, Daniel Vogel wrote: >> Does DRI have a future with neither NVIDIA nor ATI participating? >> Are people actually talking to them about why they don't use it and >> what has to be done to remedy this fact? Shouldn't this be a top priority? > >To clarify: I meant what has to be done to make DRI (direct >rendering *infrastructure*) attractive for IHVs. I didn't mean >to imply what has to be done to get NVIDIA or ATI to release >open source drivers and whatnot. > >The open source/ closed source discussion has been beaten to >death and is irrelevant to this thread. > >My point was/is that without NVIDIA or ATI using the DRI >infrastructure it is doomed to fail. Well... for starters.... ATI *is* using the DRI infrastructure. Does that mean that you think DRI is doomed to success now? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: Daniel V. <vo...@ep...> - 2003-02-28 22:33:43
|
> Well... for starters.... ATI *is* using the DRI infrastructure. > Does that mean that you think DRI is doomed to success now? I guess it means that it's at least not fundamentaly flawed ;-) Fragmention still isn't good, which brings me back to my original question whether folks are talking to NVIDIA why they aren't using the DRI framework. -- Daniel, Epic Games Inc. |
From: Arkadi S. <ar...@me...> - 2003-02-28 23:06:22
|
On Fri, Feb 28, 2003 at 05:33:29PM -0500, Daniel Vogel wrote: > Fragmention still isn't good, which brings me back to my original question > whether folks are talking to NVIDIA why they aren't using the DRI framework. Probably because of theirs UDA? I suspect it is easear to support 'more' common source base which is also under total vendor control. There also multiple accelerated heads issue with current DRI.. arkadi. |
From: Keith W. <ke...@tu...> - 2003-03-03 01:45:08
|
Arkadi Shishlov wrote: > On Fri, Feb 28, 2003 at 05:33:29PM -0500, Daniel Vogel wrote: > >>Fragmention still isn't good, which brings me back to my original question >>whether folks are talking to NVIDIA why they aren't using the DRI framework. > > > Probably because of theirs UDA? I suspect it is easear to support 'more' > common source base which is also under total vendor control. > There also multiple accelerated heads issue with current DRI.. The bulk of their driver would slot in under the GL dispatch layer just fine, though I believe they have made some optimizations in the dispatch/driver interface that we haven't got in the open source libGL.so. The big difference is in the interfaces between components, particularly the interface between the clientside 3d driver (the equivalent of eg. radeon_dri.so) and the X server. Mechanisms for communicating cliprects, context switching, client-client and client-server resource sharing are completely different. Keith |
From: Joe O <jo...@cr...> - 2003-02-28 23:11:02
|
NVidia wanted to keep the source code base of the Windows drivers and the Linux drivers as close as possible, including what would be considered kernel mode stuff. They started with windows drivers and adapted that to linux. Part of their porting effort was bulding a kernel level wrapper, which "emulated" the minimum win32 kernel service API's the rest of the kernel module needed. On Fri, 28 Feb 2003, Daniel Vogel wrote: > Fragmention still isn't good, which brings me back to my original question > whether folks are talking to NVIDIA why they aren't using the DRI framework. > > -- Daniel, Epic Games Inc. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Mike A. H. <mh...@re...> - 2003-02-28 23:37:15
|
On Fri, 28 Feb 2003, Daniel Vogel wrote: >Fragmention still isn't good, which brings me back to my >original question whether folks are talking to NVIDIA why they >aren't using the DRI framework. I'm sure if Nvidia wanted to use DRI they would do so. What benefit would there be to Nvidia really of ditching their existing infrastructure which is closed source, and switching both their kernel side and userland side code to closed source code which uses the DRI infrastructure? Their code is also shared between Windows and I believe Macintosh, and DRI is not available on those platforms. I don't see exactly what you mean by fragmentation. 2 vendors using closed source code aren't fragmenting anything except for their own internal interests. The drivers are a black box really, and could be using any kind of interface, be it DRI, or some proprietary solution. It neither helps nor hinders the DRI project really. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: Mike W. <we...@cs...> - 2003-02-28 23:54:07
|
As Mike implied, NV doesn't do the DRI precisely BECAUSE fragmentation isn't good. Their primary interest is a single <<unfragmented>> code base for <<NV drivers>> and not a single unfragmented framework for 3D accelerated XFree86!! Mike Mike A. Harris wrote: > On Fri, 28 Feb 2003, Daniel Vogel wrote: > > >>Fragmention still isn't good, which brings me back to my >>original question whether folks are talking to NVIDIA why they >>aren't using the DRI framework. >> > > I'm sure if Nvidia wanted to use DRI they would do so. What > benefit would there be to Nvidia really of ditching their > existing infrastructure which is closed source, and switching > both their kernel side and userland side code to closed source > code which uses the DRI infrastructure? > > Their code is also shared between Windows and I believe > Macintosh, and DRI is not available on those platforms. > > I don't see exactly what you mean by fragmentation. 2 vendors > using closed source code aren't fragmenting anything except for > their own internal interests. The drivers are a black box > really, and could be using any kind of interface, be it DRI, or > some proprietary solution. It neither helps nor hinders the DRI > project really. > > > |
From: Ian R. <id...@us...> - 2003-03-01 06:29:14
|
Daniel Vogel wrote: > Does DRI have a future with neither NVIDIA nor ATI participating? > Are people actually talking to them about why they don't use it and > what has to be done to remedy this fact? Shouldn't this be a top priority? > > > To clarify: I meant what has to be done to make DRI (direct rendering > *infrastructure*) attractive for IHVs. I didn't mean to imply what has to be > done to get NVIDIA or ATI to release open source drivers and whatnot. The uncanny thing is that this is almost EXACTLY my job description. :) > The open source/ closed source discussion has been beaten to death and is > irrelevant to this thread. > > My point was/is that without NVIDIA or ATI using the DRI infrastructure it > is doomed to fail. Right now both ATI and Kyro are using the infrastructure, but they both has their own internal enhancements. That's why both drivers install their own libGL.so. I'm trying to beef up the GLX support in the open-source libGL.so so that these IHVs no longer need to do this. What we need to do is open a dialogue with the IHVs to find out what they need. The problem is that there isn't really an authoritative body to have such a discussion. Tungsten probably could do it, and IHVs would probably respond to them, but I think Tungsten already has its hands full with projects that pay the rent. :) |
From: Philip B. <ph...@bo...> - 2003-03-01 07:10:31
|
On Fri, Feb 28, 2003 at 10:29:04PM -0800, Ian Romanick wrote: > Daniel Vogel wrote: > > Does DRI have a future with neither NVIDIA nor ATI participating? > > Are people actually talking to them about why they don't use it and > > what has to be done to remedy this fact? Shouldn't this be a top priority? > > > > > > To clarify: I meant what has to be done to make DRI (direct rendering > > *infrastructure*) attractive for IHVs. I didn't mean to imply what has to be > > done to get NVIDIA or ATI to release open source drivers and whatnot. > > The uncanny thing is that this is almost EXACTLY my job description. :) How about writing documentation for the kernel-level API then? It's not very attractive to write to an API that doesnt have any official documentation. |
From: Jon S. <jon...@ya...> - 2003-03-01 16:21:50
|
--- Ian Romanick <id...@us...> wrote: > Daniel Vogel wrote: > > To clarify: I meant what has to be done to make > DRI (direct rendering > > *infrastructure*) attractive for IHVs. I didn't > mean to imply what has to be > > done to get NVIDIA or ATI to release open source > drivers and whatnot. > > The uncanny thing is that this is almost EXACTLY my > job description. :) Would making a version of DRI that can run standalone be interesting? Then X Windows would load on top of the standalone DRI. A few reasons: 1) Provides a much more constrained platform for the IHV to work on. Simpler to build and debug. 2) Would isolate IHV changes from the rest of X 3) Could be used as a game platform 4) Could be used in embedded systems without X 5) Could be used in projects like DirectFB or alternative OS's. 6) Provides a platform for building and alternative windowing system (that's what I am interested in). A standalone DRI might allow all platform specific code to be removed from X in the long run. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Keith W. <ke...@tu...> - 2003-03-01 16:33:04
|
Jon Smirl wrote: > --- Ian Romanick <id...@us...> wrote: > >>Daniel Vogel wrote: >> >>>To clarify: I meant what has to be done to make >> >>DRI (direct rendering >> >>>*infrastructure*) attractive for IHVs. I didn't >> >>mean to imply what has to be >> >>>done to get NVIDIA or ATI to release open source >> >>drivers and whatnot. >> >>The uncanny thing is that this is almost EXACTLY my >>job description. :) > > > Would making a version of DRI that can run standalone > be interesting? Then X Windows would load on top of > the standalone DRI. > > A few reasons: > 1) Provides a much more constrained platform for the > IHV to work on. Simpler to build and debug. > 2) Would isolate IHV changes from the rest of X > 3) Could be used as a game platform > 4) Could be used in embedded systems without X > 5) Could be used in projects like DirectFB or > alternative OS's. > 6) Provides a platform for building and alternative > windowing system (that's what I am interested in). > > A standalone DRI might allow all platform specific > code to be removed from X in the long run. > Interesting you mention it. This is what Brian & I've done in the Mesa embedded branch -- layered the radeon dri driver on top of fbdev. I can also build regular DRI drivers from a minimal tree & sane set of makefiles. Keith > |