ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
dri-logger has quit [Ping timeout: 480 seconds]
dri-logger has joined #lima
Daanct12 has joined #lima
mripard has joined #lima
stilbruch has quit [Remote host closed the connection]
stilbruch has joined #lima
Daanct12 has quit [Quit: WeeChat 4.3.5]
ity has joined #lima
ity1 has quit [Ping timeout: 480 seconds]
<linkmauve>
Hi, I’ve noticed that we expose GL_NV_generate_mipmap_sRGB but not GL_EXT_sRGB, which sounds like a requirement for it.
<linkmauve>
Is sRGB not possible to support on this hardware, or is it just not implemented?
<linkmauve>
Oh but there is EGL_KHR_gl_colorspace, so at least for rendering that should be fine.
<enunes>
linkmauve: I never looked into it, but looks like lima offers some srgb framebuffer formats so we expose GL_EXT_framebuffer_sRGB which allows GL_NV_generate_mipmap_sRGB
<enunes>
don't know if GL_EXT_sRGB should also be there in the case of GLES or if there is some bug and we should not expose GL_NV_generate_mipmap_sRGB in that case?
<enunes>
even in CI lots of srgb-related known failures though
<linkmauve>
enunes, GL_EXT_sRGB is about being able to use textures in sRGB (that is, to convert them to linear before doing operations on them), whereas EGL_KHR_gl_colorspace is about the default framebuffer, AIUI.
<enunes>
for textures I think there is a lowering that we never wired up
<linkmauve>
Lowering in the shaders, so that it would do the conversion on texture2D()?
<linkmauve>
Ah, GL_EXT_sRGB is also about drawing to arbitrary framebuffers, with the equation provided.
<enunes>
yes lowering in shaders, I believe we never finished handling that properly, which explains the remaining CI failures
<enunes>
if you try that and find out and it really doesn't work as advertised, feel free to file an issue and I could look into that again at some point (or patch :)
<linkmauve>
I can try to give it a try. :)
<linkmauve>
I see vc4 has it enabled, I’ll have a look at that driver.
<linkmauve>
Too bad I don’t have any board supported by that driver.
<linkmauve>
enunes, how can I run the CI locally to get the failures?
<linkmauve>
I could write a small program using sRGB otherwise.
<linkmauve>
Or should I instead run the cts?
<enunes>
you can build the CTS locally or also piglit has failing srgb tests as well
<enunes>
.gitlab-ci/container/build-deqp.sh in mesa has how the CTS is built in CI
<enunes>
src/gallium/drivers/lima/ci/lima-fails.txt has the current fails if you search for srgb you can see there are lots of them
<linkmauve>
/usr/bin/ld: final link failed: No space left on device
<linkmauve>
Fail. ^^'
<linkmauve>
I should have bought a bigger microSD.
<linkmauve>
Thankfully my newer boards have a NVMe slot so I can use better storage.
<linkmauve>
Ugh, and egl-util.c depends on Xlib, even though I have passed -DPIGLIT_USE_X11=false…
<linkmauve>
Oh, I got access to a vc4 board and it also doesn’t expose GL_EXT_sRGB, for some reason.