reduce a lot of glcalls and cache various states

[gulafaran]

reading nvidia docs they say this.

All relevant GL state should be initialized during application initialization and not in the main render loop. For instance, 
occasionally glClearDepthf, glColorMask, or glViewport finds its way into the application render loop even though the 
values passed to these functions are always constant. Other times they are set unconditionally in the loop, just in case 
their values have changed per frame. Only call these functions when the values actually do need to change.

gluniform calls are also cached per program, and unless the value has changed it does not need to be called yet again.

this reduced gl* calls in apitrace by a large amount. moving a lot of driver churn to small cpu churn. but needs some testing from others that this doesnt make it now use a lot more cpu then needed. locally it doesnt.

the perfect way would be to really spend weeks into the code and appropiatly only call these uniforms/viewports/scissor when actually needed. but the easy way out is wrapping and caching the values.

i also havent tried HDR, since i dont have a HDR monitor. needs to be tested so it didnt break.

[gulafaran]

@UjinT34 i need hdr testing! :heart:

[UjinT34]

Might be tricky to test because these changes don't prevent HDR activation and some incorrect/outdated shader values might not be obvious. I guess it's time to choose/create some tool to use as a reference for CM testing. SImageDescription supports faster == comparison when id is set. CHyprOpenGLImpl::passCMUniforms uses it for color conversion matrix caching. Can be used in a similar way to return early and avoid all the new setUniform stuff and checks.

[vaxerski]

I think this is ready no?

[gulafaran]

I think this is ready no?

sure ready for review and testing.

[Zebra2711]

I rebased this on the main. Without HDR enabled, HDR displays

monitorv2 {
    output = eDP-1
    mode = 1920x1080@144
    position = 0x0
    scale = 1
    # bitdepth = 10
    cm = srgb
    sdrbrightness = 2.20
    sdrsaturation = 1.07
    supports_wide_color = 1
    supports_hdr = 0
    sdr_min_luminance = 0.005
    sdr_max_luminance = 200
    min_luminance = 0
    max_luminance = 1000
    max_avg_luminance = 200
}

monitorv2 {
    output = eDP-1
    mode = 1920x1080@144
    position = 0x0
    scale = 1
    # bitdepth = 10
    cm = srgb
    sdrbrightness = 2.20
    sdrsaturation = 1.07
    supports_wide_color = 1
    supports_hdr = 0
    sdr_min_luminance = 0.005
    sdr_max_luminance = 200
    # min_luminance = 0
    # max_luminance = 1000
    # max_avg_luminance = 200
}

Black screen with:

monitorv2 {
    output = eDP-1
    mode = 1920x1080@144
    position = 0x0
    scale = 1
    # bitdepth = 10
    cm = srgb
    sdrbrightness = 2.20
    sdrsaturation = 1.07
    supports_wide_color = 1
    supports_hdr = 0
    sdr_min_luminance = 0.005
    sdr_max_luminance = 200
    # min_luminance = 0
    # max_luminance = 1000
    max_avg_luminance = 200
}

I just want to test this. Not sure if my config is wrong or not, but hope this helps

[UjinT34]

CM shader values aren't passed correctly. With cm = srgb the CM is skipped in most cases. Anything that triggers CM will result in a red tint. cm = edid should be enough for testing (might need to force wide color gamut and use cm = wide if EDID primaries are not set or equal to sRGB).

[UjinT34]

@Zebra2711 should work now

[Zebra2711]

@Zebra2711 should work now

Yep, no more red tint when cm=edid (or wide,...) is set

[Skidamek]

https://github.com/user-attachments/assets/8e52bd37-28c2-4e65-bdfb-5b92ba5189fb

systeminfo.txt

there's something messed up, with animations/borders? best visible on bright wallpaper on special workspace this is with this patch applied on top of cf7e3aa (main), without it, i don't see these artifacts

[gulafaran]

2025-06-23.15-09-48.mp4

systeminfo.txt

there's something messed up, with animations/borders? best visible on bright wallpaper on special workspace this is with this patch applied on top of cf7e3aa (main), without it, i don't see these artifacts

that looks bad indeed, but whats up with all your env vars in your config. LIBGL_ALWAYS_SOFTWARE, __NV_PRIME_RENDER_OFFLOAD , __VK_LAYER_NV_optimus etc

[gulafaran]

2025-06-23.15-09-48.mp4 systeminfo.txt there's something messed up, with animations/borders? best visible on bright wallpaper on special workspace this is with this patch applied on top of cf7e3aa (main), without it, i don't see these artifacts

that looks bad indeed, but whats up with all your env vars in your config. LIBGL_ALWAYS_SOFTWARE, __NV_PRIME_RENDER_OFFLOAD , __VK_LAYER_NV_optimus etc

there is like 3 different places you set decoration blur/shadow too xD

[Skidamek]

that looks bad indeed, but whats up with all your env vars in your config. LIBGL_ALWAYS_SOFTWARE, __NV_PRIME_RENDER_OFFLOAD , __VK_LAYER_NV_optimus etc

idk, i had them long time lol - they dont seem to affect that

there is like 3 different places you set decoration blur/shadow too xD

true, i need to clean it up sometime, axshell replaces them tho, i just checked that its reproducible with just axshell

[Zebra2711]

true, i need to clean it up sometime, axshell replaces them tho, i just checked that its reproducible with just axshell

That's because some functions changed and axshell used old functions like GL.glTexParameteri https://github.com/Axenide/Ax-Shell/blob/2ac60548ea449041ba4819ef26197161484486a4/modules/shader.py#L324

[gulafaran]

true, i need to clean it up sometime, axshell replaces them tho, i just checked that its reproducible with just axshell

That's because some functions changed and axshell used old functions like GL.glTexParameteri https://github.com/Axenide/Ax-Shell/blob/2ac60548ea449041ba4819ef26197161484486a4/modules/shader.py#L324

technically i dont think that should break, it merely will call it uncached

[UjinT34]

true, i need to clean it up sometime, axshell replaces them tho, i just checked that its reproducible with just axshell

That's because some functions changed and axshell used old functions like GL.glTexParameteri https://github.com/Axenide/Ax-Shell/blob/2ac60548ea449041ba4819ef26197161484486a4/modules/shader.py#L324

technically i dont think that should break, it merely will call it uncached

Uncached calls won't update the cache and later cached calls might get skipped instead of updating values and cache.

[vaxerski]

isn't that a separate process though? I'd assume it's not hyprland as it's written in python.

[gulafaran]

true, i need to clean it up sometime, axshell replaces them tho, i just checked that its reproducible with just axshell

That's because some functions changed and axshell used old functions like GL.glTexParameteri https://github.com/Axenide/Ax-Shell/blob/2ac60548ea449041ba4819ef26197161484486a4/modules/shader.py#L324

technically i dont think that should break, it merely will call it uncached

Uncached calls won't update the cache and later cached calls might get skipped instead of updating values and cache.

oOh yes -_-. we set whatever to 2. module sets it to 0, later we try to set it to 2 again, only now its cached as 2 but the module changed it, mismatch and 0xb00b

[vaxerski]

oOh yes -_-. we set whatever to 2. module sets it to 0, later we try to set it to 2 again, only now its cached as 2 but the module changed it, mismatch and 0xb00b

if that python code is a plugin (runs as part of hl) then it's the plugin's job to update itself as hyprland changes. If it's just a client process, it has nothing to do with us.

[gulafaran]

@Skidamek and @Zebra2711 reverted a change that broke contrast/blur and stuff. so it should be a lot happier now.

and as always, big thanks for testing things so they dont end up merged and causing havoc on -git :heart:

[Skidamek]

Seems to work perfectly fine now, thanks

[gulafaran]

@vaxerski yeah think we ruled out the issues, its good to go from here on, from my end.