Open
Bug 693168
Opened 13 years ago
Updated 2 years ago
Tracking bug for FGLRX bugs (ATI proprietary Linux driver)
Categories
(Core :: Graphics, defect)
Tracking
()
NEW
People
(Reporter: bjacob, Unassigned)
References
Details
Unfortunately, FGLRX does not provide a driver version number in GL_VERSION string. Currently we use the OpenGL version as only discriminant factor, we require it to be >= 3.0. Unfortunately we have some unsolvable bugs even with recent drivers supporting GL 3.3 so we might have to blacklist it completely. Alternatively one might say that distros don't ship it by default anyways, so we might do as for the Nouveau drivers and just ignore bugs rather than blacklisting.
Reporter | ||
Updated•13 years ago
|
Comment 2•13 years ago
|
||
(In reply to runetmember from comment #1) > Version available in file /etc/ati/amdpcsdb.default Like so: john@joran ~/bin/firefox-nightly/firefox > cat /etc/ati/amdpcsdb.default | grep Version ReleaseVersion=S8.84.6-110324a-116088C-ATI
Reporter | ||
Comment 3•13 years ago
|
||
OK, I see. Since we have to do this during startup, it really, but really sucks to have to fopen() another small file. Even though we do it on a different process in parallel, it's still potentially a seek on the same hard disk drive that we have to load firefox from. So it could easily slow down Firefox startup by twice the seek time (round trip) which could be 25 ms.
Comment 4•13 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #3) > Since we have to do this during startup, it really, but really sucks to have > to fopen() another small file. Even though we do it on a different process > in parallel, it's still potentially a seek on the same hard disk drive that > we have to load firefox from. So it could easily slow down Firefox startup > by twice the seek time (round trip) which could be 25 ms. Could it be something lazily requested the first time a webgl context is requested [and stored until browser restart]?
Reporter | ||
Comment 5•13 years ago
|
||
For now yes, but we want to shortly turn on GL compositing, for which we need to check the blacklist on startup. We could cache this, but only if we have a reasonable way of invalidating the cache when needed. Is the last, fairly long number in the GL_VERSION string unique to a FGLRX version? If yes, it could be used as the key for cache validity.
Comment 6•13 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #5) > For now yes, but we want to shortly turn on GL compositing, for which we > need to check the blacklist on startup. > > We could cache this, but only if we have a reasonable way of invalidating > the cache when needed. > > Is the last, fairly long number in the GL_VERSION string unique to a FGLRX > version? If yes, it could be used as the key for cache validity. There doesn’t appear to be anything that correlates, I’ll have to wait for the next driver update and reply with a confirmation or not. From the above driver version, this is the GL_VERSION OpenGL version string: 3.3.10665 Compatibility Profile Context
In newer catalyst (if you are still interested to this) they added kernel driver version after "profile context". After giving a quick check to opengl.gpuinfo.org and the good reports of geeks3d, I believe somewhere between 4.2.11762 (fglrx 12.8) and 4.2.12002, 9.12.0.0 (fglrx 13.1). Even though one would technically be interested to the userspace opengl component, in my experience kernel build is far more telling of whatever branch (hence major bugs) binary comes.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•