WineD3D: Sample from the correct source when using older pixel shaders

Stefan Dösinger stefan at codeweavers.com
Sun Aug 27 06:05:25 CDT 2006


Am Sonntag 27 August 2006 04:29 schrieb Ivan Gyurdiev:
> Stefan Dösinger wrote:
> > Pre 2.0 pixel shaders do not contain a tag for the texture type to sample
> > from. Wine had 2D textures hardcoded, this patch checks the bound texture
> > type to decide from which texture to sample from. For >= 2.0 shaders the
> > shader tag is still used.
>
> Why can't this be done in a much cleaner way where the sampler is
> initialized (2nd pass, baseshader, get_registers_used)? Then you don't
> have to copy and paste the same thing in many places - there's 10
> texture instructions or something like that for pixel shaders alone.
Well, I'm pretty new to the shader code, seems like I didn't find the right 
place for this :-)

If I understand you correctly I should check the texture type from the 
stateblock around line 300 in baseshader.c:

* Declare 1.X samplers implicitly, based on the destination reg. number */
if (D3DSHADER_VERSION_MAJOR(This->baseShader.hex_version) == 1 && 
    (D3DSIO_TEX == curOpcode->opcode ||
     D3DSIO_TEXBEM == curOpcode->opcode ||
     D3DSIO_TEXM3x2TEX == curOpcode->opcode ||
     D3DSIO_TEXM3x3TEX == curOpcode->opcode)) {

        /* Fake sampler usage, only set reserved bit and ttype */
        DWORD sampler_code = *pToken & D3DSP_REGNUM_MASK;
        reg_maps->samplers[sampler_code] = (0x1 << 31) | WINED3DSTT_2D; <---
}

> Also, maybe the stateblock should be passed as an argument to all
> functions that use its states. I don't like walking up the tree to find
> what you need (this->wineD3Ddevice) - it's a hidden dependency on device
> state, which isn't even all the time - that's why you had to move the
> point where the shader is compiled [ this needs better documentation ].
Do you mean adding a pointer to the stateblock in baseShader or copying the 
entire stateblock? I do not really see any advantage in that, except avoiding 
the This->wineD3DDevice->stateBlock(would be This->stateBlock instead). I 
think that is confusing, we should have only one place to access the 
stateblock(and only one copy of the primary state block)

> Similarly, I think the code would be cleaner if projected sampling vs
> regular was retrieved from the stateblock, and stored somewhere else, at
> the point when the sampler is initialized.
Do you mean an extra stateblock member for every sampler which stores if 
projected sampling is used? I do not see any advantage in that, we'd create 
another redundant copy of the data.
a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060827/e41762f1/attachment.pgp


More information about the wine-devel mailing list