I have a dream... a day when I can use my mobility x300 haw it can be works, a day when compiz is usable (with Radeon Open-Source is usable, with fglrx 8.01 no), when I can see all my video without problem and I can see my dvd on TV with tv-out (don't work with Radeon, little bit with fglrx), when I can play x-plane (with Radeon no, with fglrx yes!!!!), when ???
I can't understand why fglrx driver are unusable with compiz, it's a driver problem not an hardware problem, with Radeon it works great, fast, but, sometimes, it crashes, ok is Open-Source driver, fglrx now support AIGLX, but,.. it's slow, very slow.
3D performance of fglrx now is good, I can play games, but with radeon no, why? beacuse AMD release the spec of new hardware but nothing, nothing, nothing for old hardware, but not so old, for example in Italy the majority of people have an R300 or R400, and AMD? the most used and consolidated hardware is the poor supported, no spec, and bad fglrx support than for the new driver, I repeat, I CAN'T UDERSTAND. WHY NO SPEC FOR R300?
Why all the things I need works but something with a driver something with another driver, is ridicoulus.
And, at the end, with fglrx driver I was forced to change disto from fedora to ubuntu, but I hate Ubuntu, isn't clean and stable like fedora, but fglrx works better.
AMD, only a question, WHY?
Is simple, but no answers.
That's all folks
Actually, the 3D documents coming very soon will cover R300, so you may be luck in the near future.
Wow will this cover some workstation ?
Originally Posted by Michael
I can't remember of the list of chipset I guess the firegl v3200 is a rs380.
Yes, the next round of info should also cover the workstation products.
Billybore, the main reason for releasing info on the newer chips first was that there was zero information available for those chips (although the avivo guys did a surprisingly good job reverse engineering 5xx), while there was already an open source driver for the 3xx parts and only the 3d part was really missing info.
We want to get the newer parts to the same level as the 3xx as a first step, then 3d improvements for any of the 3xx through 5xx chips (and maybe 6xx) will generally also improve the other chips in that range as well.
Last edited by bridgman; 02-13-2008 at 06:23 PM.
Is there a time table for the releasing of documents? (in general, like for the upcoming tcore stuff)
There's a sequence but not a precise timetable. The minute something is ready we release it.
Tcore took a lot more work to clean up than we expected, and started to get in the way of working on 3d. Since the SuSE developers already had a pre-release copy of tcore under NDA we figured that pushing ahead on 3d should be the priority and the final cleanup of tcore is happening in parallel.
Does it mean that a basic 3d driver will come up once the documentation wil be released ?
Originally Posted by bridgman
Who whispered fosdem ?
We already know 99% of r300/r400 hw so specs won't fix the driver. The problem you are facing are just the outcome of the old infrastructure on which current r300 driver is built. Even if current driver can be improved to have better performance i don't think you can compete without a proper memory manager. Current spirit is upload texture when you do rendering ie in worst case you can reupload the whole texture set at each frame which kill performance. Not talking about reading from framebuffer like doom3 is doing which also kills performance.
Originally Posted by billybore
Why put all the work into an "outdated" driver infrastructure. I think that it would make more sense to develop a new r(3-5,6?)xx ttm / galium driver. Galium and ttm are not finished yet, but until we see a working r500/r600 driver will also take some time.
Do you want somethings working in next couple of weeks or are you ready to wait few months (not before end of this year) ? I believe the current strategy to fix r300 and add support for newer hw to it is a good one. The new infrastructure: gallium, drm"2", dri2, ... isn't ready for production at all we still having a lot of discussion on the design and once we happy with the design we need to test it with code and even then we will likely wait a bit to see how mature it's before freezing API and pushing things upstream. We don't want to ask distrib or user to build things using branch scattered all around fdo neither we want to support this code as we break it sometimes every hour.
Originally Posted by onestone