First, sorry for maybe somewhat newbish questions/approach... but anyway. Do i understand correctly that wined3d implementation takes d3d shaders'
bytecode and converts it to other
format depending on hardware?
Correct. Currently we support GL_ARB_*_program and GLSL, but the backends are modularized so its possible to add other stuff as well(considerations are GL_NV_*_program, Nvidia's Cg shader, GL_ATI_fragment_shader and GL_NV_texture_shader, or whatever may come up in the future)
I'm asking because I've recently came across a MojoShader
(http://icculus.org/mojoshader/) project which is
a library (zlib licensed) to convert compiled Direct3D shaders from
bytecode to some other format (several
profiles). The library seems to work well - it is used for OpenGL renderer
in Unreal Tournament 3 engine.
So i wonder - can there be some benefit to wine from such a project?
I don't think it would be any use for wine.
The part that MojoShader does - streight conversion from D3D bytecode into some GL shader - is pretty well understood. The things that make problems(or used to make, in the meantime its handled pretty well in wine) are implicit dependencies on d3d settings outside the shader, e.g. bound textures or the "fixed function" bump map matrices etc. As far as I can see is that this is completely unimplemented in mojoshader:
2936 // !!! FIXME: do non-RGBA textures map to same default values as
D3D?
2940 // ps_1_0 and ps_1_4 are both different, too! 2941 fail(ctx, "TEXLD <= Shader Model 2.0 unimplemented."); //
!!! FIXME
2942 return;
3017 EMIT_GLSL_OPCODE_UNIMPLEMENTED_FUNC(TEXBEM) // !!! FIXME 3018 EMIT_GLSL_OPCODE_UNIMPLEMENTED_FUNC(TEXBEML) // !!! FIXME
MojoShader is useful as an abstraction layer if you're writing your own application, like UT3 does, but it is not suitable to handle unmodified D3D shaders which were never intended to run with opengl.