rendering errors due to multiple GPUs

[Anesthesia4]

I have a 4090 as the primary GPU and an Intel A380 as the secondary GPU, when I run the sample he uses the A380 as the rendering GPU and all the text fails to be rendered, I checked the function that selects the GPUs and the result is that the 4090 and the A380 have the same score, and because of the order of traversal it ends up selecting the A380, is it appropriate to add the extra score for the primary GPU?

[takev]

Hi, thank you for trying HikoGUI.

It is actually really hard to figure out what the primary CPU is. In fact HikoGUI asks the OS for the primary GPU (directX generates a priority ordered list), and it still got it wrong, unless there is a bug there. In the future I would like if it would be easy to select which CPU to use.

Could you maybe make a screenshot to see what is happening? And maybe copy and paste the log that appears in your IDE's output? I wonder what is going wrong with the A380.

[Anesthesia4]

Okay, I'll get you screenshots and logs later today.

[Anesthesia4]

log.txt

[Anesthesia4]

As a side note, everything works fine when I force the 4090 to be the rendering GPU.

[takev]

Thank you for the investigation.

The difference between SDF and other graphic pipelines is that SDF uses "dual source blending". Which according to the JSON output of https://vulkan.gpuinfo.org/displayreport.php?id=28543 is available on the A380.

You could try and force that feature off in gfx_device::initialize_device to see if that is indeed the source of the problem.

I guess I did not complete the directx device ordering system. Maybe it is in the abandoned pull request :-(

I also notice some vulkan validation errors, I need to check those as well.

[Anesthesia4]

Thanks for the reply, I tried turning off dual source blending and it now gives a rendering error

log.txt

[takev]

Well.. that looks interesting.

It looks like the internal Y coordinates inside the shader is half what it is supposed to be. But if this is true and it is sampling outside of the SDF texture of the glyph, then I expect it to show a different glyph. But definitly not a grey block, because you can't design a SDF texture that creates a grey block, so something else must be going on.

[takev]

I still don't understand why this goes wrong. But there may be a work around.

HikoGUI should automatically switch to a non-subpixel anti-aliasing at high pixel densities such as retina displays. Because the calculations for subpixel anti-aliasing does get expensive.

For this we actually need a new shader that is in effect simpler and does not need the subpixel-blending setting in Vulkan.

So by adding this feature we improve performance on high DPI displays and at the same time we have a fallback for problematic GPUs.

The y-axis scaling bug could have been caused by making a shader that returns two colors while the pipeline is not setup for such handling subpixel anti aliasing; it worked on some graphics card like nvidia, but it is definitely out of spec what I wrote.

I am not sure how we can attach two shaders to the same pipeline. We may need to duplicate the whole pipeline. On the other hand we do desperately want to share the SDF-texture maps between the two shaders.

[Anesthesia4]

Sorry this is beyond my capabilities, but good luck!

[takev]

I somehow now got the same problem with font rendering where the top of each character is a gray block and the letters are vertically squished.

So hopefully I can find the actually problem.

[takev]

It look like copying from a staging image to a texture image is fragile in vulkan.

And although used in many tutorials is recommended against since it gets confused when the images formats and layouts are not exactly identical and also doesn't work with advanced pixel-formats.

Instead create a staging buffers, which is guaranteed to properly copy a bytes stream into an image, including for advanced pixel formats.

[takev]

Fixed this issue with the SDF pipeline in a branch. It will take a while to be merged into main.