From: Brian P. <bri...@ya...> - 2001-09-14 15:36:51
|
Dieter Nützel wrote: > > Anybody (Brian, Keith?) working on the Mesa-3.5-tree? > I've didn't see any activity for some days/weeks, now. Here's the deal. The DRI developers, including myself, have been laid-off from VA Linux. Today (Friday) is my last day. There's an effort to relocate us to a new organization but it's too early to say what'll happen on that front. In the mean time, some of us will try to do some DRI work in our spare time. Progress might be slow though. Volunteers are all the more welcome now. > It would be very nice to see the Mesa-4.0/OpenGL 1.3 stuff comming, soon. Keith and I are working on finishing up the Mesa 4.0 / OpenGL 1.3 work. I hope to release 4.0 in the next few weeks. At some point after that I'd like to return to the DRI's mesa-3-5 branch to import Mesa 4.0 and finish that up. Again, progress may be slow. I plan to take some time off before starting a new job (to be determined) so I might not be following the mailing lists too closely. -Brian __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ |
From: Alex D. <ag...@ya...> - 2001-09-14 21:24:30
|
I'd be willing to donate to support DRI development. I'd even be willing to donate a substantial amount assuming it would guarantee some results. Maybe a project like this would catch the eye of the HW vendors and prompt them to put more effort into opensource drivers. Alex --------- Dear Brian/Keith etc. I'm sure that everybody has their say on this but would you think of a company set up so that people donated money in exchange of binary drivers (source was free of course) for DRI, more like ordered donation than business really. I for one would be keen to donate $20 per 6 months, and thats irrespective of actually getting the binaries (I can compile them myself anyway). I think the point is that do you think people are willing to pay hard cash to support DRI? Andy __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ |
From: Dieter <Die...@ha...> - 2001-09-15 05:17:25
|
Brian Paul wrote: > > Here's the deal. The DRI developers, including myself, have been laid-off > from VA Linux. Today (Friday) is my last day. That's sad. But how the world goes. Daryll, what are you doing, next? > There's an effort to relocate us to a new organization but it's too early > to say what'll happen on that front. > > In the mean time, some of us will try to do some DRI work in our spare > time. Progress might be slow though. Volunteers are all the more welcome > now. Some little hope ;-) Good luck to all of you and as always may the source be with you. Greetings, Dieter |
From: Daryll S. <da...@da...> - 2001-09-15 17:11:02
|
On Sat, Sep 15, 2001 at 07:08:31AM +0200, Dieter N=FCtzel wrote: > That's sad. But how the world goes. >=20 > Daryll, what are you doing, next? Playing golf, riding motorcycles, and generally taking time off. I'm waiting to see what happens with the relocation, and I'm looking at other opportunities. I've got some time. > Some little hope ;-) >=20 > Good luck to all of you and as always may the source be with you. Thanks. I'm sure it's appreciated. - |Daryll |
From: Andrew J. R. <and...@uc...> - 2001-09-14 16:50:32
|
Dear Brian/Keith etc. I'm sure that everybody has their say on this but would you think of a company set up so that people donated money in exchange of binary drivers (source was free of course) for DRI, more like ordered donation than business really. I for one would be keen to donate $20 per 6 months, and thats irrespective of actually getting the binaries (I can compile them myself anyway). I think the point is that do you think people are willing to pay hard cash to support DRI? Andy -- \\\|/// \\ - - // ( @ @ ) +---------------o00o----(_)----o00o-------------------------------------+ |Andy Richardson Dept. of Chemistry | |t(w): +44 171 380 (7465) University college London | |t(h): +44 181 352 (0848) Gordon street | |e: an...@pr... London WC1E 6BT UK | +------------------------------0ooo-------------------------------------+ ooo0 ( ) ( ) ) / \ ( (_/ \_) |
From: Gareth H. <gar...@ac...> - 2001-09-14 19:26:43
|
Andrew James Richardson wrote: > > I'm sure that everybody has their say on this but would you think of a > company set up so that people donated money in exchange of binary drivers > (source was free of course) for DRI, more like ordered donation than > business really. I for one would be keen to donate $20 per 6 months, and > thats irrespective of actually getting the binaries (I can compile them > myself anyway). I think the point is that do you think people are willing > to pay hard cash to support DRI? I think people need to take a step back and have a think about how much money it costs to support top-class developers like those work/have worked on the DRI. We're talking hundreds of thousands of dollars a year. Unless the IHVs (or other companies) want to support it, I seriously doubt the open-source 3D graphics world will progress much further. Is the G400/r128 class of hardware relevant anymore? That's the last generation to see anything approaching full support by open-source drivers. -- Gareth |
From: Mark A. <ma...@em...> - 2001-09-14 20:25:12
|
Gareth Hughes wrote: > I think people need to take a step back and have a think about how much > money it costs to support top-class developers like those work/have worked > on the DRI. We're talking hundreds of thousands of dollars a year. Unless > the IHVs (or other companies) want to support it, I seriously doubt the > open-source 3D graphics world will progress much further. Is the G400/r128 > class of hardware relevant anymore? That's the last generation to see > anything approaching full support by open-source drivers. So do we give up on open source drivers completely? I'm willing to bet that there is some way to generate sufficient revenue to fund the DRI. I don't know what it is, but it would be worth throwing some ideas around rather than throwing our hands up and saying "oh, well." It would be extremely unfortunate if we have to rely upon in-house developers writing binary-only drivers for Linux. With a company like NVIDIA, it really isn't that big of a deal, as they have excellent drivers under both Windows and Linux. But ATI and Matrox both have poor Windows drivers. I have to assume that any Linux drivers from these companies would be even worse. Is open source absolutely essential? Personally, I would rather have binary-only drivers written by the likes of Brian, Gareth, Keith, et. al. than binary-only drivers written by some faceless unknown. Would an open/closed hybrid be feasible? A bare-bones, rasterization only base implementation could be completely open source, included in distributions, etc. A fully-featured driver w/ interesting extensions, T&L, etc. would be a binary-only, licensed product. Something similar to the way OSS works. I know nothing about Xi Graphic's revenue streams, but they seem to be making enough money to stay in business and develop drivers. What other options are there? Is there a way to make this work? It's worth a bit of brainstorming and thought about whether some model can be put in place to support 3D driver development. 3D is becoming increasingly important for general PC use. In the past, the domain of 3D has been primarily for DCC and games. In the future (and not that far in the future), 3D will be pervasive throughout the GUI. Without good 3D support, Linux is dead. -Mark ------------------------------------------------------------ Mark B. Allan NASA Ames Research Center QSS Group, Inc. Neuro-Engineering Lab 650 - 604 - 0537 (office) Mail Stop 269-2 650 - 604 - 0461 (lab) Moffett Field, CA 94035 650 - 604 - 3594 (fax) ma...@em... http://ic.arc.nasa.gov/ic/ne.html ------------------------------------------------------------ |
From: Gareth H. <gar...@ac...> - 2001-09-14 21:13:03
|
Mark Allan wrote: > > So do we give up on open source drivers completely? I'm willing to bet > that there is some way to generate sufficient revenue to fund the DRI. I > don't know what it is, but it would be worth throwing some ideas around > rather than throwing our hands up and saying "oh, well." Good luck. Let us know if you come up with anything. > It would be extremely unfortunate if we have to rely upon in-house > developers writing binary-only drivers for Linux. With a company like > NVIDIA, it really isn't that big of a deal, as they have excellent > drivers under both Windows and Linux. But ATI and Matrox both have poor > Windows drivers. I have to assume that any Linux drivers from these > companies would be even worse. This is a fair point. > Is open source absolutely essential? Personally, I would rather have > binary-only drivers written by the likes of Brian, Gareth, Keith, et. > al. than binary-only drivers written by some faceless unknown. Since I now work for NVIDIA, you can put their closed-source driver in this basket (not to say the GL group here isn't totally amazing already). > 3D is becoming increasingly important for general PC use. In the past, > the domain of 3D has been primarily for DCC and games. In the future > (and not that far in the future), 3D will be pervasive throughout the > GUI. Without good 3D support, Linux is dead. Some are saying that Linux on the desktop is already dead... -- Gareth |
From: Benjamin H. <be...@ke...> - 2001-09-14 21:33:36
|
> >> It would be extremely unfortunate if we have to rely upon in-house >> developers writing binary-only drivers for Linux. With a company like >> NVIDIA, it really isn't that big of a deal, as they have excellent >> drivers under both Windows and Linux. But ATI and Matrox both have poor >> Windows drivers. I have to assume that any Linux drivers from these >> companies would be even worse. > >This is a fair point. Another point is that binary drivers like NVIDIA are x86 only, which is a problem for me (PPC) as Apple now bundles their cards with recent Mac G4s. Also, despite beeing pretty complete, the r128 driver is experiencing all sorts of lockups (depending on the chip rev. and using AGP or not) on PPC. I don't know if x86 has the same issue, but since there doesn't seem to be anybody working on it anymore with good knowledge of the r128 engine (and it's possible bugs)... >> Is open source absolutely essential? Personally, I would rather have >> binary-only drivers written by the likes of Brian, Gareth, Keith, et. >> al. than binary-only drivers written by some faceless unknown. > >Since I now work for NVIDIA, you can put their closed-source driver in this >basket (not to say the GL group here isn't totally amazing already). Heh, you may be able to help me then :) Ben. |
From: Gareth H. <gar...@ac...> - 2001-09-14 22:28:09
|
Benjamin Herrenschmidt wrote: > > Another point is that binary drivers like NVIDIA are x86 only, which is > a problem for me (PPC) as Apple now bundles their cards with recent > Mac G4s. > > Also, despite beeing pretty complete, the r128 driver is experiencing > all sorts of lockups (depending on the chip rev. and using AGP or not) > on PPC. I don't know if x86 has the same issue, but since there doesn't > seem to be anybody working on it anymore with good knowledge of the > r128 engine (and it's possible bugs)... Indeed, this is a problem... Mind you, in the days of the GeForce3 (and it successors) and Radeon 8500 (or whatever they're calling the R200), who wants to be stuck maintaining a driver for the r128? Not me... -- Gareth |
From: Benjamin H. <be...@ke...> - 2001-09-14 22:44:51
|
>Indeed, this is a problem... Mind you, in the days of the GeForce3 (and it >successors) and Radeon 8500 (or whatever they're calling the R200), who >wants to be stuck maintaining a driver for the r128? Not me... Yeah, I can understand... well, if you have clues about things I could look at, I'd be glad to hear about them ;) Regards, Ben. |
From: Will N. <wi...@mi...> - 2001-09-15 00:36:11
|
On Friday 14 Sep 2001 11:22 pm, you wrote: > Indeed, this is a problem... Mind you, in the days of the GeForce3 (and it > successors) and Radeon 8500 (or whatever they're calling the R200), who > wants to be stuck maintaining a driver for the r128? Not me... It's like any other open source project, you can find mainatiners who are interested. Distributions, Debian, Red Hat, would all help fixing bugs in the drivers they ship. That is no big deal IMO. The problem is none of these organisations can build a group of qualified people and find them enough work to justify employing them while the graphics card market consists of 3 cards, 2 of which are closed and the other is "not sure". |
From: Jeffrey W. B. <jw...@ac...> - 2001-09-15 00:04:26
|
On Fri, 14 Sep 2001, Gareth Hughes wrote: > Since I now work for NVIDIA, you can put their closed-source driver in this > basket (not to say the GL group here isn't totally amazing already). I think you should point this out when you claim that ATI and Matrox's products are obsolete. > > 3D is becoming increasingly important for general PC use. In the past, > > the domain of 3D has been primarily for DCC and games. In the future > > (and not that far in the future), 3D will be pervasive throughout the > > GUI. Without good 3D support, Linux is dead. > > Some are saying that Linux on the desktop is already dead... Some people say the moon landing was faked. The only way to kill Linux on the desktop is to get rid of everyone who uses it. -jwb |
From: Gareth H. <gar...@ac...> - 2001-09-15 00:36:35
|
Jeffrey W. Baker wrote: > > I think you should point this out when you claim that ATI and Matrox's > products are obsolete. I've been saying that for a *long* time -- perhaps you missed it, or perhaps the conversations took place elsewhere. Either way, my opinion hasn't changed since joining NVIDIA. It may have something to do with why I chose to join NVIDIA, however... > Some people say the moon landing was faked. The only way to kill Linux on > the desktop is to get rid of everyone who uses it. I agree, however, it depends on your definition of "dead" and what your goals for Linux on the desktop are. A niche market of technically-literate users is a very different thing to widespread acceptance in the corporate and home arenas. -- Gareth |
From: Benjamin H. <be...@ke...> - 2001-09-15 00:53:40
|
>I agree, however, it depends on your definition of "dead" and what your >goals for Linux on the desktop are. A niche market of technically-literate >users is a very different thing to widespread acceptance in the corporate >and home arenas. One important point here is the embedded market. The x86 is definitely not the only CPU used here and Linux is becoming a really important player here. I've been faced to the problem of finding a video chip to use in an embedded box (non-x86), and there is no simple solution today if you need some quality & speed. for kiosk stations. (except doing it all in windoze on an industrial x86 board). Ben. |
From: Frank E. <fe...@ai...> - 2001-09-15 00:46:04
|
On Friday 14 September 2001 17:06, Gareth Hughes wrote: > Some are saying that Linux on the desktop is already dead... Really? Somehow, I find that hard to believe with places like Largo, FL using it on the desktop- I'm of the belief that it's still in its infancy. Oh, congrats on scoring your new employment- I'd hoped you'd get on with someplace worthwhile. -- Frank Earl |
From: Gareth H. <gar...@ac...> - 2001-09-15 01:07:30
|
Frank Earl wrote: > > > Some are saying that Linux on the desktop is already dead... > > Really? Somehow, I find that hard to believe with places like Largo, FL > using it on the desktop- I'm of the belief that it's still in its infancy. Again, I don't actually agree with the statement. However, just take a look at the difference between corporate backing of the Linux server market to the Linux desktop market... We have a long way to go. You'd be kidding yourself if you thought otherwise. > Oh, congrats on scoring your new employment- I'd hoped you'd get on with > someplace worthwhile. Thanks! -- Gareth |
From: Frank E. <fe...@ai...> - 2001-09-15 01:43:32
|
On Friday 14 September 2001 21:08, you wrote: > That's fine -- I wasn't suggesting that. But, for the people who can > actually do this job, the r128/G400 isn't terribly interesting anymore. > Isn't the whole open source thing about developers scratching an itch? Cool. It just came across differently, somehow... Dunno, guess it's due to the incidents of the week combined with nothing still on making the RagePRO go under DRI (I think I'm closer- there's some stuff that's being incorrectly set in the ati XFree86 driver, I've un-done that and now the bus-master seems to hang the box solid instead of do nothing at all... There's still something missing that's messing things up- I just can't finger it yet.). > Talk with Keith and Brian, I'm sure they'd agree with me. We are graphics > programmers for a reason, and keeping up to date with the latest research > and rendering techniques is important as a result. I'd rather be making a > difference to the state-of-the-art than tweaking a driver I wrote 18 months > ago. But that's just me... To be honest, I'd love to be in your position- but the number of jobs for that sort of thing are limited and I couldn't relocate anyhow. So, I guess, for now at least, I'll settle for working on the old junk- someone's got to do it, right? :-> Again, I'm thrilled that you got the job at NVidia. -- Frank Earl |
From: Manuel T. <man...@so...> - 2001-09-15 11:10:20
|
El S=E1b 15 Sep 2001 02:41, escribiste: > On Friday 14 September 2001 21:08, you wrote: > > That's fine -- I wasn't suggesting that. But, for the people who ca= n > > actually do this job, the r128/G400 isn't terribly interesting anymo= re. > > Isn't the whole open source thing about developers scratching an itc= h? > > Cool. It just came across differently, somehow... Dunno, guess it's = due > to the incidents of the week combined with nothing still on making the > RagePRO go under DRI (I think I'm closer- there's some stuff that's be= ing > incorrectly set in the ati XFree86 driver, I've un-done that and now t= he > bus-master seems to hang the box solid instead of do nothing at all...= > There's still something missing that's messing things up- I just can't > finger it yet.). Frank, one more time, I would like to have your work to take a look on i= t. Perhaps with more eyes looking at the problem we could find something. A= nd if you could release your changes we could test it in another machines and = see different behaviours. I think that another good idea is to discuss about what have you find wr= ong in the ati driver, don't you think so? And talking about this thread itself, I think that the DRI development w= ill be always behind the Windows drivers development. So, people buying state-of-art cards will never have a linux environment ready for their shining cards. A lot of things must change to make it possible. Perhaps = Linux is not ready for games and will never be. But I think that Linux have no= t reached it's position for being the first supporting new hardware, but f= or showing a better stability and performance that MICROS~1 OS. This is the= hope, in my opinion. The unstable drivers, hanging the machine, are the = worst thing for Linux. If I bought a Rage128, and saw that the machine hang= ed every two hours, I would say: 'this is just the same shit than Windows',= and I will have no reason to use linux. So, the only hope for the hardware enterprises to release linux drivers is people demanding it. |
From: Frank E. <fe...@ai...> - 2001-09-15 17:04:28
|
On Saturday 15 September 2001 07:08, you wrote: > Frank, one more time, I would like to have your work to take a look on it. > Perhaps with more eyes looking at the problem we could find something. And > if you could release your changes we could test it in another machines and > see different behaviours. > I think that another good idea is to discuss about what have you find wrong > in the ati driver, don't you think so? Sorry, haven't had much time to package things up (I barely had time to do what little I tried this week to get the hang, with all the insanity going on)- I'll try tomorrow or monday to get it all back out. And, yes, I do think so and I was about to do the same... Digging through the code for the X driver, I find strange things that do not match up with what the documentation ATI has handed us (and the draw test code I have proves the documentation at least partly correct...). I find it setting bits that have no documentation for them (grey bars in the bit field descriptions mean that they're un-used/reserved). I find it setting bits that are documented, but have completely different meanings than what the code's comments indicate. I find it keeping the engine's entire state when all it needs do is query it directly (Which is a potential for other problems- what if those duplicated state variables are out of sync for any reason?). In short, it almost looks like the driver is a mess. Right now I'm trying to sift through it and the old 3.3.6 server code to see what I can do to straighten this out in the short term and what I'd need to do to make it more robust in the long term. We're not likely to get bus-mastering going with it in the state it's in. By the way, gang, Gareth's old code has hacks in it to allow you to run accelerated 3D within Mesa so long as the DRI driver isn't loaded- gets about 115-120 fps in gears on my PII 450 with the code I have in hand from Manuel (His first pass at this...). I do agree with his sentiment that it has no business being in the trunk, but I do believe with the new re-worked, repackaged stuff, we have the makings of a new branch for the CVS tree. > And talking about this thread itself, I think that the DRI development will > be always behind the Windows drivers development. So, people buying > state-of-art cards will never have a linux environment ready for their > shining cards. A lot of things must change to make it possible. Perhaps > Linux is not ready for games and will never be. But I think that Linux have > not reached it's position for being the first supporting new hardware, but > for showing a better stability and performance that MICROS~1 OS. This is > the hope, in my opinion. The unstable drivers, hanging the machine, are the > worst thing for Linux. If I bought a Rage128, and saw that the machine > hanged every two hours, I would say: 'this is just the same shit than > Windows', and I will have no reason to use linux. So, the only hope for the > hardware enterprises to release linux drivers is people demanding it. Indeed. But the only way to get people demanding it and the companies thinking it is worthwhile is for us to do the DRI work (or something else like it...) so that they know there is a demand. The Linux buying public doesn't do the brick and mortars- so the stores don't know what the demand is, or worse, don't think there's a potential market. The Linux buying public won't be buying cards without drivers for their card, open or closed source- so they don't know that there is a potential demand for their cards. It's a chicken and egg type problem we face here. As for the Rage 128, I've got several of them (incl. one on a PPC machine...) once we get a little further along, I think I'll be chasing that one at least for a little bit. -- Frank Earl |
From: Jeffrey W. B. <jw...@ac...> - 2001-09-15 18:26:08
|
On Sat, 15 Sep 2001, Frank Earl wrote: > On Saturday 15 September 2001 07:08, you wrote: > > > Frank, one more time, I would like to have your work to take a look on it. > > Perhaps with more eyes looking at the problem we could find something. And > > if you could release your changes we could test it in another machines and > > see different behaviours. > > I think that another good idea is to discuss about what have you find wrong > > in the ati driver, don't you think so? > > Sorry, haven't had much time to package things up (I barely had time to do > what little I tried this week to get the hang, with all the insanity going > on)- I'll try tomorrow or monday to get it all back out. > > And, yes, I do think so and I was about to do the same... > > Digging through the code for the X driver, I find strange things that do not > match up with what the documentation ATI has handed us (and the draw test > code I have proves the documentation at least partly correct...). I find it > setting bits that have no documentation for them (grey bars in the bit field > descriptions mean that they're un-used/reserved). I find it setting bits > that are documented, but have completely different meanings than what the > code's comments indicate. I find it keeping the engine's entire state when > all it needs do is query it directly (Which is a potential for other > problems- what if those duplicated state variables are out of sync for any > reason?). In short, it almost looks like the driver is a mess. Right now > I'm trying to sift through it and the old 3.3.6 server code to see what I can > do to straighten this out in the short term and what I'd need to do to make > it more robust in the long term. We're not likely to get bus-mastering going > with it in the state it's in. Frank, sounds like you have the r128 documentation, ja? Is that something the rest of us can get our hands on, or do we need to drink the goat's blood at the temple of XFree86 first? I'm most interested in working on the r128 and the rage mobility setup code, and xvideo. I'm least interested in working on the mesa code for r128. I only have access to rage mobility on a ppc currently. It seems like there are a lot of efforts out there to get r128 100% working. Someone is hacking on DMA transfers for the hardware video scaler, some other folks are trying to make the video scaler behave, you are working on the chip setup code, and some other folks are trying to figure out the setup routines for the seconds head on the rage mobility. Maybe we need a whole mailing list for r128. -jwb |
From: Manuel T. <man...@so...> - 2001-09-16 14:24:08
|
El S=E1b 15 Sep 2001 18:02, escribiste: > Sorry, haven't had much time to package things up (I barely had time t= o do > what little I tried this week to get the hang, with all the insanity g= oing > on)- I'll try tomorrow or monday to get it all back out. > OK, I know you are busy. I'm expecting your changes to learn about them. > And, yes, I do think so and I was about to do the same... > > Digging through the code for the X driver, I find strange things that = do > not match up with what the documentation ATI has handed us (and the dr= aw > test code I have proves the documentation at least partly correct...).= I > find it setting bits that have no documentation for them (grey bars in= the > bit field descriptions mean that they're un-used/reserved). I find it > setting bits that are documented, but have completely different meanin= gs > than what the code's comments indicate. Could you put me an example. I have not an exact idea of how the initialization process is fired by the 2D driver. Perhaps you're talking= about the mach64preinit.c? It would be nice if you could post me a list of the different suspicious= register writes to contrast them with the docs I have. >I find it keeping the engine's > entire state when all it needs do is query it directly (Which is a > potential for other problems- what if those duplicated state variables= are > out of sync for any reason?). In short, it almost looks like the driv= er is > a mess. Right now I'm trying to sift through it and the old 3.3.6 ser= ver > code to see what I can do to straighten this out in the short term and= what > I'd need to do to make it more robust in the long term. We're not lik= ely > to get bus-mastering going with it in the state it's in. Perhaps the DRI Mach64 driver depends a lot on the 2D driver initializat= ion. On the other hand, the 2D driver is really difficult to follow because i= t's made for a lot of different ATI Cards (actually for all the models from = the VGAWONDER and Mach8 accelerators to the Mach64). BTW. Could anybody say me what is the AVOID_CPIO define used for ? > > By the way, gang, Gareth's old code has hacks in it to allow you to ru= n > accelerated 3D within Mesa so long as the DRI driver isn't loaded- get= s > about 115-120 fps in gears on my PII 450 with the code I have in hand = from > Manuel (His first pass at this...). I do agree with his sentiment tha= t it > has no business being in the trunk, but I do believe with the new > re-worked, repackaged stuff, we have the makings of a new branch for t= he > CVS tree. Do you think we need to startup from another code base? I made the Garet= h's code migration to the XFree4.1.0 CVS trunk, but somebody said before tha= t there's a newer trunk for the DRI. My opinion is that we need urgently to have a common codebase for all th= e people interested to work in the Mach64 driver. So, if you think we must= merge with the DRI newest trunk please make me know. > Indeed. But the only way to get people demanding it and the companies > thinking it is worthwhile is for us to do the DRI work (or something e= lse > like it...) so that they know there is a demand. The Linux buying pub= lic > doesn't do the brick and mortars- so the stores don't know what the de= mand > is, or worse, don't think there's a potential market. The Linux buyin= g > public won't be buying cards without drivers for their card, open or c= losed > source- so they don't know that there is a potential demand for their > cards. Well, I'm just a newbie here. I don't consider myself a graphic programm= er, and posibly I'll never be. I'm a programmer in the 'real world' but in a= very higher level approach. My only aim is to learn and to see my laptop 3D working. So, I don't mind working in an obsolete hardware support. Anywa= y I understand that high level developers here like to work with the newest designs. Best regards. -- M. Teira |
From: Leif D. <lde...@re...> - 2001-09-16 16:04:01
|
On Sun, 16 Sep 2001, Manuel Teira wrote: > BTW. Could anybody say me what is the AVOID_CPIO define used for ? Looking at xc/programs/Xserver/hw/xfree86/drivers/ati/Imakefile, this is defined by default only for Sparc and PPC. Here's the comment: /* * The following configuration logic is only meant as a first cut, and is * therefore incomplete. ...And, no, you do NOT have permission to move this * into xfree86.cf... * * Currently, ATIAvoidCPIO >MUST< be #define'd as YES for those platforms * (architecture/OS combinations) that neither provide nor emulate a * little-endian undirected PIO address space of at least 64 kB in size. * * "Undirected" means the driver does not need to determine the identity nor * location of the responding adapter before accessing a particular location in * the PIO address space. * * #define'ing ATIAvoidCPIO to YES generates a driver that will only support * PCI/AGP Mach64 adapters using a linear aperture and the accelerator CRTC. * The resulting driver will also require the same of the environment on server * entry. * * For testing purposes, #define'ing ATIAvoidCPIO as YES is also supported on * platforms that do, in fact, provide or emulate a PIO address space as * described above, but this should not be the default driver configuration. * * Currently, ATIAvoidNonPCI needs to be set to YES for those platforms that * "drop down" to firmware on accesses to allocated, but disabled, PCI space. * ATIAvoidNonPCI necessarily implies ATIAvoidCPIO. */ > > By the way, gang, Gareth's old code has hacks in it to allow you to run > > accelerated 3D within Mesa so long as the DRI driver isn't loaded- gets > > about 115-120 fps in gears on my PII 450 with the code I have in hand from > > Manuel (His first pass at this...). I do agree with his sentiment that it > > has no business being in the trunk, but I do believe with the new > > re-worked, repackaged stuff, we have the makings of a new branch for the > > CVS tree. > > Do you think we need to startup from another code base? I made the Gareth's > code migration to the XFree4.1.0 CVS trunk, but somebody said before that > there's a newer trunk for the DRI. > My opinion is that we need urgently to have a common codebase for all the > people interested to work in the Mach64 driver. So, if you think we must > merge with the DRI newest trunk please make me know. I agree that we need a common codebase, but my understanding is that we need a working patch before we can start a new branch in CVS. I guess the question is whether it makes more sense to get a patch working based on the 4.1.0 release first and then merge in changes from the trunk or to do the merge now. Of course the trunk is a moving target, but there may be changes in the 2D driver that would be helpful. Frank? --Leif Delgass |
From: Manuel T. <man...@so...> - 2001-09-16 18:19:58
|
El Dom 16 Sep 2001 18:00, Leif Delgass escribi=F3: > On Sun, 16 Sep 2001, Manuel Teira wrote: > > BTW. Could anybody say me what is the AVOID_CPIO define used for ? > > Looking at xc/programs/Xserver/hw/xfree86/drivers/ati/Imakefile, this = is > defined by default only for Sparc and PPC. Here's the comment: Thank you, Leif. > > > Do you think we need to startup from another code base? I made the > > Gareth's code migration to the XFree4.1.0 CVS trunk, but somebody sa= id > > before that there's a newer trunk for the DRI. > > My opinion is that we need urgently to have a common codebase for al= l the > > people interested to work in the Mach64 driver. So, if you think we = must > > merge with the DRI newest trunk please make me know. > > I agree that we need a common codebase, but my understanding is that w= e > need a working patch before we can start a new branch in CVS. I guess= the > question is whether it makes more sense to get a patch working based o= n > the 4.1.0 release first and then merge in changes from the trunk or to= do > the merge now. Of course the trunk is a moving target, but there may = be > changes in the 2D driver that would be helpful. Frank? Anyway, It would be nice to have a common code now, at least to have the= same scenery while hunting the DMA bug. Perhaps little differences in the cod= e used could drive us to very different results, because I think that we a= re really near (of having a working DMA, I mean). I agree with you about the fact of the better the newer trunk we use, but I think that the 2D driver implications we could suffer won't change= if we use a different DRI trunk (I suppose that the 2D base differences bet= ween the 4.1.0 trunk and the newest DRI trunk doesn't matter ). -- M. Teira |
From: Will N. <wi...@mi...> - 2001-09-16 02:07:11
|
On Sunday 16 Sep 2001 1:59 am, you wrote: > I think you are missing my point -- having to maintain a driver for a card > that's four or five generations old as a full-time job just plain sucks 4 or 5? Please elaborate. |