Who can afford a new video card? So, play with shaders on your CPU.

Win32 CPU-shader host for experimenting with image shaders, ray-tracing studies, interactive widgets, text rendering, and scene-reduction POCs.

https://github.com/bitRAKE/C-CPUShader

It isn't meant to be particularly good at anything, but can do many things. Perhaps I'll better align the c-shader language with other shader language(s) - probably not.

There are a number of Proof-of-Concepts (POCs):
- shader logic reused as a standalone tool window
- low-tech fixed-grid SDF text
- more advanced MTSDF text rendering
- Blender-driven scene reconstruction

* this is a tool for programmers - you'll probably need to recompile.

The start of this work was to produce HDR UI through shaders. You might think HDR isn't a big deal but I can see the different now, and so can you if your monitor supports HDR.

The presentation backend was completely re-engineered because HDR support sucks outside of DX. So, although backends exist for DX12, OpenGL, and Vulkan; they all route though DXGI to produce consistent results.

Shader features are expanded: they select the color space and the backend tries to present/capture correctly.

Capture frames to PNG - yes, HDR PNG from shader with alpha.

New sprite capture POC! Yes, write a shader get a sprite.


* Don't trust any performance metrics, yet - kind of on the back-burner.

Not totally true. Fixed the Vulkan backend - it's a complete, valid backend for HDR, but it still uses DXGI to validate the capability.

Switched to NMAKE build with LLVM/Clang dependency tracking (insures edits trigger the correct rebuilds). This is to make the modify-build-test loop faster; but that won't really matter in the future.

Expanded the command line (because this is ultimately a scripting tool). Capturing and parametric shaders can all generate assets from scripts. Shader variables are script only for now, but they allow creative variation.

Also, chased down some nasty threading bug that only happened when headless.

Is HDR just 16bits per color?

scRGB (CCCS), DXGI_FORMAT_R16G16B16A16_FLOAT, Linear
HDR10 (ST.2084), DXGI_FORMAT_R10G10B10A2_UNORM, Non-Linear

... are both considered HDR on the presentation side. HDR10 is weird and requires complex color space conversion, but it's closer to what monitors are actually supporting. I still need to make some more color space tests to ensure round-trip works in the different formats.

1.0f is equal to 80 nits in scRGB. So, although it's linear, monitor range matters in color conversion (if we assume component ranges are [0.0,1.0]).

The obvious question to me is: To what extent can conversion be avoided? Can shaders produce the expected color form?

Then I guess ARGB16161616 is HDR ?

At the application layer.

Well, in my wip wayland compositor, the framebuffer actually scanned out is native ARGB16161616 (no color banding). It seems many apps are currently limited to ARGB8888 (I have to blit/convert on the fly).

No monitor actually displays ARGB16161616, though.

For me the better goal is trying to display in a manner that matches the expressiveness of the monitor. The CPU shaders prefer 4 floats because of SIMD.

Mine is a 10 years old iiyama 1080p monitor, in 16bits color, I do not get color banding (I did visual tests).

Most monitors do some sort of dithering though, usually time-dithering, since they can't render all those colors.

Just there is a problem to run GDI

Then 16bits color encoding is even more appropriate, namely in the worst case scenario it will be done by the monitor hardware.

Could not see any color banding or dithering artifacts with my visual tests with full screen 16bits color gradients, "my noze touching the panel" (10years old panel).

I need to research this deeper to verify my current understanding: some cheap monitors don't have a lot of processing hardware and lean on the video card more for color processing. Where in this "extra" processing can software intercept?