00:41tarceri: glx: compare config masks, not just sizes
01:07tarceri: with that reverted nothing gets better or worse. I can't test the wayland I believe because r300 on big endian fails list any of the 8888 formats (I still haven't figure out why). This is where is differs from r600 for testing purposes
01:52tarceri: i.e. I can't test any of the changes to the 8888 array formats
04:23daniels: tarceri: hrm, so on the commit before the glx commit (i.e. HEAD is the FP16 commit) things are fine, on the glx commit things are broken, then on the HEAD of that branch + glx changes reverted things are still broken, right?
04:23daniels: tarceri: how does it break - channel swap or no configs?
04:27tarceri: only that commit breaks things. It end up with no config, with it reverted things work again. But as above my testing doesn't really cover most of the format changes you made
04:28tarceri: * things work again on the HEAD of your branch
04:29daniels: right, was just confused by 'with that reverted nothing gets better or worse'
04:30tarceri: right, sorry bad wording by me. Just meant that is the only commit that changed anything for me, for good or bad
04:32daniels: yeah, gotcha - I'd be interested to see if adding PIPE_FORMAT_X8R8G8B8_UNORM + PIPE_FORMAT_X8B8G8R8_UNORM + PIPE_FORMAT_A8R8G8B8_UNORM + PIPE_FORMAT_A8B8G8R8_UNORM to the list in dri_fill_in_modes[] made things work again with the branch HEAD as it is?
04:48tarceri: let me try. I've tried a few things can't remember if that was one of them
05:03tarceri: nope :( no change. pretty sure I tried that already
05:04daniels: that's bizzare - so what's the failure mode? clients don't have any modes? clients render with channel swap?
05:11tarceri: What is that table for dri3? I think I was building the legacy path. The issue is I need to force Depth to 16 not 24 in xorg settings
05:11tarceri: or the driver fails to load
05:12daniels: hmm, 'driver fails to load', do you mean the xorg driver, or x11 clients?
05:13daniels: if the xorg driver, does it give some kind of error or?
05:13daniels: I don't understand how that commit would change anything about xorg driver loading, given it's only in the glx code used by clients ...
05:17tarceri: the xorg driver is fine the mesa driver just complains about no visual configs. Basically the driver has regressed back to this: https://bugs.freedesktop.org/show_bug.cgi?id=71789
05:19tarceri: Your commit doesn't cause this by the way, the 8888 formats are already missing
05:19tarceri: With your commit everything else goes missing too
05:20daniels: impressive
05:29daniels: ah right, turns out the protocol doesn't actually carry the shift or mask. good stuff.
05:33tarceri: So the bit I don't get is this new dril loader for dri2 it pulls the configs from egl but were are those coming from originally?
05:34daniels: those are gbm
05:35daniels: init_dri2_configs() creates a gbm_device and an EGLDisplay against that then iterates the EGL_NATIVE_VISUAL_ID - so those will be from platform_drm.c / gbm_dri.c and using the GBM_FORMAT fourccs
05:35tarceri: thats what I assumed, so I don't get why this r300 driver doesn't pick them up like r600 does
05:40daniels: r600 just looks at the properties (channels/sizes/swizzles/etc) of the format and makes up a format based on that
05:41daniels: r300 has a hardcoded list of formats it supports instead - pipe_screen->is_format_supported(PIPE_FORMAT_X8R8G8B8_UNORM) will fail on r300 because r300_translate_colorformat() doesn't have a case for it, so those configs will never be added to the list
05:41daniels: I think if you fixed that then you'd be in the same place as r600, i.e. with working array formats
05:41tarceri: r600 got busted when the list in gbm was updated previously
05:41daniels: yeah and the fix to gbm was the right one
05:42tarceri: right and I mostly fixed up r600 following that
05:43tarceri: I see the is_format_stuff in r300 I'm tried extending that table and also sticking stuff elsewhere but it enjoys being stubborn
05:43daniels: yep, so r300 just needs support for the pipe_formats you added to the map in 642c4cf2b2f3dcd2cc1506a8ff3e143be396444a - then you should be in the same place as r600
05:45daniels: I assume you'd need to add it to r300_translate_colorformat() plus the swizzles in r300_translate_colormask_swizzle() and r300_translate_out_fmt()
05:45tarceri: I believe its mean to flip it at the top of all those
05:47tarceri: r300_unbyteswap_array_format()
06:05daniels: yeah, it does look that way - basically, you should have dri_fill_in_modes() adding PIPE_FORMAT_X8R8G8B8_UNORM to the list because pscreen->is_format_supported() returns true, then drm_add_config_for_visuals() adding it because it's present in the list in gbm_dri.c; when dril enumerates the list it should see a GBM config with EGL_NATIVE_VISUAL_ID == DRM_FORMAT_BGRX8888, convert that back to PIPE_FORMAT_X8R8G8B8_UNORM and use it
09:12jani: demarchi: want to make maintainer-tools MAINTAINERS reflect reality?
09:13jani: mripard: rodrigovivi: ^
10:36jani: mlankhorst: FYI I just sent the drm-intel-next pull request with the drm panic changes. once dave pulls it, you can backmerge it to drm-misc-next
12:44Hazematman: Hey, I worked on a fix for llvmpipe/lavapipe/swrast to fix a bug a colleague encountered with containers and xshm where the extesnion was enabled but you didn't have permission to bind the shm. I'd appreciate it if anyone could give it a review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35284
13:16zmike: from where does piglit-runner get its caselist?
13:16zmike: cc anholt
13:17zmike: I'm seeing it pick up tests that don't exist
13:17zmike: trying to figure out if it's something broken in my piglit checkout
13:59anholt: zmike: it reads the built caselist file.
13:59zmike: anholt: where is that?
14:01anholt: piglit's build system runs python to generate some xml.
14:01zmike: oh I see
14:01zmike: TIL
14:01zmike: thanks