Skip to content
Snippets Groups Projects

vkd3d-shader: sm1 texture interface.

Merged Elizabeth Figura requested to merge zfigura/vkd3d:mr1 into master

This defines (and, broadly, implements) the API for mapping sm1 combined samplers to the target environment. This is possibly the simplest bit of API for sm1 support thus far.

It does not actually involve any API changes. Rather, each combined sampler is split into two descriptors, one for the sampler and one for the texture, both with the same binding index as the original combined sampler.

--

I feel rather positive about this bit of API. it required very little design concern or implementation difficulty on the vkd3d side.

On the Wine side, it required quite a lot of change, but I think pretty much all of that change was positive on its own merits, and should probably be applied independently of the sm1/Vulkan work. We've talked about translating wined3d_device_set_sampler_state() and wined3d_device_set_texture() to wined3d_device_set_sampler() and wined3d_device_set_shader_resource_view() for quite some time now, and that was pretty much exactly what was required to make this work—that and choosing the obvious mapping of "same index for both state objects".

The most obvious alternative to this design, to me, would be to reroll struct vkd3d_shader_interface_info (or extend it without rerolling), adding a new array for mapping a combined sampler in the source environment to two separate descriptors in the target environment, i.e. struct vkd3d_shader_resource_binding in reverse. We would probably also want to design a way to map a combined sampler to a combined sampler (a sixth array? Or reuse struct vkd3d_shader_descriptor_binding with a new descriptor type?)

I suppose the advantage of such an alternative design would be that it reports "one" descriptor as "one", not "two", but the associated complexity seems far greater, and accordingly I don't really want to give it the time of day. (Note also that this patch set handles combined -> combined mapping without any extra effort). I will of course yield to maintainer preference, though.

--

As before, I've prepared proof-of-concept code for Wine. The branches are here:

https://gitlab.winehq.org/zfigura/vkd3d/-/commits/himavant5

https://gitlab.winehq.org/zfigura/wine/-/commits/himavant6

The relevant test can be run with:

make tests/shader_runner.exe && WINE_D3D_CONFIG=renderer=vulkan wine tests/shader_runner.exe ../vkd3d/tests/hlsl/tex2D.shader_test

These branches are rather larger than the previous ones. By way of summary, the vkd3d branch contains these patches, plus about two dozen patches to hook up sm1 tests and to fix various corner cases surrounding semantic translation (much of which should be rewritten with a VSIR-based "lowering" approach in mind).

The Wine branch contains:

  • Wine merge request 4027,

  • the patches for sm1 constant buffers,

  • a set of patches to transform individual sampler states into sampler objects (of which [1] is the most interesting), and

  • a set of patches to transform textures into SRVs (of which [2] is the most interesting).

As described above, there is not actually any part of the Wine side that touches the vkd3d-shader interface.

[1] zfigura/wine@984e4787

[2] zfigura/wine@722c1bf1

    What are the roots that clutch, what branches grow
    Out of this stony rubbish? Son of man,
    You cannot say, or guess, for you know only
    A heap of broken images, where the sun beats,
    And the dead tree gives no shelter, the cricket no relief,
    And the dry stone no sound of water.
Edited by Elizabeth Figura

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Elizabeth Figura changed the description

    changed the description

  • This defines (and, broadly, implements) the API for mapping sm1 combined samplers to the target environment. This is possibly the simplest bit of API for sm1 support thus far.

    It does not actually involve any API changes. Rather, each combined sampler is split into two descriptors, one for the sampler and one for the texture, both with the same binding index as the original combined sampler.

    --

    I feel rather positive about this bit of API. it required very little design concern or implementation difficulty on the vkd3d side.

    Right, this is essentially how this was intended to work.

    An argument could perhaps be made that VKD3DSPR_COMBINED_SAMPLER is somewhat superfluous because the distinction between VKD3DSPR_COMBINED_SAMPLER and VKD3DSPR_SAMPLER is implied by the shader model, but I think the added clarity is helpful.

    There's perhaps also an argument that we should describe how d3dbc descriptors are mapped to vkd3d-shader descriptors in the vkd3d_shader_scan_descriptor_info documentation, much like we do for d3dbc shader constants. The instructions for vkd3d_shader_resource_binding and vkd3d_shader_combined_resource_sampler would then logically fall out of that.

    +static enum vkd3d_result normalise_combined_samplers(struct vkd3d_shader_parser *parser)
    +{
     ...
    +                FIXME("Unhandled instruction %#x.\n", ins->handler_idx);
    +                return VKD3D_ERROR_NOT_IMPLEMENTED;

    vkd3d_shader_parser_error(), please. Conveniently, we already have VKD3D_SHADER_ERROR_VSIR_NOT_IMPLEMENTED.

  • Author Developer

    An argument could perhaps be made that VKD3DSPR_COMBINED_SAMPLER is somewhat superfluous because the distinction between VKD3DSPR_COMBINED_SAMPLER and VKD3DSPR_SAMPLER is implied by the shader model, but I think the added clarity is helpful.

    Yes. In general I rather like the idea of not making the API semantics depend on the shader model, at least inasmuch as it affects the output. I suppose in this case it's also redundant because sm1 uses different instructions (TEX et al.) but I still think the clarity is helpful here.

    There's perhaps also an argument that we should describe how d3dbc descriptors are mapped to vkd3d-shader descriptors in the vkd3d_shader_scan_descriptor_info documentation, much like we do for d3dbc shader constants. The instructions for vkd3d_shader_resource_binding and vkd3d_shader_combined_resource_sampler would then logically fall out of that.

    Yeah, I agree, this shouldn't be in two different places. I'll change this in v2.

    vkd3d_shader_parser_error(), please. Conveniently, we already have VKD3D_SHADER_ERROR_VSIR_NOT_IMPLEMENTED.

    Will do. There was precedent elsewhere but that one was my fault too, I'll add a patch to fix it.

  • Elizabeth Figura added 3 commits

    added 3 commits

    • b5f851ce - include: Define an API for mapping sm1 samplers to the target environment.
    • cfc5c763 - vkd3d-shader: Scan combined sampler declarations.
    • 7254cf31 - vkd3d-shader/ir: Translate TEX instructions to SAMPLE.

    Compare with previous version

  • Henri Verbeet approved this merge request

    approved this merge request

  • Alexandre Julliard added 36 commits

    added 36 commits

    • 7254cf31...3af629cf - 32 commits from branch wine:master
    • 2bcd6ea8 - vkd3d-shader: Introduce a separate register type for combined samplers.
    • 7a4ae434 - include: Define an API for mapping sm1 samplers to the target environment.
    • bd9eae6c - vkd3d-shader: Scan combined sampler declarations.
    • 6a942581 - vkd3d-shader/ir: Translate TEX instructions to SAMPLE.

    Compare with previous version

  • Alexandre Julliard approved this merge request

    approved this merge request

Please register or sign in to reply
Loading