--- Comment #7 from Stefan Dösinger <stefandoesinger@...> 2009-06-01 01:42:00 PST ---
> 1) We cannot actually provide fglrx-style strings from within the 3D stack.
Fair enough I guess. If I test for "X1600" or "R5xx" to find some roughly
matching GPU type shouldn't matter too much to me.
> 2) Unlike fglrx (and, I assume, nvidia,) we don't register support for GL
> extensions that we don't do in hardware.
I guess that's ok for the scope of this bug as well. On fglrx we catch the only
partially working texture_np2. It can cause some other troubles though, I'll
file a separate bug report for this.
(In reply to comment #6)
> Why do you need the chip names? The hw capabilities are based on family
> (r3xx,r4xx, r5xx) rather than the marketing names (9500, X1600, etc.).
To report them to the Windows app. Windows reports the marketing names, so
that's what Windows apps expect, and that's what our users expect to see when
their game tells them what card it has found.
But I think in terms of the driver this point is mostly moot, because (1) we
currently do not return a proper string(only PCI ID), the renderer string we
report is "Direct3D HAL", and (2) we map GL info -> PCI ID, and would later map
PCI ID -> String. There are some games that are confused by this "Direct3D HAL"
that is reported.
The bottom line: I guess the chip family will work for me.
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.