Did you ever get a chance to run those tests on your 620-based card?
Replying to myself - I just got the 9-2 drivers installed - had to rebuild my kernel since tlb_flush_page isn't exported on 64bit systems - you have to patch to add it in.
Good news and bad news.
I now get 30+ FPS in lightsmark instead of single digits.
Every test with radiosity makes my entire screen go blank until it completes. I'm rendering to a window, not fullscreen, I thought my machine crashed at first.[/s]
Edit: Fixed. It was too overclocked, forgot I had turned it up to see if that fixed the framerate. Brought it back down some and the blackscreens went away. I figured it out when I noticed some pixel tearing on static images. New FPS ahoy!
Lightsmark 08 1024x768 windowed:
Finished, average fps = 32.62.
For reference, Radeon HD3200 on a gigabyte board, 128 UMB + 128 shared RAM, linux 2.6.28 64bit on AMD, the 9-2 drivers.
Oh and the 'stillnotabenchmark' glxgears gets 1000 FPS now depending on load, so whatever was slowing it down in previous drivers is corrected now.
5043 frames in 5.0 seconds = 1008.588 FPS
5026 frames in 5.0 seconds = 1005.180 FPS
EVE in wine is playable, if a bit slow. Very similar FPS in windows so not a major complaint.
I have asked this question a few times already now but I didn't get a clear answer, yet (though I guess no one really knows). Anyways:
Will we ever be able to enjoy KMS with fglrx? As far as I know, the necessary hooks for KMS are GPL'd, so they can't be used directly, but maybe there are ways to circumvent this?
(Without knowing details) I think it comes down to the framebuffer driver anyways, so would it be possible for fglrx to "just" implement its own framebuffer driver and provide (an own implementation of) the user-space KMS API by itself?
EDIT: For clarification, the framebuffer driver would of course have to be open source just as the current kernel module, but that shouldn't be such a big problem as fglrx doesn't touch any IP sensitive information at modesetting (this was one of the first things which was covered by the coding docs after all). Correct me if I'm wrong at this assumption
I may have read your earlier questions as "will we do it", which I'm not able to answer. Questions about "is it possible ?", on the other hand, I *can* answer
AFAIK the code is either MIT/X11 or dual licensed, so that shouldn't be a problem. I guess it's possible that the kernel devs could band together and declare the API as "GPL only" but I don't think that is likely to happen.
We already have a good memory manager, so the most we would use from GEM is any API subset we needed to expose in order to let another kernel driver make use of a KMS-managed frame buffer. We would also need to expose the appropriate KMS API bits as you say.
I think the goal would be to use the existing framebuffer drivers; we could replace them as an alternative to exposing the GEM/KMS API bits but I don't think we would want to go that route.
The actual modesetting code would probably stay closed-source as it is today, not to protect the register info but to protect some of the proprietary software.
All that said, it's not clear whether implementing KMS in the fglrx driver is the right thing to do, or whether the endgame for professional graphics is more likely to move modesetting out of the X/DRI stack completely into a separate hypervisor. In that case we would probably just make the fglrx driver hypervisor-aware and hook modesetting that way rather than going with the current KMS approach.
For clarity, I still think KMS is absolutely the right direction for the open source drivers, and there's a good chance we will need to provide something similar in fglrx. I'm just not sure whether KMS would be the "next step" for fglrx.
It would be a feature added to one of the compositing window managers, not something specific to the driver or the hardware. I think border transparency is available today but the Vista UI adds a bit of diffusion/blurring as well as transparency which looks pretty sharp.