Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

Andrei Slăvoiu andrei.slavoiu at gmail.com
Wed May 28 14:48:38 CDT 2014


În ziua de Mar 27 Mai 2014, la 21:13:44, Stefan Dösinger a scris:
> Am 2014-05-27 17:35, schrieb Stefan Dösinger:
> > Am 2014-05-27 16:56, schrieb Andrei Slavoiu:> Yes,
> > 
> >> GL_ARB_shader_texture_lod is exposed by mesa for all drivers in
> >> both core and compatibility contexts. So should I check for
> >> GL_ARB_shader_texture_lod instead of glsl version?
> > 
> > No, I'd say use something like if (EXT_gpu_shader4 || (
> > ARB_shader_texture_lod && glsl_version >= 1.30).
> 
> An even nicer solution would be to use the capabilities reported by
> the shader backend. See select_shader_backend() and and
> shader_backend->shader_get_caps. Unsupported vertex shaders would
> match a dx 7 card, VS 1.x dx 8, VS 2/3 dx9 and 4 dx10. For separating
> dx6 and and 7 the fixed function fragment pipeline info is needed
> (number of supported texture units).
> 
> Note that we currently do not support pixel shaders on dx8 cards, and
> probably never will. That's because those cards use separate GL
> extensions (ATI_fragment_shader and GL_NV_register_combiners +
> GL_NV_texture_shader). Thus it's better to look only at vertex shaders
> for now to prevent dx8 cards from being reported as dx7.

Actually, d3d_level_from_gl_info is misleading (broken even), as it will check 
for SM3 capability and then return that the card is capable of directx 10 
(which requires SM4). I'll look into a better way to report the capabilities 
to the callers (maybe use d3d feature levels?) and also for a way to share the 
code that identifies the capabilities with shader_glsl_get_caps.

But that in a future patch, after the second version of this one gets 
submitted.



More information about the wine-devel mailing list