693168 - Tracking bug for FGLRX bugs (ATI proprietary Linux driver)

Status: NEW

(Core :: Graphics, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 1

[russianneuromancer]

Version available in file /etc/ati/amdpcsdb.default

Comment 2

[John Drinkwater (:beta)]

(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

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

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

[John Drinkwater (:beta)]

(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]?

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

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

[John Drinkwater (:beta)]

(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

Comment 7

[mirh]

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.

Comment 8

[Candy Steele]

Attachment: same problem

Thanks from cenmudsrare1981.