~~This one's marked as a draft, as there seems to be a blocker with the method parameters.~~
~~The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it:~~
```
vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed.
```
~~Seems like it's surprised when we try to load from the constant buffer maybe?~~ Fixed!
--
v7: tests: Add a basic compilation test for SampleGrad() method.
vkd3d-shader/hlsl: Add support for SampleGrad() method
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184
> This is what I originally thought, but I'm having slight second thoughts now. The thing is that the tradeoff is now you need a new IR for every bytecode language you have, which in our case means at least sm1, sm4, and eventually I think sm6. That's a lot of extra support code to add. Consider how much we'd need to add by putting that intermediate step into HLSL -> smX translation. The advantage of making v_s_i the IR is that you don't actually need any of that.
You mean that you'd have just `v_s_i` and every frontend and backend deals directly with it, including for very syntactical things like assembling and disassembling? I don't feel really convinced, it seems to me that you'd have to encode su much stuff in `v_s_i` that each time you need to change something (for example to allow for a new language) the changes can have repercussions in each other language frontend or backend.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31723
This patch makes index expressions on resources hlsl_ir_index nodes
instead of hlsl_ir_resource_load nodes, because it is not known if they
will be used later as the lhs of an hlsl_ir_resource_store.
For now, the only benefit is consistency.
--
v2: vkd3d-shader/hlsl: Don't keep the implicit mipmap level on hlsl_ir_index.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/182
From what I can tell, the recent work on SampleBias/SampleLevel did all of the work for us, we just need to take the same framework and include the case for the `sample_l` instruction.
Tested with some shaders from the native Linux version of Little Racers STREET.
--
v6: vkd3d-shader/tpf: For sample_l/sample_b, set lod swizzle to SCALAR.
vkd3d-shader/tpf: Add support for emitting sample_l instructions
tests: Add a test for SampleLevel() function.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/188
It indicates a misuse of the API and is undefined behavior according to Glib / GStreamer semantics. Glib tells about it nicely and returns a sensible value, but it should be fixed on the caller side.
> The g_return family of macros (g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), g_return_val_if_reached()) should only be used for programming errors, a typical use case is checking for invalid parameters at the beginning of a public function. They should not be used if you just mean “if (error) return”, they should only be used if you mean “if (bug in program) return”. The program behavior is generally considered undefined after one of these checks fails. They are not intended for normal control flow, only to give a perhaps-helpful warning before giving up.
>
> https://docs.gtk.org/glib/logging.html
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2546#note_31696