When'll AMD Opensource Drivers be feature-complete for Evergreen chips
I'm wondering when'll AMD Opensource Drivers be feature-complete for Evergreen chips. Around 10-13 features are in todo/working state for last 3 years. Looking at http://www.x.org/wiki/RadeonFeature feels like the entire develpment has been halted for some years. Is it the usual pace? Or is that page not updated?
That's not the only place to look for progress. Evergreen chips use the r600g driver, which has been steadily progressing and is now almost OpenGL 3.3 compliant. Just this week they gained OpenGL 3.1 compliance.
Over the last month or two Mr. Glisse's Hyper-Z patches have resurfaced, and in a better state than they previously were, so they should be closer to being merged, which will be another box ticked. Mr. Stellard is continuing to make progress on the OpenCL backend.
Just because that page marks something as WIP for a long time that doesn't mean it has stagnated or that progress isn't being made - some of the tasks listed are huge.
Thank you all.
Well, here's the current status:
todo items: Video Decode (XvMC/VDPAU/VA-API) on UVD, Stippled Primitives, Smooth Primitives, Tessellation Shader Stages, Geometry Shaders, Crossfire.
wip items: Video Decode (XvMC/VDPAU/VA-API) on the 3D engine, Hyper-Z, Compute (OpenCL).
mostly items: Hybrid Graphics
Among the above items, would anybody please tell me which ones are not important for everyday tasks - media playback, games and usual work stuff. And what progress have been made?
One or the other of the Video Decode features may be "nice to have" or "must have" for media playback depending on the codec used (some codecs are not supported by UVD anyways), resolution of the video (lower res videos are easier to play without decode acceleration), and whether your machine has enough CPU/GPU power to play it acceptably without decode acceleration.
Hybrid Graphics support is important if you bought a laptop that uses hybrid graphics (typically an IGP and GPU together), not used otherwise.
HyperZ is interesting because once all the quirks are figured out it has the potential to add maybe 10% improvement in 3D gaming performance, which is definitely nice.
The rest are probably not important to most people for everyday use.
Note that even if a GL level or GL feature is not needed today it probably will be needed for some game at some point in the future so worth working on today anyways.
In case it helps, the most requested additions seem to be (a) improved power management (current PM implementation depends on having fairly complete power tables in the VBIOS and increasingly that is not the case), (b) video decode acceleration for HTPC-type applications, (c) improved OpenCL support.
Last edited by bridgman; 01-14-2013 at 03:26 AM.
Thanks Bridgman for such nice explanation. One last question though, how long will it take to be feature-complete and mature those 3 (that you've mentioned) areas?
Thanks for the update John!
Can you (one of the devs) explain a bit more about the VBIOS tables?
Can that be compared to something like the ACPI tables (eg. DSDT) or is it just the several states like "video watching" (GPU on xxx MHz, VRAM on xxx MHz) and "gaming" (with GPU on yyy MHz etc.)? Why do these tables lack information?
I personally always used Sapphire cards which afaik are close to AMD's reference design and they normally work nicely - also in terms of power consumption. Actually I have with profile=low (free driver stack) same or even 1-2 W better overall (power plug wall measured) wattage like I have in Windows XP with Catalyst. It's like 83 W (Linux free) idle vs. 85 W idle (W32). (Didn't try fglrx/Linux for a long time )
So I personally am really fine with power side of the free stack (just sad that dynpm does not use low profile!). But I see complaints from others sometimes.
So do some vendors provide clean implementation of VBIOS tables (like some mainbaord people provide good DSDTs) and some do not? How many quirks are allowed for a vendor that sells a Radeon GPU somewhere in a solution?
edit: And yes please for any kind of video accel (your E-350 Mini-ITX style boards would be perfect HTPCs then!) (low power, passively cooled and so on)
I thought HyperZ was finished?!
Originally Posted by manmath
The rest of the features comes to OpenGL4.2, Video decode either via UVD or OpenCL, more efficient power management and Crossfire.
In recent four years driver went from OpenGL1 to 3.1. Thats a lot of progress thats shareable between all drivers! Then the open drivers already support GL ES and have solved the S3TC patent problem (kudos to S2TC devs!) and the Khronos committee seems to appreciate the driver because in newer OpenGL the better compression method is patent-free from ground up.
So I project, to answer your question the full support of every single feature will land in 5-6 years, without crossfire in 4 years, its faster if you help by donating, reporting and debugging, but its usable already.
And then perhaps it'll take another decade to catch up with the features of the devices of that time... Life's too short....
Originally Posted by crazycheese
Anyways, thanks all!
When you're sitting at a computer all day, you get used to seeing progress bars. Maybe instead of WIP, we can add those circular loading animations that never end.
Originally Posted by bridgman