wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)
stefandoesinger at gmail.com
Fri May 30 13:02:42 CDT 2014
-----BEGIN PGP SIGNED MESSAGE-----
Am 2014-05-30 19:51, schrieb Andrei Slăvoiu:
> I find it strange that there are 2 completely different code paths
> for determining card capabilities. So I was thinking to share the
> code between d3d_level_from_gl_info and shader_glsl_get_caps.
Yes, the double implementation of those similar functionalities is
unfortunate and fixing this is a good idea. I'd say migrating to
MESA_query_renderer supersedes this work and is the better long-term goal.
> Since such shared code needs to be able to differentiate between
> d3d 9 with SM 2 and d3d 9 with SM 3 I was wondering if it would be
> a good idea to expose SM info to the current callers of
> d3d_level_from_gl_info to pick Radeon 9500 for SM2 or Radeon X1600
> for SM3.
I think just looking at the vertex shader version should work, as I
suggested in an earlier mail. I don't think this needs a DirectX
version at all. Also, don't call shader_glsl_get_caps directly - call
the get_caps method exported by the selected shader backend.
There are two caveats: To separate version 7 from version 6 you'll
need information from the fixed function fragment pipeline. This
shouldn't be hard to do.
The other thing to keep in mind is that by calling the shader backend,
the card may present itself with a different PCI ID when switching
between ARB and GLSL shaders. Arguably this is even the correct thing
to do, as the ARB shader backend supports only Shader Model 2 on most
cards. Reporting a Radeon 9500 instead of Radeon HD 8000 when the user
selects ARB shaders sounds like a good idea in general. It may make
debugging shader backend differences harder though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the wine-devel