Skip to content

vkd3d-shader/hlsl: Print hlsl_fixme() messages using FIXME() as well.

Elizabeth Figura requested to merge zfigura/vkd3d:pr1 into master

This makes most vkd3d-shader insufficiencies a lot more obvious when used as an embedded library.

The obvious disadvantage here is that vkd3d-compiler will basically print every fixme message twice.

This is a bit of an RFC, since I'm not married to this patch. Other potential approaches I see (not all mutually exclusive):

  • Always print a FIXME if we return VKD3D_ERROR_NOT_IMPLEMENTED from compile_hlsl(), but don't print messages for individual compilation errors. Thus we clue in debuggers that a bug is related to HLSL, but let them use VKD3D_SHADER_DEBUG to find out what the actual bug is. Since the first step is most of the hard part I think this is a reasonable solution.

  • Or do the same thing from d3dcompiler.

  • Relegate hlsl_fixme to a separate vkd3d_shader_log_level, and print messages from that log level in d3dcompiler by default. This isn't quite as simple as that though, since currently all the messages are stored in a single blob.

  • Extra APIs to control whether FIXMES are printed.

I'd also like to propose extending whichever of the above solutions to the hlsl_error() / VKD3D_ERROR_INVALID_SHADER cases. That way we catch things which we aren't going to catch via hlsl_fixme(), such as syntax errors from unrecognized keywords. There's a counterargument that compiling an invalid shader is valid usage, and that we (wine or vkd3d) shouldn't print any ERR/FIXME messages when a program does something valid and implemented, but I'd counter that in practice intentionally compiling an invalid shader should be exceedingly rare, and especially for something like wine or vkd3d where debugging is difficult, it's simply not worth insisting on "a correctly functioning program should print no messages" if it's at the cost of making debugging that much harder.

Merge request reports