d3d10

[Stefan Dösinger]

Am 29.10.2009 um 21:29 schrieb Luis C. Busquets Pérez:

> Dear all,
>
> Since d3d10effect has advanced a lot during the latest weeks I was  
> wondering what are the next steps that you are planning to develop.
I'm still working on d3d9-related stuff only, no guarantees that the  
following is correct

> 1. Do DepthStencil and RasterizerState present major differences in  
> terms of capabilities compared to D3D9? I mean that coding  
> ID3D10EffectDepthStencilVariable is very easy once you have  
> ID3D10DepthStencilState (just call  
> ID3D10Device_CreateDepthStencilState for  
> ID3D10EffectDepthStencilVariable::GetDepthStencilState and  
> ID3D10EffectDepthStencilVariable::GetBackingStore  should only be  
> recovering the data from a private variable).
I see no additional features in D3D10_DEPTH_STENCIL_DESC. A  
ID3D10Device::OMSetDepthStencilState could just call the proper  
IWined3DDevice::SetRenderState calls, or a depthstencilstate could  
contain a wined3d stateblock with the proper pre-recorded states.

> Furthermore,  ID3D10Device::OMSetDepthStencilState is just a bunch  
> of IWineD3DDevice_SetRenderState calls because I think that wined3d  
> already implements all the required functionality, doesn't it?.
> ID3D10Device::OMGetDepthStencilState would be a bunch of  
> IWineD3DDevice_GetRenderState.
> ID3D10EffectRasterizerVariable. presents the analogous thing  
> (together with ID3D10Device::RSSetState), doesn't it?
For OMSetDepthStencilState, your idea seems correct, as outloned  
above. For GetDepthStencilState you'd probably cache the correct  
interface pointer in d3d10core, since an app may create more than one  
ID3D10DepthStencilState states and expect the one it set when it calls  
the getter.

> 2. For ID3D10EffectBlendVariable I think that that is different.  
> what are the major difficulties concerning the capabilities that  
> D3D10 offers compared to D3D9 conerning blending and do you see them  
> achievable beofre this year ends?
You'd probably use a ID3D10BlendState for D3D10EffectBlendVariable.  
D3D10_BLEND_DESC adds a few new features compared to d3d9.  
AlphaToCoverageEnable doesn't exist per se, but there's a MAKEFOURCC 
('A','T','O','C') hack ATI and nvidia added(sorta a d3d9 "extension").  
ATOC is supported by opengl multisampling afaik. So the proper way is  
probably to add a proper state to wined3d, and implement the atoc hack  
in d3d9(using the newly added wined3d state), and also use this state  
from d3d10.

The separate blend enable isn't supported by wined3d yet, but you can  
just add new render states and implement them via  
GL_EXT_draw_buffers2. Should be pretty easy, unless EnableIndexedEXT /  
DisableIndexedEXT complain if you enable/disable blend on a color  
target that's not defined in the current FBO, which would tie blending  
to the render target setting.

> 3. Last, for ID3D10Device::RSGetViewports/ 
> ID3D10Device::RSSetViewports and ID3D10Device::RSGetScissorRects/ 
> ID3D10Device::RSSetScissorRects, the difficulty may lay in accepting  
> in the wine driver more thatn one rect/viewport. Do you agree? Are  
> you planning an upgrade in wined3d to refer to *rect rather than  
> rect in the stateblock definition? The analogous question applies to  
> viewports.
Adding different viewports to wined3d and passing them to the  
according GL function isn't too difficult - make the viewport and  
scissor rect states arrays in wined3d, and modify the Getters,  
Setters, stateblock apply/capture and state applying code accordingly.

What may be more difficult is finding the right GL functions. This is  
not related to the functionality added by GL_EXT_draw_buffers2. From  
the MSDN docs, it seems to be related to geometry shaders, but on a  
quick search I couldn't find any hints in GL_EXT_geometry_shader4 and  
GL_EXT_gpu_shader4.