If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Is anyone actually working on that medium term fix, or is it on the roadmap to eventually be done in a few years? I ask because it's already been 1 year, and it doesn't seem like it would take that long to accelerate a single operation. Unless you mean you are switching the whole driver to use EXA? That could take a year. Otherwise, it seems like you are prioritizing this bug very, very low, and I don't think that you can seriously argue that fglrx is ready for "normal" desktop use if that's the case. Maybe AMD isn't even saying that, and they're saying that if you can get lucky and get it working then great, but don't expect any more than that.
Yes, we've been working on it for a while. I'm told that accelerating that function within the existing framework wasn't a good option.
I'm sure they do, these are smart guys and they know the quality of the product they're putting out.
Honestly, if AMD just put out a roadmap stating when they thought all the various problems with fglrx might be solved, that would be a good start. Right now it's like Flash - there are so many problems and no indication about whether AMD even intends to fix them, let alone whether it's under progress now or scheduled for 5 years later.
All I want is a roadmap stating when they'll switch into dropping fglrx and supporting the Open Source stack full steam. It is pretty solid in my Kubuntu Lucid test partition, but obviously a lot of speed ups and functionality need to still be coded in!
Not unless we decide to abandon the workstation market, which seems very unlikely.
If you don't mind educating me a bit: what's different for workstations? NDA's at the hardware level or the customers need somehow for binary only support?
Ultimately, I am a desktop user, and I am wondering if, long term, Open Source drivers will give the same level of performance as the binary ones (but with more stability). My hunch is that there is no reason why this should not be the case, but I am not a graphics guru at all.
Thanks for the answer! And for the good work, I am sticking to ATI for my graphics needs because it's open.
Workstation users are generally quite 3D-intensive, and require (rather than desire) the same level of performance and functionality as Windows. This is where proprietary drivers shine, by allowing the implementation of APIs (OpenGL in this case) which are common across proprietary and free OSes to be shared without IP concerns.
I'm not aware of anyone who "needs" binary-only support, just that they need a level of functionality and performance which (for economic reasons) can not be separately implemented for each OS and which (for IP reasons, mostly related to DRM) can not practically be provided in open source form.
Obviously the OpenGL portion of the stack does not have much in the way of DRM-related IP, however the OpenGL portion of the stack relies heavily on lower level code which is shared between 2D, 3D and video on other OSes.
There is no reason in principle why open source drivers could not match or exceed the performance of proprietary drivers, it's just a question of manpower - which in turn is a function of market share and perceived business opportunity.