Open Bug 693168 Opened 13 years ago Updated 4 months ago

Tracking bug for FGLRX bugs (ATI proprietary Linux driver)

Categories

(Core :: Graphics, defect)

All
Linux
defect

Tracking

()

People

(Reporter: bjacob, Unassigned)

References

Details

Attachments

(1 obsolete file)

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.
Blocks: 605780
Depends on: 680644
Depends on: 698040
Depends on: 724640
Version available in file /etc/ati/amdpcsdb.default
(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
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.
(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]?
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.
(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
Depends on: 798157
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.
Severity: normal → S3
Attachment #9386140 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: