03:38 airlied: yay have most of what appears to be a working llvmpipe msaa + sample_shading
03:38 airlied: now to work out how to make it reviewable
03:40 imirkin: impressive!
03:40 imirkin: look at the gs5 stuff for the sample shading bits too, if you haven't already
03:40 ccr:bows at airlied's skill.
03:41 airlied: imirkin: yeah I've tried to cover that, ordering all the bits is a bit of a mess
03:42 imirkin: ok
03:43 airlied: I have a separate patch series to add interpolation
03:43 imirkin: i meant stuff like gl_SampleMaskIn
03:44 imirkin: and the centroid vs per-sample interp
03:45 airlied: yeah got centroid working, messily
03:50 anarsoul: hm, so R8 and R8G8 are not renderable formats?
03:51 anarsoul: dEQP-GLES2.functional.fbo.completeness.renderable.texture.color0.r8 fails if I expose it as renderable
03:52 imirkin: mmm
03:53 imirkin: they're not renderable in GLES2 iirc
03:53 imirkin: but that should be controlled at the API level, not at the gallium level
04:04 anarsoul: :\
04:12 anarsoul: OK, so lima now exposes EXT_texture_rg
04:13 anarsoul: and according to https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_rg.txt this is renderable format
04:13 imirkin: ok
04:13 imirkin: well perhaps the test fails with good reason then?
04:15 anarsoul: Fail (Framebuffer checked as complete, expected incomplete)
04:15 imirkin: fun
04:16 imirkin: could be a bug in the test -- it might only be checking for gles3 and not EXT_texture_rg
04:26 anarsoul: I'll just add these tests to skips for lima
09:46 MrCooper: anholt_: it's kind of ridiculous though to allow >= minute timeouts for tests which normally finish in a few seconds (even for s390x)
09:48 MrCooper: I'm also wondering if it's worth bothering with a Vulkan replacement for glamor, the latter (+ zink for any future HW without native GL drivers) might be good enough?
13:36 tpreston_: Hi, I have a client who wants to open source their existing graphics driver. Ideally they'd like a driver in the upstream kernel, but at present it's about 80k lines of an external kernel module. It doesn't use DRM and has a bunch of proprietary userland libs which talk to it. Is there a place in the kernel for drivers like this or should it just be left as an external module?
13:37 tpreston: It seems to me that the whole thing needs a rewrite to use DRM
13:38 emersion: that would be best, yeah
13:38 emersion: but i don't know the policy
13:40 tpreston: emersion: you mean rewriting it to use DRM?
13:41 emersion: yeah
13:54 pq: tpreston, proprietary userland implies that the driver has "new UAPI", which means the DRM new UAPI rules will apply. Even after conversion to use DRM core, it could be a major hurdle, particularly if the userspace bits are complicated.
13:57 pq: tpreston, maybe do it piece-wise by starting a proper DRM driver from scratch, one the parts of functionality that can be done with existing upstream UAPI?
14:05 tpreston: pq: by existing UAPI you mean things like Gallium/MESA?
14:07 xexaxo1: tpreston: does the hardware have a display controller, GPU/renderer or both?
14:08 xexaxo1: on the former side, DRM has pretty standardized KMS (kernel mode setting infrastructure) with a bunch of tests in IGT
14:10 sravn: danvet: any feedback on "[PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()"?
14:11 MrCooper: pq: thre's no driver agnostic DRM rendering UAPI
14:11 danvet: sravn, *shrug*
14:11 danvet: not sure that's worth the churn
14:11 danvet: since once we ahve drmm_ we'll churn right again
14:11 danvet: feels a bit pointless to me, but not enough that I'll stop you :-)
14:12 sravn: danvet: Was not fan of the drm_simple_* for somthing that is not simple.
14:12 tpreston: xexaxo1: I don't have reference hardware yet, primordial soup stage yet. As I understand it though, the display controller is provided by some other vendor and this driver just talks to that
14:13 tpreston: It comes with an example display driver but I think you're supposed to hook it into whatever drives the hardware you're using
14:14 xexaxo1: tpreston: if it were me, I'd start with barebones/dummy DRM driver. Then wire a basic modesetting support - one connector/encoder/plane, coulple of formats
14:14 sravn: danvet: We should not apply it just because the patch was made, and as you think "pointless" and Thomas is not fan either I will drop them.
14:15 danvet: sravn, yeah the entire simple encoder thing is a bit in the air I think
14:15 xexaxo1: tpreston: with that in place, then another person (say a colleague) could start hacking on the rendering side - kernel and userspace - a Mesa driver (for OpenGL/ES and/or Vulkan) is a good approach.
14:15 danvet: converting it fully over to drmm_ will be anything but simple I feel like
14:16 danvet: since a lot of drivers do things totally backwards, and I'm also not yet entire clear on what's the best approach
14:16 danvet: sravn, I don't think your series was wasted, since it does give us a fairly good overview of what's there at least
14:16 sravn: danvet: shelfed fgor now, we can re-visit after drmm_ has landed (hopefully in the not so far future)
14:17 sravn: s/fgor/for/
14:17 danvet: I sometimes calle these series "active assessment of current state by changing everything just to see what blows up in compile testing" :-)
14:17 xexaxo1: tpreston: depending on the display controller type/details - it might be better to model it as drm_bridge
14:18 xexaxo1: tpreston: skim through one of the smaller ones to get the feel
14:21 tpreston: ok thanks xexaxo1, this feels like a huge project
14:25 jekstrand: eric_engestrom, anholt_, dcbaker: I'm running into a problem with CI and I'm not sure how you think it should be best handled. !4228 has a CI failure because one of the unit tests segfaults on the mingw unit tests. At this point, I'm fairly convinced that the crash is either a bug in some windows debug code in mesa or else it's a bug the mutex implementation in the utterly ancient version of wine
14:25 jekstrand: in the test container.
14:25 jekstrand: In either case, I'm very sure it's not my bug
14:26 jekstrand: To be more specific, the bug comes up because I started using the os_malloc/free_aligned helpers in util/os_memory.h which, on windows, call into the memory allocation tracking in u_debug_memory.c which then segfaults while trying to lock its mutex.
14:27 jekstrand: I can't repro the issue on the version of Wine on my laptop (5.3). I've not tried on real windows.
14:27 xexaxo1: tpreston: for display controller only drivers, it can be pretty small. for example original drm/pl111 was 800 loc, with a little more for other variants
14:29 ajax: meson.build:with_gallium_zink = gallium_drivers.contains('zink')
14:29 ajax: ... okay ...
14:29 ajax: desoxy:~/git/mesa% meson configure build -Dgallium-drivers=iris,swrast,zink
14:29 ajax: ERROR: Options "zink" are not in allowed choices: ", auto, kmsro, radeonsi, r300, r600, nouveau, freedreno, swrast, v3d, vc4, etnaviv, tegra, i915, svga, virgl, swr, panfrost, iris, lima"
14:31 pq: MrCooper, I was hoping it has a display function.
14:32 tpreston: xexaxo1: I meant before that this is a graphics driver, which interfaces with a third-party display driver
14:32 tpreston: So it'll be much more complicated than that I believe.
14:33 ajax:wonders if this is some kind of prank or, like, hazing ritual
14:33 jekstrand: Seems to run fine on real windows
14:35 pq: ajax, I guess forgets to mention zink in meson_options.txt
14:35 ajax: pq: nope. but apparently editing that file is not on its own enough for meson to notice that there are new options
14:36 ajax: the options and their legal values are copied into the builddir at 'meson setup
14:36 ajax: time
14:36 xexaxo1: ajax: do you recall our chat a while back about removing ROOT requirement for DROP_MASTER?
14:36 pq: Oh.
14:36 ajax: so it's a problem that can be solved with rm(1), which does mean it's my favorite kind of problem, but still
14:37 pq: ajax, meson --wipe is a thing too
14:37 ajax: xexaxo1: a bit hazy but yeah. i think my position was remember if a drm client ever _had_ master so it can reacquire it after dropping?
14:37 ajax: pq: blink, new to me. thanks!
14:37 xexaxo1: ajax: precisely here's a patch that does it https://patchwork.freedesktop.org/patch/354001/
14:37 ajax: ♥ my hero
14:38 ajax:gets his review goggles on
14:38 xexaxo1: ajax: with that in place I can run X w/o root access, plus it doesn't mess with drm_clients on other VTs
14:38 pq: ajax, sorry, meson setup --wipe path/to/source
14:39 ajax: xexaxo1: augh, a month old, this patch. my apologies.
14:41 xexaxo1: ajax: if you want to give it a test note that some drivers like xf86-video-{intel,nouveau} (yeah I know) do _not _ call drmSetMaster during ScreenInit()
14:42 xexaxo1: so they don't crash X ... although the drop/set in their VT handler is no-op. it'll block a client on another VT
14:43 xexaxo1: other drivers like the modesetting one, amdgpu, etc will call drmSetMaster during ScreenInit and will the X instance... if the patch is not applied and X is rootless
14:43 Venemo: jekstrand: welcome to the world of CI misfortune
14:44 jekstrand: Venemo: :-(
14:45 ajax: xexaxo1: tangentially related, can we change the if (!file_priv->master) bit of drm_setmaster_ioctl to return -EBUSY instead of -EINVAL ?
14:45 Venemo: by now, I'm almost convinced that all ARM drivers secretly use ACO, and that's why their CI fails on my ACO commits
14:45 ajax: unique error codes for unique error conditions, please
14:46 xexaxo1: ajax: from memory, it should be safe. I can follow-up with another patch for that - after double-checking exising userspace.
14:47 xexaxo1: ajax: fwiw there's a libdrm helper drmIsMaster() - which will tell if the caller is currently master.
14:48 ajax: xexaxo1: i _think_ it can only matter for callers that use ioctl() directly
14:48 xexaxo1: in case you've got some code laying around wondering
14:48 ajax: mm, nevermind. drmSetMaster does look like it handles errno sanely
14:49 ajax: but at least weston and all the X drivers only report errno and not handle it conditionally, fwict
14:59 MrCooper: xexaxo1: why does it matter if ScreenInit calls drmSetMaster? If it was master implicitly by virtue of there not being another master, should still be able to drop master and get it again?
15:04 xexaxo1: MrCooper: depends on where to draw the line...
15:04 xexaxo1: MrCooper: it's not an issue as it highlights a potential future problem
15:05 xexaxo1: potential problem - a drm_client on another VT
15:09 xexaxo1: seemingly that's not a consern for xf86-video-{intel,nouveau}, although modeset/amdgpu does the more robust thing (IMHO) by bailing early
15:11 ickle: for some value of robust, X bailing is data loss
15:12 ickle: X reporting error back to client is robust
15:18 ajax: what error is X going to report if an implicit modeset fails?
15:18 ajax: there's not many reasonable ways to fail in EnterVT
15:19 ajax: there's abort, there's exit, there's raise..
15:19 MrCooper: this happens before clients can connect anyway, doesn't it?
15:20 MrCooper: again not sure why modeset would fail in EnterVT but not in ScreenInit
15:21 ajax: while you've left the vt, someone else took it, and they're not wired to drop it for some reason?
15:21 ajax: which i suppose is drmSetMaster failing not a modeset proper, but.
15:21 MrCooper: right, but that's an existing scenario without xexaxo1's patch
15:22 ajax: yeah, i don't think that patch can make anything fail that currently works.
15:22 ajax: maybe create new ways to get to a DoS instead of an outright failure
15:26 xexaxo1: today, there are plenty of ways to DoS a compositor on another session/VT.
15:27 xexaxo1: the patch addesses a few cases, but not all.
15:30 MrCooper: jekstrand: if you're sure the crash isn't related to your changes, disable the crashing test in CI?
15:31 tpreston: re: upstreaming pre-existing out-of-tree graphics driver. To clarify, are non-DRI drivers accepted in upstream at all? A complete re-write seem like drastic action for an already working (but perhaps, poorly written) driver
15:32 ajax: tpreston: possibly into drivers/staging/ ?
15:33 jekstrand: MrCooper: It's part of ninja test. Not quite so easy to disable in CI, I'm afraid. :-(
15:34 MrCooper: put a patch to disable it in the tree, and apply that patch before the build?
15:35 jekstrand: I guess that could be done
15:35 jekstrand: Or we could upgrade Wine in the container. :)
15:35 jekstrand: But I don't relaly know how that's done
15:36 tpreston: ajax: that looks like it could partially solve the problem. We want to do the re-write but our client also wants to deliver code to customers asap
15:36 MrCooper: yeah it's a bit tricky, newer Wine is only available in testing
15:36 tpreston: drivers/staging might be the right place to put it while we work on the rewrite
15:36 tpreston: that's if integrating the out-of-tree driver isn't too hairy
15:37 jekstrand: Honestly, running our unit tests on Wine seems kind-of sketchy IMO
15:39 MrCooper: it could also be e.g. due to the MingW toolchain though, couldn't it?
15:42 MrCooper: n-1 sketchy tests still beats 0 tests in my book
15:55 jekstrand: It's possible it's ming2
15:55 jekstrand: But I don't think so
15:55 jekstrand: The exact same executable runs fine on my wine 5.2 and on real Windows
15:58 xexaxo1: jekstrand: fwiw I'd suggest using mingw-w64 (instead of the original mingw), if you aren't already
15:59 xexaxo1: development is far more active and from experience (a few years back) w64 was less glitchy and more feature complete
16:01 Venemo: jekstrand: can you pls take a 2nd look at the two NIR commits in MR 4165?
16:07 jekstrand: xexaxo1: It's using -w64
16:31 jekstrand: anholt_, krh, robclark: I'm seeing a lot of random fail in the freedreno CI.
16:32 robclark: a5xx in particular.. that was a new addition and still stabilizing.. anholt_ filed a couple issues about things to work on there..
16:36 ashafer: Hi all, does anyone know why display planes in vulkan don't support alpha blending?
16:36 ashafer: wsi_get_display_plane_capabilities in src/vulkan/wsi/wsi_common_display.c
16:37 ashafer: it always sets the supported_alpha to VK_DISPLAY_PLANE_ALPHA_OPAQUE_BIT_KHR
17:04 anholt_: jekstrand: I merged skips for 2/3 the a530 spurious fail yesterday, but the remaining set I had seen is going to take a bit more work (detecting instaboots and restarting the job up to n times)
17:05 anholt_: the two I had seen were in gles3, so we might be able to just turn that off until I can fix it, but I need to collect a bit more data (I get marge-generated and post-merge spurious fails in my inbox, and I go through them every morning)
17:05 anholt_: but also once !4229 is in you'll see fewer freedreno jobs.
17:23 jekstrand: anholt_: cool
17:23 anholt_: jekstrand: did you see specific tests fail on a530? looks like I didn't get any new ones since my merge yesterday
17:23 anholt_: or was it instaboots?
17:23 anholt_: (bootloader text pops up at the end while tests were running)
17:23 jekstrand: anholt_: I don't pay atttention to why it failed. I just push the retry button.
17:31 xexaxo1: ajax: double-checked usespace for s/EINVAL/EBUSY/ -> nobody seems to care. patch is in your inbox
17:36 ajax: xexaxo1: awesome
18:56 anholt_: jekstrand: well, put up an MR to disable gles3 db820c so hopefully the other new source of flake goes away
19:48 airlied: tpreston: sound like you want a driver like etnaviv or panfrost
19:48 airlied: which have no display at all
19:48 airlied: not sure why people misread what you said and started talking about displays :-P
19:49 airlied: tpreston: and no you cna't upstream the current driver
19:50 airlied: we generally don't accept gpu drivers into staging, esp vendor ones
19:51 airlied: talk to panfrost, etnaviv or freedreno ppl about best strategies
20:22 anarsoul: airlied: I guess right answer is "try to do things right from the very beginning" but looks like it's a little too late
20:26 airlied: anarsoul: yeah it's hard to for companies to get the first time :-P