June 16, 2023
5:43 p.m.
On Fri Jun 16 17:42:47 2023 +0000, Francisco Casas wrote:
> > Wait, why can't these be in object_usage\[\]?
> They could be, but that would still be additional fields that could
> simply be stored in the new variable with the infrastructure we
> currently have.
> Also, in native these values (however they are stored) are unique for
> the whole variable. For that reason the test I added doesn't compile in
> tpf profiles with compatibility mode (while it is perfectly valid in
> d3dbc profiles):
> ```
> sampler sam[2];
> float4 main() : sv_target
> {
> return tex2D(sam[0], float2(0, 0)) + tex3D(sam[1], float3(0, 0, 0));
> }
> ```
> Adding it in object_usage\[\] also adds the inconvenience of having to
> iterate over all the components to check if the sampler_dim usage is
> consistent for all combined sampler **components**. And also, we would
> have to remember to check object_usage[HLSL_REGSET_SAMPERS] even though
> the deref is in HLSL_REGSET_TEXTURES.
> > That doesn't seem particularly visible in 28af38f7106c?
> All these things are not necessary if we just create a separate variable:
> * The conditional in hlsl_offset_from_deref() (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54a86074e871df#3cf804f245af47d51595ff932bf817c50967eea2_3729_3807)
> * The need to create an additional extern resource in
> sm4_get_extern_resources() both when separated components (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54a86074e871df#b9a696b7e2f161c9052ff1159d7d8cb2907cdeae_3193_3239)
> and (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54a86074e871df#b9a696b7e2f161c9052ff1159d7d8cb2907cdeae_3108_3144)
> * The check when writing the CTAB entry (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54a86074e871df#b9a696b7e2f161c9052ff1159d7d8cb2907cdeae_3193_3239)
> * Conditionally changing the regset so that objects_usage information is
> obtained from the correct objects_usage[regset] (yes, this wouldn't be
> necessary if objects usage is component-wise, but it is just a detail) (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54a86074e871df#b9a696b7e2f161c9052ff1159d7d8cb2907cdeae_3807_3862).
> * Having to create sm4_resource_dimension_from_sampler_dim() since
> sm4_resource_dimension() cannot be used directly now because we don't
> have a texture type we can pass as an argument (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54a86074e871df#b9a696b7e2f161c9052ff1159d7d8cb2907cdeae_3816_3873)
> * Having to bypass sm4_resource_format for the same reason (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54a86074e871df#b9a696b7e2f161c9052ff1159d7d8cb2907cdeae_3823_3880)
> And the problem is not only these things, but also having to keep in
> mind that this exception exists.
> Also come to my mind some inconveniences like having to create a
> separated allocation function just so that the sampler resources get
> allocated first (
> https://gitlab.winehq.org/fcasas/vkd3d/-/commit/607f22ba836c73ab9ab16ccefdb2d994e80b12bf)
> where in the alternative it is just a matter of sorting the new
> variables first.
The gitlab UI doesn't show it very well at first glance but all those links point to a particular line in the commit after you click them.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/209#note_35936