00:02 krh: jekstrand: did you play with atomics again?
00:17 mareko: Kayden: the top priority for me is to add full GL compatibility support to glthread, which is mainly user vertex arrays and immediate mode
00:19 mareko: and fp16/i16 and gfx preemption on the radeonsi side
00:20 Kayden: makes sense
00:22 mareko: on the st/mesa side, saving sampler CSOs in gl_texture_object/gl_sampler_object would reduce some overhead there, currently it does full translation every time
00:23 airlied: oh man tess control shaders will need coroutines as well, thanks barrier
00:26 imirkin_: airlied: fwiw, barrier in TCS can only be at the outer level
00:26 imirkin_: so it's actually a lot less flexible than the compute one
00:26 imirkin_: i.e. it can only be at the "outer" level of main, not inside any control flow.
00:48 airlied: imirkin_: I think that still might require coroutines
01:07 imirkin: airlied: oh well
06:11 airlied: okay got a basic tes shader running and using the tessellator tor code in llvmpipe, two piglits down :-P
06:27 imirkin: something i've been playing with ... not sure if i'm going to make it useful: https://people.freedesktop.org/~imirkin/edid-decode/test.html
06:28 imirkin: the input data is hard-coded, but it's running the real edid-decode code
09:27 daniels: robclark, anholt_: a630 xfb flake (not detected) plus one detected flake https://gitlab.freedesktop.org/frohlich/mesa/-/jobs/1563565
09:28 pepp: getting 503 errors on gitlab
09:29 MrCooper: it's being upgraded
09:29 pepp: ok
09:30 MrCooper: as announced on #freedesktop :)
09:30 pepp: MrCooper: yeah, I should have check there first :)
09:33 MrCooper: it's back
16:05 bnieuwenhuizen: Daniels: as an aside from https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3724 how does one figure out what modifiers a gbm device supports?
16:05 gitbot: Mesa issue (Merge request) 3724 in mesa "Nouveau improve format modifiers" [Gallium, Nouveau, Opened]
16:09 daniels: bnieuwenhuizen: don't think we ever exposed that entrypoint directly as such. but you know IN_MODIFIERS from KMS (that's the list you're supposed to pass), and you can intersect with the result from eglQueryDmaBufModifiers if you need to know
16:10 daniels: but unlike Vulkan, passing unsupported modifiers in the list you give to create_surface_with_modifiers is explicitly allowed, and the implementation must filter for supported, rejecting if none are suitable
16:11 bnieuwenhuizen: So basically gbm always has to support what egl exposes and you can only figure that out though egl?
16:15 daniels: well, I mean, GBM isn't useful unless you're doing software mappings which are defined to be linear, or you're using it with a client API in which case you need to query the client API?
16:18 daniels: if you want to know which modifiers the display controller supports, query KMS for that - it can be disjoint between planes so you need the per-plane information rather than a global query
16:19 daniels: and if you want to use EGL or Vulkan to render, then you need to find out what they support for that target anyway
16:19 bnieuwenhuizen: Yeah just always had this idea that GBM was its own allocator with own modifiers and then you import into a client (KMS, EGL, or vulkan) and check what it supports
16:20 bnieuwenhuizen: Instead of it being tightly coupled to EGL
16:21 daniels: right, but if GBM declares that it 'supports' DCC, then you try to import that into Vulkan which doesn't have DCC ... what happens?
16:22 bnieuwenhuizen: Rejection
16:22 bnieuwenhuizen: On the vulkan side
16:23 daniels: right, if you're just doing that kind of brute-force, might as well walk every modifier in the list that KMS gives you
16:23 bnieuwenhuizen: Well if you'd intersect the vulkan list and the gbm list you wouldn't?
16:24 daniels: you need to start with the KMS list
16:24 daniels: which GBM doesn't have
16:25 daniels: again they can be disjoint between planes, and often are
16:25 bnieuwenhuizen: You don't need to if you don't want display?
16:25 daniels: if you don't want display, why are you using GBM?
16:25 bnieuwenhuizen: Cross-API allocator with use flags?
16:26 daniels: noooooooooooo
16:27 bnieuwenhuizen: Hence my entire line of questioning being around the EGL link
16:27 daniels: GBM isn't gralloc - it's a bridge between KMS and client APIs like EGL/Vulkan
16:27 daniels: (as well as a helper for generic KMS clients to allocate buffers they can use for hardware cursors)
16:27 daniels: if that's not what you're doing, don't use GBM
16:27 bnieuwenhuizen: So the fun part: what if kernel has modifiers but gbm does not support modifiers at all?
16:28 bnieuwenhuizen: Say new kernel + old userspace
16:28 daniels: gbm_surface_create_with_modifiers() fails and you fall back to gbm_surface_create() with no modifiers
16:28 bnieuwenhuizen: Okay
16:28 daniels: and you don't try to pass a modifier to KMS because you don't have one
16:29 daniels: (this is the case with e.g. i915)
16:50 daniels: imirkin: https://gitlab.com/gitlab-org/gitlab/issues/201454
16:50 gitbot: GitLab.org issue 201454 in gitlab "First-class experience from the command line" [Direction, Feature, Moonshots, Opened]
16:51 vsyrjala: drm-misc-fixes is behind the times. i wanted to push https://patchwork.freedesktop.org/patch/351781/?series=72941&rev=1 and i thought drm-misc-fixes is the right choice at this point in time?
16:51 vsyrjala: mripard: ^
16:51 vsyrjala: hmm, mlankhorst seems awol
16:53 vsyrjala: tzimmermann: you too now i guess ^
17:10 seanpaul: vsyrjala: -misc-next-fixes is the place to push until rc1 is cut
17:12 vsyrjala:always confused with drm-misc
17:13 vsyrjala: thanks. i'll push there then
17:58 karolherbst: mhh. I had to restart the a630 gles3 runner twice today :/
17:59 karolherbst: I mean.. the test runs
19:05 anholt_: karolherbst: new commit in !3662 for that
20:42 inolen: hey all, i've been hacking on SDL's KMS / GBM / EGL driver the past few nights and i've hit an issue that i believe is unrelated to my API usage, but wanted to get a second opinion. in short, i'm doing doing the draw / wait for flip / release bo / swap buffers / lock front / queue flip dance, and at first i thought i was getting tearing, but after sprinkling around a few glFinish's I got this result:
20:42 inolen: https://i.imgur.com/ftmck6b.jpg . in that scene, the game is rendered to an fbo, the fbo is blitted to the back buffer and the ui is then drawn on top. from the looks of it, it seems that the buffer is possibly getting scanned out before the ui drawing is complete. i added a few paranoid asserts (e.g. ensuring the back buffer != current inside of get_back_bo) but nothing came up so I was curious if anyone
20:42 inolen: here had any thoughts
20:54 anholt_: inolen: you aren't doing anything with explicit fences, are you?
20:59 inolen: anholt_: we have one mode where we do (secondary thread that acts as a mailbox of framebuffers) but i've disabled that so there's only one context while testing now
21:03 anholt_: if you're getting partial frames displayed, my guesses in order would be 1) explicit fences busted either on your app's end or the driver's 2) app releasing a bo back to the gbm queue before kms has reported a flip completion away from it 3) kms driver's implicit fencing not actually waiting for the rendering
21:16 inolen: anholt_: cheers. i think 1 is ruled out because it works on glx (and i've definitely disabled everything), but i'll triple check 2 tonight
21:21 imirkin_: anholt_: i wonder if the point of u_tile having a temp buffer is that "dst" was meant to be a vram-backed thing or other slow memory. probably not used that way anymore.
21:24 inolen: anholt_: regarding 3, are there any debug environment variables or some such for aggressively synchronizing that'd be useful for debugging in this case?
21:40 anholt_: imirkin_: if our format pack is doing RMW on its destinations, then we should just fix that anyway.
21:40 Lyude: mripard: poke, any chance you or mlankhorst saw my message about getting a merge in drm-misc-next-fixes with misc-fixes?
21:41 imirkin_: anholt_: i guess i don't even know if a memcpy would work out better than a bunch of small writes with "spare" cpu cycles in the middle.
21:41 imirkin_: due to the latency of those writes, depending on how cpu execution works, it may actually be beneficial to write a little at a time
21:43 anholt_: imirkin_: avoiding memcpy is probably a win actually since some impls go backwards and that often breaks the WC buffers on lower-end CPUs.
21:43 imirkin_: ouch, yeah
21:45 anholt_: oh wow. i586 glibc reads from the dst as it memcpys to try to pull the dst into the cache since the CPU wouldn't do that for you. way to go glibc!
21:46 imirkin_: kinda funny to think back on what sorts of optimizations one did for 386, 486, p1, etc
21:46 imirkin_: worrying about U/V pipes