I really hope that the open source drivers will get better soon. But I have doubts if they could ever run gl2benchmark without glitches. fglrx is in a heavy broken state, especially for Xserver 1.4. Since new codebase gl2benchmark test 3/4 do not run and with Xserver 1.4 and 64 bit it just segfaults... 8.40.4 worked btw... Let's see how long it will take to get really good drivers.
I'm running xorg-server 1.4 + fglrx for slightly over 1,5 months now, without problems. I only had problems with newer xorg-server versions.
Originally Posted by Kano
try this then (compiled for 32+64 bit):
add this to /etc/apt/sources.list (works with sid too, gutsy/hardy not tested):
deb http://kanotix.com/files/fix/gl2benchmark.lenny ./
deb-src http://kanotix.com/files/fix/gl2benchmark.lenny ./
apt-get install --allow-unauthenticated gl2benchmark
If you have problems you can always do:
apt-get build-dep gl2benchmark
apt-get source -b gl2benchmark
to build it for currently unsupported systems.
It needs openscenegraph 2 as build depend. It is not really a benchmark as it is interactive with mouse movement/button press but also a graphic feature test for correct rendering. New fglrx code base totally ignores point sprites for example. Last test only works correctly in fullscreen mode.
That makes me wonder why there is no (almost complete in functions) open source driver for RS690 uptill now? Parts are more or less ready and what's left is to combine them, so what's stoping the devs ? I mean it could have been done along the reverse engineering of r4xx chips.
Originally Posted by bridgman
and BTW radeonhd is for r5xx r6xx cards if RS690 is so much closer to r4xx then it does make sence to put it into radeon (r2xx r3xx r4xx) driver instead. I'm a bit confused about why it's in the radeonhd dirver now.
Last edited by val-gaav; 01-05-2008 at 09:08 AM.
well, to put it in simple ways:
Originally Posted by val-gaav
- radeonhd is totally developed from the source with the addition of some working code from radeon parts.
- radeon code has been written in its majority from reverse engineering the old fglrx code.
the thing that board are similar doesn't imply that they're the same and john pointed out some differences. the main problem is that radeonhd is developed entirely on the new r600 series and works with some older r500 that are similar to the r600. the radeonhd could work also on other chips but the devs don't know about it since they never tried testing it on r300 or 400 for example. but for the moment it's likely that it won't work on these boards without harm.
the radeon branch instead is working for boards till r500 and is adding various support for newer features and boards. it's known that with time we'll have just one driver but for now the 2 codes from the 2 drivers are different and until the radeonhd doesn't finishes its code for the new boards i don't think that it will converge into the radeon, while the radeon branch will continue to increase its features, stability and speed for the older cards also through utilities from radeonhd and specs from amd and one day it will absorb radeonhd, but i don't see this happening this year.
What about MPEG2 acceleration? Some of us don't give a damn about gaming or 3D effects, but faster video decoding would be nice...
Last edited by highlandsun; 01-06-2008 at 05:25 AM.
What do you mean looks incomplete and hacky? I assume you are basing this on your years of experience writing XAA/EXA drivers? or just on the fact that you can't understand the codepaths?
Originally Posted by TechMage89
XAA is functionally complete in that it provides accel for anything it can.
EXA is still a work in progress and the missing bit is Composite support which actually requires using the 3D engine not the 2D engine. We only support Composite on r100/r200 so far and I'd like to add r300 support at some point. R500 needs some info on the fragment shader pipeline to happen.
XAA also has some support for composite operations but we might not bother implementing that (maybe someone will, they mainly make gnome-terminal go faster).
Really EXA isn't a great final solution as-is, we require a unified memory manager like TTM to really make it shine. Otherwise we end up with the current texture/pixmap VRAM split etc...
Originally Posted by val-gaav
rs690 modesetting is the same as the r500 parts, so it needs atombios or radeonhd support to set modes. the 3D engine is like the 3D engine on rs480, but there is also a large chunk of work just programming the memory controller on these chips. Setting up the memory controller is tricky (maybe atombios will make it easier).
Once the memory controller is working, the current Mesa r300 driver should work on top of it all fine, however the current Mesa r300 driver doesn't fully support "vertex shader"-less cards, googleearth and many games work, compiz however has resisted fixing, I'd hope to remedy this situation since I wrote the current "vertex shader"-less codepaths, but time as ever is the enemy.