00:04 computermouth: kisak: I don't think that's inherently a problem. So long as I can static link everything, and drop the drm and x11 requirements
00:06 computermouth: the drm dependency is more of a question to me. I was thinking this would be an entirely userspace library, and maybe it still can be, but I just don't know enough about how drm functions there
08:08 itoral: anyone else getting this when trying to run deqp-vk?: ./deqp-vk: symbol lookup error: ./deqp-vk: undefined symbol: glGetInternalformativ
08:08 itoral: I have seen this issue in CTS: https://github.com/KhronosGroup/VK-GL-CTS/issues/141 but adding -Dglvnd=true doesn't fx the problem for me
08:10 itoral: fwiw, it only happens when I run against my compiled version of mesa, running against the system's mesa works fine
08:10 gfxstrand: Does your compiled mesa have a GL build?
08:10 itoral: yes
08:11 gfxstrand: IDK why deqp-vk grew a GL dep but it did
08:11 gfxstrand: hrm...
08:11 itoral: yeah, that puzzled me as well
08:12 gfxstrand: IDK what the driver load path with glvnd looks like but I wouldn't expect glvnd to be involved with a custom mesa build
08:13 itoral: mmm... I see that my build of mesa doesn't have the glGetInternalformativ symbol, but the system's version does
08:13 gfxstrand: I wonder why I'm not hitting this
08:14 itoral: yeah, I only started to hit this when setting up a new laptop
08:14 itoral: doesn't happen to me on the old one
08:14 gfxstrand: woof
08:15 itoral: well, on my old laptop my custom built mesa doesn't have the symbol either :-/
08:17 gfxstrand: Is your CTS building against libGL or libOpenGL?
08:19 gfxstrand: Hrm... I'm seeing GetInternalformativ in both of them on my system
08:19 itoral: how can I check that? the cmake output doesn't specify
08:19 itoral: mmm... interesting
08:20 gfxstrand: Ok, so on my system, I have GetInternalformatiV on the system libGL and libOpenGL but not on my mesa build
08:20 itoral: ah, ok
08:20 itoral: so same as me then
08:20 gfxstrand: but deqp-vk seems to be fine
08:29 MrCooper: itoral: sounds like a deqp-vk bug, pretty sure glGetInternalformativ isn't part of the ABI of any shared library (i.e. GetProcAddress needs to be used for it)
08:30 itoral: maybe, but why is it not affecting everyone else?
08:35 gfxstrand: And why are the system-installed versions providing it?
08:42 MrCooper: glvnd versions may expose more symbols, doesn't mean they can be relied on
08:47 itoral: fwiw, it seems I "fixed" the problem by setting --libdir <install>/lib instead of <install>/lib64
08:48 itoral: and then recompiling CTS again
08:51 gfxstrand: ugh
13:56 daniels: jenatali: looks like we're still periodically hitting timeouts on clc_compiler_test; maybe time to split it up into multiple test progs? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/35743177
14:09 jenatali: Ack
14:10 jenatali: Or move it to a separate job instead of a unit test
14:47 jenatali: Maybe I can add a test job that actually builds the CL runtime to run some piglits or a part of the CTS...
15:07 bbrezillon: airlied: Re io-pgtable => I guess I don't have to, was just trying to avoid duplicating the pgtable code in panfrost :-/
15:13 haasn: what is the status quo of https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer ? is it being used in practice? how does this end up exposed inside the mesa radv/anv icds?
15:14 daniels: haasn: mesa doesn't use it
15:14 daniels: that project is pretty much abandonware
15:14 haasn: sad
15:14 daniels: yeah
15:14 haasn: so where does VK_EXT_headless_surface exist at all anymore? not?
15:14 haasn: I could have sworn it existed in the past on mesa
15:14 haasn: but I can't find any reference to it in the code now
15:14 daniels: you don't need one? you can just create VkImages without a swapchain in Vulkan
15:15 haasn: daniels: I need it for my test framework
15:15 haasn: to test the swapchain code
15:16 X512: I use Vulkan headless surface as gateway for displaying contents on Haiku windows.
15:18 bbrezillon: airlied: didn't implement async bind/binding yet (VM_BIND), and I thought it'd be safe to allocate mem in the VM_{MAP,UNMAP}, since, AFAICT, there's no fence signaling involved there
15:18 bbrezillon: but yeah, we'll have problems when/if we want to support VM_BIND
15:20 X512: For first time I got Vulkan headless surface by using vulkan-wsi-layer in Mesa repo group.
15:21 X512: Now I made own Haiku WSI Layer add-on but it still works throuth headless surface.
15:21 Ristovski: Nice!
15:21 X512: Adding new Vulkan WSI surface type is not trivial.
15:50 X512: My old fix for OSMesa memory leak on buffer resize: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21074
15:56 cmarcelo: hakzsam: hi. any update on the crashed fossil-dbs after trying the SPIR-V patch?
16:01 hakzsam: not yet sorry
18:16 X512: Message seems not sent.
18:16 X512: Anybody familiar with Gallium API? I need suggestions about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21079.
18:26 alyssa: anyone have test coverage for ASTC with border colours?
18:26 alyssa: i guess i could extend texwrap ..
18:28 alyssa:extends texwrap begrudgingly
18:31 mareko: you can also just do nothing
18:32 alyssa: I can?
18:37 alyssa: if test coverage doesn't exist the feature can't hurt me? :-p
18:39 anholt: do the deqp-gles border color tests not cover astc?
18:39 anholt: khr-gles maybe I meant
18:40 alyssa: deqp-gles doesn't
18:40 alyssa: maybe khr, let's see
18:41 alyssa: not seeing anything in khr either
18:41 alyssa: and piglit tests BCn but not ASTC
18:41 anholt: -t border_clamp was the thing I was thinking of, and looks like it doesn't.
18:43 alyssa: nod
18:43 alyssa: Undecided between asserting out or doing a guess in the dark
19:00 airlied: gfxstrand: would rust be much nicer for vulkan drivers if we just decided to not deal with the common code? like I wonder if there is a nicer win in just redoing it
19:10 anholt: I have a suspicion that rust drivers would end up wanting to rewrite vk common at some point. but some incrementalism would probably be good.
19:11 daniels: can't wait to see wsi_common_xcb.rs
19:12 airlied: wsi is mostly a layer anyways
19:12 airlied: so we might be able to push that out a bit
19:12 daniels: there is the separate layer project on GitLab, but it's ... not good
19:12 airlied: no even in mesa we wrote it to act like a layer
19:13 airlied: it might have degraded a bit, but I'm sure we could firm up the boundaries
19:14 airlied: it's more the entry point generators and the sync code I suppose
19:16 alyssa: daniels: can't wait to see x11.rs ;p
19:18 gfxstrand: airlied: Yeah, I think we'd want to go in stages:
19:18 gfxstrand: 1. Wrappers similar to what I put in that MR
19:19 gfxstrand: 2. Modify the C code to make all the structs memmove-able. I.e., no more struct list_head.
19:19 airlied: zmike: llvmpipe reboot in rust...
19:19 gfxstrand: 3. Start replacing bits of common code with Rust, starting with vk_object_base.
19:19 emersion: oh you don't want to deal with Pin<T>?
19:20 gfxstrand: Pin<T> is a pain
19:20 emersion:is disappointed
19:20 airlied: gfxstrand: just replace all the list_head with u_dynarray?
19:20 gfxstrand: Also, even if you use Pin<T>, you still have an initialization problem where things like list_head can't be initialized by creating one and then moving into the final location.
19:20 gfxstrand: airlied: Initially, yeah, probably.
19:20 emersion: i thought you were more brave, but it turns out you're a sane person :P
19:21 gfxstrand: I don't really like dynarray, personally. It always feels less typesafe than list_head to me.
19:21 gfxstrand: emersion: Well, "sane" might be a bit of a stretch.
19:21 airlied: gfxstrand: make a typesafe dynarray :-P
19:21 gfxstrand: emersion: The other option would be for Rust to grow some sort of a concept of placement-new.
19:21 emersion: yeah you need to pin and then mutate
19:21 gfxstrand: airlied: You mean like Vec<T>?
19:21 emersion: it's not great at all
19:21 emersion: and project the pin when mutating ofc
19:21 airlied: but more of the I think we should do that pre-rust anyways, being nice to caches
19:21 airlied: gfxstrand: just write a Vec<T> equiv in C first then :-)
19:22 gfxstrand: airlied: The few things we use list_head for aren't gonna be hot in anyone's cache.
19:22 gfxstrand: It's stuff like walking all the physical devices.
19:22 gfxstrand: Bit meh
19:22 airlied: yeah but it would be nice to get it consistent before rusting it
19:23 emersion: behold my creation https://gitlab.freedesktop.org/emersion/wlroots-rs/-/blob/master/src/listener.rs#L68
19:27 gfxstrand: But, yeah, once we get all the C types moveable, that'll make rust binding a lot easier.
19:29 gfxstrand: And we can have pub fn vk_foo_init(*mut foo, ...) { foo.write(Foo::new(...)?); Ok() }
19:30 gfxstrand: So it's easy to move stuff over one thing at a time.
19:30 gfxstrand: The big thing is that I think it'd be easiest to start with BaseObject so that everything else can do VkImage { base: BaseObject::new() ... }
19:33 airlied: hey so has anyone got a good link to anything that helped them "get rust"?
19:33 gfxstrand: Nope
19:33 gfxstrand: For me, it's just been spending time with it
19:33 anholt: airlied: I feel like I've asked this before, but how do I dump the LLVM ir generated?
19:33 gfxstrand: But the key is don't fight it.
19:33 airlied: ah okay, guess I gotta go old school and grind
19:33 Sachiel: leaving a sheet of iron out in the open will get you plenty of rust
19:33 airlied: anholt: GALLIVM_DEBUG=ir
19:34 anholt: thanks
19:34 airlied: Sachiel: I have a car to do that :-P
19:34 gfxstrand: If you fight it, it'll just be frustrating and clearly worse C.
19:34 anholt: was looking in lp_debug
19:34 Sachiel: gfxstrand: what do you mean by not fighting it?
19:35 emersion: from my PoV, you fight it whether you want it or not
19:35 gfxstrand: When you run into trouble, don't reach for unsafe or try to fight the borrow-checker. Take a step back and ask if there's a different way you could structure your code that doesn't rely on weirdly linked data structures.
19:35 gfxstrand: Often, there is.
19:35 gfxstrand: The more you do that, the more you learn to let rust work for you instead of against you.
19:35 anholt: gfxstrand: yes, exactly
19:36 gfxstrand: Of course, it depends on what you're trying to do. If you're writing a Wayland compositor, that's gonna be hard. You're going to have Arc and Rc everywhere because that's the way Wayland wants to work. You're not really fighting Rust in that case, you're fighting to very different ways of thinking about problems.
19:36 gfxstrand: *fighting the mismatch between two very different ways of thinking about problems.
19:37 gfxstrand: Unfortunately, a legacy C code-base like Mesa is going to have a LOT of Cisms that are difficult to work around.
19:37 gfxstrand: Not the best environment for learning Rust.
19:40 alyssa: gfxstrand: Yeah, I know how you feel about Cisms
19:41 gfxstrand: alyssa: 🥚
20:14 alyssa: how do I have this many commits on top of main in my {agx,panfrost}/next branches
20:14 alyssa: when did I become Android
20:21 ccr:ponders if alyssa has a positronic brain.
20:23 HdkR: alyssa: Watch out, Google might want you to work on the Android Graphics stack
20:23 alyssa: oh no
20:23 alyssa: or oh yes?
20:23 alyssa: is that good or bad?
20:23 alyssa: you say it like a threat
20:23 HdkR: The Android Graphics Stack stares back menacingly
20:25 alyssa: emersion: do I want to work around a wlroots bug in mesa yes or no
20:26 emersion: no!
20:26 emersion: what is the bug?
20:26 alyssa: using mediump texture coordinates
20:26 alyssa: which a conformant GLES driver is allowed to implement as fp16
20:26 alyssa: which is not enough precision for 4K textures
20:26 alyssa: which means blocky artefacts on the right side of the screen
20:27 alyssa: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/render/gles2/shaders/tex_rgba.frag
20:27 alyssa: example of a buggy shader
20:27 emersion: what should wlroots do?
20:27 alyssa: `highp varying vec2 v_texcoord;`
20:27 emersion: oh.
20:28 alyssa: i'm tempted to workaround in mesa anyway, I already do so on Panfrost and I expect there are piles and piles and piles of broken apps with this exact bug
20:29 emersion: weston has the same bug FWIW
20:29 alyssa: delight
20:29 emersion: does the "precision mediump float" has any say in this?
20:30 emersion: i'll type the wlroots patch, it'll make it in 0.16.2
20:33 alyssa: the precision mediump float line sets the default shaderwide
20:33 alyssa: it's fine if the output variable is fp16, it's just the texture coordinates that need the extra precision
20:33 emersion: ah maybe Weston is fine since... recently
20:34 alyssa: TBH I expect piles of stuff in the wild will break if I try to optimize this so I'm just going to.. not
20:34 alyssa: since I'd rather not play driconf whack-a-mole for something that probably doesn't matter for perf
20:44 alyssa: emersion: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21082 the workaround in question
20:45 alyssa: (but you should still fix sway :p)
20:45 emersion: i probably need to use highp for the matrix as well
20:45 alyssa: possibly
20:54 alyssa: the GLSL precision qualifier was the biggest mistake in GLSL imho
20:54 alyssa: there is no way to use it unproblematically
21:03 jenatali: Probably the same reason D3D added it. It makes some hardware go brrr
21:05 airlied: at least on mobile, it makes some hardware go
21:07 daniels: ugh
21:07 mattst88: yeah, but the precision qualifiers themselves and the optionality of it all is terrible
21:08 daniels: looking at Weston, we set 'precision highp float' if GL_FRAGMENT_PRECISION_HIGH is set ... but only in the frag shader, and that macro is only ES3.1+
21:08 daniels: oh, but Mesa defines it for all ES contexts
21:09 daniels: alyssa: know off the top of your head what happens if we have 'varying vec2 v_texcoord' in both VS&FS, but 'precision highp float' only in FS, and nothing defined in VS?
21:10 emersion: lol
21:10 emersion: that sounds fun
21:10 zmike: airlied: I'm on it
21:12 emersion: bleh i'm not even sure what the right fix is
21:19 anholt: 30 -> 1.7 seconds on these llvmpipe tests. now to just make them pass again. :/
21:19 emersion: in strict GLSL 1.20, mediump doesn't actually exist
21:20 emersion: ahahah this table https://l.sr.ht/gKiV.png
21:20 zmike: nice anholt!
21:20 emersion: this is GLSL 1.30
21:28 emersion: daniels: i believe that macro is GLES2, it's in here at least https://registry.khronos.org/OpenGL/specs/es/2.0/GLSL_ES_Specification_1.00.pdf
21:33 daniels: emersion: yep, looks like you're right - highp's mandatory for VS, and available in FS iff that macro is defined
21:34 emersion: and the answer for your question:
21:34 emersion: if the vertex shader doesn't set the default, it's highp for float
21:34 emersion: if the fragment shader doesn't set the default, it's whatever the driver wants
21:35 emersion: see 4.5.3
21:35 emersion: ah no
21:35 emersion: if the fragment shader doesn't set the default, it's an error
21:44 daniels: emersion, alyssa: #ifdef GL_FRAGMENT_PRECISION_HIGH
21:44 daniels: #define HIGHPRECISION highp
21:44 daniels: #else
21:44 daniels: #define HIGHPRECISION mediump
21:44 daniels: #endif
21:44 daniels: ffs
21:44 daniels: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1145
21:44 emersion: yeah
21:45 emersion: typing the commit message now :P
21:45 daniels: haha
21:45 daniels: I'll be glad when Chrome's clipboard is fixed
21:54 emersion: alyssa: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3997
22:12 alyssa: daniels: "know off the top of your head what happens if we have 'varying vec2 v_texcoord' in both VS&FS, but 'precision highp float' only in FS, and nothing defined in VS?"
22:13 alyssa: If separable shaders are used, that's invalid
22:13 alyssa: Otherwise the precisions get linked together. Unsure what Mesa will produce for that particular combination, possibly mediump
22:14 alyssa: oh right but emersion pointed out VS defaults to highp, not defaults to mediump (different from FS) because of course
22:14 alyssa: so yes that will give you highp
22:14 emersion: """"sane""""
22:15 alyssa: literally
22:16 alyssa: emersion: strictly, the wlroots commit message isn't right
22:16 alyssa: (even though the patch is)
22:16 alyssa: 2^14 = 16384, which is plenty
22:16 alyssa: the issue is the precision
22:17 emersion: eh
22:17 alyssa: IEEE 754 fp16 floats have a max value of about 65k
22:17 alyssa: so overflow isn't a problem
22:17 alyssa: for tex coords
22:17 mareko: are you sure?
22:17 alyssa: the problem is they only have 11 bits of significand
22:19 mareko: the exponent should give you much higher values than 65K
22:20 alyssa: which means consecutive integers near 4096 have identical fp16 representations => precision loss => wrong pixels are sampled
22:20 alyssa: mareko: 5 bits of exponent, but the exponent is signed
22:20 mareko: ok
22:21 alyssa: so 0b1111 = 15 is the maximum exponent (2's complement representation)
22:21 mareko: it's indeed +-65504
22:22 alyssa: rig
22:22 alyssa: right, giving a maximum value of
22:22 alyssa: >>> (2**15) * (1 + (1 - (1/(2**10))))
22:22 alyssa: 65504.0
22:22 alyssa: (...Knowing IEEE 754 arithmetic by heart is an occupational hazard :|)
22:23 alyssa: emersion: anyway, floats in [2047, 4094) have an exponent of 10
22:23 emersion: yeah that makes sense
22:23 alyssa: so mantissa bits corresp-- hold on I have an off by one somewhere
22:24 HdkR: Sounds like typical float problems. just off by a ulp
22:24 HdkR: ;)
22:24 alyssa: right yes there it is
22:24 mareko: there is one value above 65504 though: +inf
22:24 alyssa: [2047, 4094) have an exponent of 11
22:24 mattst88: wikipedia has some useful tables -- e.g. https://en.wikipedia.org/wiki/Half-precision_floating-point_format#Half_precision_examples
22:24 alyssa: at an exponent of 11 with only 10-bits of mantissa, 1 ulp = 1/2
22:25 alyssa: so you get rounded to every other pixel when sampling [2048, 4096) which isn't right
22:26 mattst88: oof
22:26 alyssa: however integers <= 2048 can be stored exactly as fp16
22:27 alyssa: so the visual artefacts don't happen with 1080p
22:27 alyssa: (correction: at exponent 11 with 10-bits of mantissa, 1 ulp is 2)
22:29 HdkR: I love true lowp and mediump for how often it gets messed up
22:30 mareko: caffeine hangover is no fun
23:05 anholt:wonders how many more silly compiler fixes it would take to hit <10 minutes for full lvp in ci.
23:07 alyssa: :o
23:12 glennk: fp16 coordinate precision issues, is this 2007?
23:17 alyssa: yes
23:17 alyssa: good news, just one more year and Obama will be president
23:19 glennk: think it was the first gen tegra that only supported fp16 and lowp in fragment shaders
23:20 glennk: and then not supporting fp16 in vertex shaders
23:56 mareko: glthread enablement reverts for 22.3 and 23.0 are up
23:58 alyssa: glthread 23.1 is the hope then?