01:00 luc: <DMJC> on my laptop PRIME=1 is coming up as intel, PRIME=2 and PRIME=0 come up as AMD <- DRI_PRIME=2 and PRIME=0 looks to make no sense according to the Mesa doc https://docs.mesa3d.org/envvars.html#envvar-DRI_PRIME
01:02 luc: neither the code, https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/loader/loader.c#L362
03:37 simpleman: what is x
04:12 CounterPillow: simpleman: https://en.wikipedia.org/wiki/X.Org_Server
04:13 simpleman: many thank yous
05:17 mareko: why do unused fall and fany NIR opcodes exist?
05:26 mareko: alyssa: ^
07:35 MrCooper: dviola: the system one should be picked by default; for an alternative one, I think you'll need to set LD_LIBRARY_PATH for glamor and LIBGL_DRIVERS_PATH for glx
07:35 tzimmermann: airlied, do you still take PRs from drm-misc-next-fixes ?
07:48 airlied: tzimmermann: yes will pull that together tomorrow
07:48 tzimmermann: ok, thanks
07:59 airlied: tzimmermann, mlankhorst : also if there are any drm-fixes stragglers might be good to get them, though probably won't merge those until after rc1
08:00 tzimmermann: airlied, there's still last week's PR for drm-misc-next-fixes pending. can you merge it before i prepare this week's
08:00 tzimmermann: ?
08:02 airlied: tzimmermann: pushed now
08:02 tzimmermann: thank you
09:19 DMJC: ok this is really weird, got a WINE game, it works on 32-bit X11 on NVIDIA closed source, but on AMD/Intel only works on 16-Bit X11.
10:05 alyssa: mareko: for non-integer (float-only) hardware
10:05 alyssa: which I think is all vec4
10:06 alyssa: no booleans on float-only hardware
10:06 alyssa: instead of flt, we have slt which returns b2f32(flt)
10:06 alyssa: and install of ball/bany we have fall/fany which return b2f32(ball/bany)
10:07 alyssa: now, why they would be /unused/ is a different question.
10:07 alyssa: they don't actually look unused, though
10:08 alyssa: It looks like the relevant backends set lower_vector_cmp, which gets them lowered to vectorized float compares in "interesting" ways for opt_lagebraic
10:08 alyssa: and they're produced by bool to float
10:10 alyssa: with the boolean versions bany/ball at least nominally produced by glsl-to-ir
10:10 alyssa: how true that actually is is unclear
10:11 alyssa: at any rate, all() in GLSL will become ball after glsl-to-nir, which becomes fall after lower bool to float, which becomes some vectorized alu after opt_algebraic
10:12 alyssa: possibly the right call is to fold those lowerings together, turn ball/bany into the alu directly in opt_algebraic
10:12 alyssa: and then delete the opcodes
10:12 alyssa: not exactly high on my todo list, they're not hurting anything existing
10:31 DMJC: I found the issue with my WINE game
10:31 DMJC: 24-bit OpenGL support. Found a config file and changed 24 to 32 boom it works.
10:31 DMJC: must be a throwback to the bad old days of 24-bit colour X11
10:50 MrCooper: when bytes were precious
10:55 DMJC: I'll let the patch authors know so they can either add an option or default to 32-bit colour.
10:56 DMJC: So atm, Wing Commander 1-4/Privateer 2 runs in WINE, and 5/Secret Ops runs with an adjusted ntdll/heap.c
10:56 mlankhorst:thought i386 compiled in protected when he heard 16-bit x11
11:02 dviola: MrCooper: thanks
11:04 dviola: I think I'd like to file a bug first, not sure if I should do so under https://gitlab.freedesktop.org/mesa/mesa or https://gitlab.freedesktop.org/virgl/virglrenderer though
11:23 dviola: I think I'll file it under mesa, I've seen a couple of virgl ones there
14:18 MrCooper: the OpenGL pixel unpack machinery really can't ignore the alpha channel and return 1.0 instead, can it?
14:18 zmike: is there context here?
14:19 emersion: it's just an OpenGL API question, no?
14:19 emersion: i don't know the answer
14:19 MrCooper: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1131 could use this to force alpha to 1.0 with glTexSubImage
14:20 MrCooper: but AFAICT there's no way to achieve that
14:22 zmike: texsubimage still uploads a buffer, so it depends if the underlying driver is able to use a true RGBX format for the use case or is using RGBA to emulate
14:23 MrCooper: that's the thing, there's no RGBX for the glTexSubImage format parameter, only RGBA or RGB (which means 3 bytes per pixel)
14:23 MrCooper: anyway gotta run, bbl
14:23 zmike: right, I'm talking internally
14:24 zmike: potentially in the case of real RGBX it could take RGB? a lot of it depends on the individual driver mechanics/handling
14:24 pq: you can't do GL_RGB, GL_UNSIGNED_INT_8_8_8_8?
14:24 MrCooper: nope, spec explicitly excludes that
14:24 pq: awesome
14:25 zmike: in general I think the answer to your query is "no"
14:25 MrCooper: zmike: what's needed there is loading 4 bytes per pixel, but ignoring the alpha byte and storing 1.0 instead in the texture image
14:26 zmike: it seems like that would come down to driver mechanics and whether the driver is aware that the image is RGBX and is then able to ignore alpha
14:26 zmike: mesa/st can be made to do whatever drivers can do in one way or another
14:26 emersion: i force alpha=1 in a shader personally
14:26 pq: do you need the texture to have a real alpha channel?
14:29 emersion: MrCooper: https://www.khronos.org/opengl/wiki/Texture#Swizzle_mask maybe
14:29 zmike: you can follow try_pbo_upload_common() through to the driver entrypoints for the current handling
14:30 zmike: I guess you'd want to change templ.swizzle_a = PIPE_SWIZZLE_W; in certain cases
14:30 emersion: GLES3 has GL_TEXTURE_SWIZZLE_A
14:30 zmike: ah wait nvm it's a texel buffer
14:30 zmike: so this is all invalid
14:31 zmike: it'd have to be done in the pbo upload shader from st_pbo_get_upload_fs
14:32 MrCooper: pq: yes
14:32 zmike: which doesn't appear to be format-specific, so another variant would be added there
14:32 MrCooper: zmike: driver mechanics are irrelevant for Xwayland if there's no GL API to get at them
14:33 zmike: you're talking about swapchain images or ?
14:35 penguin42: it does
14:35 emersion: hm, right, i was assuming shader access but maybe that's not the case…
14:58 kchibisov: Who is expected to use tearing control, I'd assume mesa?
15:01 emersion: yes
15:01 emersion: there's a MR lost in limbo
15:01 emersion: note, EGL has no knob for this (yet)
15:01 emersion: there are MRs for this too
15:04 kchibisov: Oh, sorry, wrong channel.
15:26 dviola: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9321
15:40 karolherbst: any of the iris devs some time to give this a proper thought? I kinda need this for CL subgroups unless somebody comes up with a better idea: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22893/diffs?commit_id=f01eb8dc3b9b4e9ad17ad17500af886ea587f664 I know alyssa already reviewed it, but I'm still curious what iris devs are thinking as I think it's a bit sketchy myself
15:50 alyssa: r-b
16:05 zmike: my first thought is why is this a ctx method and not a screen method
17:14 MrCooper: zmike: glTexSubImage2D, uploading texel data from a PBO or plain system memory to a texture image (with an alpha-ful internal format, but alpha must always end up as 1.0 in this specific case for correctness)
17:15 zmike: MrCooper: I was looking through the specs and I don't think there's any way to (legally) do it
17:15 zmike: but with e.g., a MESA extension it would be possible to either add matching functions that ignore alpha or set a property on image creation that forces alpha to 1.0 in all cases
17:15 zmike: internally it would be very easy to handle in mesa
17:32 anholt_: DavidHeidelberg[m]: you've been doing manual rules changes recently, and it seems that scheduled pipelines are no longer running the manual jobs.
17:59 DavidHeidelberg[m]: anholt_: I'll check it
18:56 karolherbst: zmike: because... cso creation/whatever is all context method
18:57 karolherbst: long term I think we want to force all drivers to support shareable shaders and move this to screen, but....
18:57 karolherbst: in any case, I kinda need to force drivers to finalize the compilation and it's really annoying in iris
19:25 HdkR: `/usr/bin/ld: warning: src/glx/libGLX_mesa.so.0.0.0 has a LOAD segment with RWX permissions` :thonking:
20:11 jenatali: David Heidelberg: Has anyone tried to see if the Windows runners are working again? I assume it was just a transient problem