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 |