09:12pq: vsyrjala, imirkin, I did not mean displaying, but on EGL GBM platform and GL ES 3, I don't get GL_EXT_color_buffer_half_float with HSW. I do get it on AMD Polaris11.
09:21tzimmermann: mlankhorst_, could you cherry-pick cdea72518a2b38207146e92e1c9e2fac15975679 into drm-misc-fixes after -rc1 ?
09:23pq: OTOH, it's convenient that by picking the GPU, I can test the failure path too :-p
09:27emersion: so are you buying hardware because it's missing features now? :P
09:32pq: no, I bought the AMD card because... because...
09:32pq: oh, right
09:32pq: beign able to test weston/DRM without switching away from my dev desktop
09:33emersion: oh. on the same machine?
09:33emersion: physical seats?
09:34emersion:has not enough room for two GPUs :(
09:34pq: mvlad documented it: https://wayland.pages.freedesktop.org/weston/toc/running-weston.html#running-weston-on-a-different-seat-on-a-stand-alone-back-end
09:34emersion: … at least not without a terrible jumper cable
09:35pq: I suppose this will also come handy when Weston grows support for multiple DRM devices.
09:35emersion: would setting XDG_SEAT work as well?
09:35pq: the card I mean
09:36emersion: yeah, that's my primary use-case: test wlroots multi-GPU support
09:36pq: dunno, haven't tried XDG_SEAT
09:37pq: looks like weston looks at XDG_SEAT at least
09:38pq: unfortunately running weston on another seat like this cannot use logind, hence need to circumvent all security measures for that phys seat
09:38emersion: yeah, i was wondering if the --seat arg was really necessary
09:40emersion: hm. where does it refuse to use a different seat? inside logind itself?
09:40emersion: i've tried multi-seat on wlroots a very long time ago, so i really don't remember how this all works
09:40pq: yeah, logind has no concept for a unprivileged user taking over an "unused" physical seat.
09:40emersion: ah, right
09:40pq: "unprivileged" being the point
09:41pq: or maybe already being in a session was a problem too
09:44emersion: isn't the "insecure" seat laso unused?
09:45emersion: hm, right, sessions…
09:45emersion: oh well
09:45pq: it is
09:46pq: I discussed this on the systemd-devel@ list and came to the conclusion that this is the best I can do - without logind.
09:46emersion: i see
09:46pq: it's a niche feature for developers anyway, so not worth a huge effort
09:47pq: or, any further effort
09:50emersion: the proposal to be able to use KMS leases would be nice for testing as well, but as always the devil is in the details
09:53mlankhorst_: tzimmermann: put it in drm-misc-next-fixes?
11:41vsyrjala: pq: hmm. looks like maybe that's only hooked up for gallium for whatever reason
11:43pq: aha, I can file a proper bug for it
12:28tzimmermann: mlankhorst_, whatever makes it first into upstream
12:29tzimmermann: see https://lore.kernel.org/dri-devel/YDeAnaM8GSInqCkv@phenom.ffwll.local/
13:05edman007: Hey, so I'm trying to do ffmpeg transcoding with VA-API, and I'm experiencing this bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1235 and this is the backtrace of where it's being slow: https://pastebin.com/gsWm21Kf
13:05edman007: and some background, if I run 'vblank_mode=1 glxgears' while doing this it runs about 20-30x faster
13:07edman007: anyways, I have zero experience with the mesa source, is '*_wait_idle()' right here? And what does vblank_mode=0 do on glxgears that the vaapi libs are not doing?
13:08edman007: also, passing vblank_mode=0 to ffmpeg does nothing
13:58mlankhorst_: tzimmermann: drm-misc-next-fixes is fine, can push there. :)
13:58tzimmermann: mlankhorst_, ok, i'll add it now. thanks
14:00danvet: emersion, btw reason for all that protocol and compositor doing the problem: even with a read-only lease you hand out something fairly disruptive
14:01danvet: doing a forced probe takes a long time due to edid reads
14:01danvet: and iirc hogs some modeset locks still
14:01danvet: so can hold up the main compositor even
14:01danvet: mlankhorst_, I also have a compat ioctl fix for -next-fixes
14:01emersion: the fact that the kernel allows forcing probes for non-master, i consider a kernel bug
14:01danvet: lease is master together with the lessor
14:02danvet: but yeah there's a ton of stuff we allow that probably shouldn't
14:02danvet: e.g. vblank queries and fun stuff like that
14:02emersion: not even in the lease case, just in the non-master DRM FD case
14:02danvet: I think if you queue up enough queries you can DoS the compositor, since there's no query slots left or so
14:03danvet: but I haven't tried, just crossed my mind
14:04tzimmermann: mlankhorst_, done
14:08emersion: interesting trick danvet, re: empty DRM lease to workaround GEM handles
14:08emersion: didn't think about that
14:12danvet: tzimmermann, you tuned down the FIXME a lot, plus left in the kerneldoc
14:12danvet: I would have preferred a stern "don't think about using this" as the only kerneldoc
14:12danvet: but alas this bikeshed is too silly anyway
14:13tzimmermann: danvet, there'll be a v6 anyway
14:13danvet: (hence only FIXME that explains the problem in detail and not anything else that makes it sound like this is a legit functionality - it's not)
14:13danvet: also I hope I didn't derail the patch with my note about device refcounting and dma_buf_attach
14:14danvet: just realized that we have another hotunplug issue there potentially
14:14tzimmermann: danvet, wasn't that a problem anyway? the original device had the dmamask copied from the sysdev
14:15tzimmermann: if that goes away, the dmamask is bogus
14:15danvet: well I have no idea how bad dma_unmap_sg goes boom when the struct device is gone :-)
14:15tzimmermann: what we could do is to hold the reference to sysdev in each driver from start to finish
14:15danvet: vsyrjala, fbdev is in drm-misc, for that patch I've seen flying around with you on cc: pls just push
14:16vsyrjala: you mean the one that obviously wrong?
14:16danvet: tzimmermann, yeah but that feels like throwing more good time after a bad hack
14:16danvet: imo go with the smallest hack that greg deems acceptable
14:16tzimmermann: he seemed happy with this
14:16danvet: vsyrjala, well maybe next version :-)
14:17tzimmermann: if we store sysdev in the driver, we'd do away with the shared prime helper
14:17tzimmermann: each driver, udl, gm12u320 (plus maybe gud), would get their copy
14:18tzimmermann: wasn't that what you proposed anyway?
14:18danvet: ofc silly me applied the bugfix to -next
14:18danvet: mlankhorst_, ^^ I guess another cherry-pick, sorry about that
14:21tzimmermann: danvet, oh those paragraphs were literally the FIXME. now i got it
14:22tzimmermann: if we put this FIXME into the drivers, no one is ever going to look at it. i'd rather put it into the todo item
14:24danvet: tzimmermann, todo.rst is fine
14:24danvet: and yeah that's why I put it into a <doc> </doc> block, I guess that wasn't clear
14:26danvet: tzimmermann, maybe just do a todo.rst patch, this bikeshed has already achieved galactic proportions for a regression fix :-/
14:26tzimmermann: danvet, i'll send out something on monday
14:36neobrain[m]: What are the semantics for NIR's u2f16 when converting from a large input integer? Does it saturate to +-infinity or is the result undefined in that case?
15:28imirkin: pq: that's probably just not hooked up in i965. should be easy for anyone who cares
15:36vsyrjala: i wonder if something higher up could just enable it always when the ARB equivalent is supported
15:36imirkin: vsyrjala: the ARB equivalent requires fp32 as well
15:37imirkin: so the enable has to be different
15:37imirkin: i965 explicitly sets these, so should be easy to just flip the flag on imo
15:37vsyrjala: sure, but if the ARB is a superset then enabling the gles ext should safe
15:37imirkin: yea, but we have no way to manage that
15:38vsyrjala: i thought it was already done for some exts
15:38imirkin: some exts use the same enables
15:38imirkin: but here the enables must be different
15:38imirkin: also in st/mesa, there's various logic around enabling this if that is enabled, etc
15:38imirkin: but i965 is separate from that
15:39vsyrjala: i have vague memories of seeing code to enable slightly different gles exts based on the some gl ext
15:39vsyrjala: but maybe that's just my memory playing tricks
15:39imirkin: i definitely did stuff like that instead of adding new enables
15:39imirkin: where there was no practical reason to add new enables even though they were slightly different
15:40imirkin: but here, i believe there is hw which can do fp16 but not fp32 rendering
15:40imirkin: (iirc blending is required as part of the ext?)
15:44vsyrjala: hmm. now i wonder if also saw this issue when i was doing the weston hdr thing
15:45vsyrjala: ah, no it was some other 16bpc thing. something_something_norm16 i think was a related ext that was missing
15:57imirkin: vsyrjala: EXT_texture_norm16?
15:58imirkin: anyways, if the hw supports this stuff (which hsw+ certainly does), it's just a matter of flipping the enable in intel_extensions.c
15:59ajax: st_extensions' mapping from format support to extn is... not quite correct
15:59imirkin: ajax: it's pretty correct ... what'd you have in mind?
15:59imirkin: it's not 100% accurate for arbitrarily weird drivers
15:59imirkin: but for drivers which report a logical set of formats, it's fine
16:00ajax: mostly the above bits about which float extns map to which combinations of texture or render support
16:00imirkin: mmmm ... should be accurate. can you point to a specific example?
16:00ajax: not immediately, no
16:00ajax: i'm just remembering that we were _just_ here, about some other float extn in gles
16:01ajax: and kusma (i think) and i spent some time spec lawyering about it
16:01imirkin: about texture filtering i think?
16:01imirkin: which isn't well-reported by the gallium api's
16:01imirkin: i.e. whether linear filtering is supported on this or that format
16:01ajax: yeah, possibly
16:01imirkin: so st/mesa has to do some guessing
16:02ajax: anyway it's something i keep meaning to revisit because i don't trust it. maybe i'm just wrong and should trust it ;)
16:02imirkin: it's definitely slightly incomplete. if you report a random assortment of formats as supported, you'll end up getting some exts that you shouldn't.
16:03kusma: I think the biggest issue is that nobody bothered making some enabling exts that doesn't also pull in functionality that not all hw supports...
16:03imirkin: when adding various ES exts, i erred on the side of not adding 100 new enables to worry about
16:03imirkin: figuring that when such hw came along where it mattered, the ones that needed to would get split up
16:04kusma: I'm not aware of anything obviously wrong with the code, just that we don't have the extensions needed to expose everything in all apis...
16:04imirkin: i can believe that
16:21robclark: jekstrand, Kayden: btw since we don't have intel in gitlab CI, not sure if you want to give https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9266 a quick sanity test? If you did previously have an use of util_cpu_caps before util_cpu_detect() is called, it now becomes an assert in debug builds.. probably doesn't need a full CI run, I think if there were an issue you'd hit it pretty fast
16:22zmike: oh hey I hit that exact case somewhat recently
16:49kevintang: Hi danvet, do you have more comments about my patch v4?
16:50danvet: sry I'm entirely out of the loop on driver patch review
16:51danvet: maybe ping me next week
17:22danvet: kevintang, your dropping fairly often
17:22danvet: <danvet> sry I'm entirely out of the loop on driver patch review
17:22danvet: <danvet> maybe ping me next week
17:26kevintang: Sorry, i login irc with my phone, there seems to be a problem with the network before, but now is well.
17:30kevintang: danvet, i will ping you next week, thks.
17:32emersion: danvet: how bad of an idea would it be to demote drmModeGetConnector to drmModeGetConnectorCurrent in the kernel if the client isn't DRM master?
17:33danvet: I guess should be ok
17:33danvet: if there's no races on vt switch
17:33danvet: like not sure what compositors do there, or whether they just don't bother probing at all
17:34emersion: my compositor does a full re-probe on VT switch
17:34danvet: yeah but after or before it gets master?
17:34emersion: just like when it's handling a hotplug event
17:34emersion: hm, after the session is resumed
17:35emersion: but it's all abstracted by logind/seatd, so i don't remember what causes that
17:36emersion: yeah, so it does that after setting DRM master
17:37emersion: ie, after the drmSetMaster call
18:23Kayden: robclark: will give it a test, thanks!
18:27Kayden: robclark: well, glxgears and vkcube run without asserts, so I think we're good
18:28Kayden: oh, does this affect i965 too?
18:28Kayden: seems fine there as well
18:28robclark: ok, cool
18:28Kayden: right, i965 uses the *other* cpu detection code in mesa
18:28robclark: heh, we have two?
18:29Kayden: because we still have the gallium version and some older version
18:29Kayden: iris just assumes your CPU has features, hehe
18:29robclark: u_cpu_detect is src/util now.. but maybe it was in gallium at one point
20:13anholt: doing a bit of work on the freedreno fastboot (db410c, db820c) configuration, I'm trying to avoid killing things when people's jobs are running but can't guarantee it.
20:13anholt: (so feel extra encouraged to just smash retry on freedreno today)
20:23austriancoder: robclark: shader-db with drm-shim: ../src/util/u_cpu_detect.h:116: util_get_cpu_caps: Assertion `util_cpu_caps.nr_cpus >= 1' failed.
20:25robclark: austriancoder: ok, you need an extra util_cpu_detect() call somewhere
20:26robclark: it recently (today) started asserting that util_cpu_detect() was already called before you try to use cpu caps
20:26robclark: so I guess it caught it's first bug
20:30austriancoder: robclark: here is the bt: https://dpaste.org/vtrG .. I need to have a look at your merged MR
20:32robclark: austriancoder: probably the easy thing is move util_cpu_detect() from st_create_context() to st_api_create_context().. or call it in your driver
20:33robclark: austriancoder: the MR basically just made things assert if cpu caps are used before they are initialized.. to try and catch previously undefined behavior
20:35robclark: I suppose we should actually just move util_cpu_detect() up to before pipe_screen creation.. I guess that would catch most of the potential bugs
20:41Kayden: that seems like a reasonable plan
20:41Kayden: I remember seeing helgrind complain about some potential threading issues with util_cpu_detect not being called in time
20:44robclark: tbh, helgrind complains about a *lot* of things
20:50austriancoder: robclark: would be pipe_loader_create_screen(..) a good candidate to move the util_cpu_detect() to?
20:50robclark: yeah, I think so
20:51robclark: hmm, are there any non pipe_loader paths to creating a screen (clover, windows, etc)?
20:51jenatali: Windows doesn't use it
20:52robclark: ok.. so maybe safer to just add a util_cpu_detect() in pipe_loader_create_screen() but not remove the existing one
20:52robclark: it doesn't really hurt to call util_cpu_detect() multiple times (as long as it isn't critical-path stuff)
20:54austriancoder: robclark: k
21:10austriancoder: robclark: !9311
21:11robclark: thx, r-b
23:02robclark: mareko: hmm, tc seems to be walking past the end of the batch:
23:03robclark: p->resource==0x3333 comes from a line I added to poison the resource pointer at the end of tc_call_texture_subdata()
23:03robclark: first column is the 'p' pointer address
23:15robclark: mareko: I don't suppose you've tried u_threaded_context on power/arm (or anything with a more relaxed memory model than x86)?
23:18mareko: robclark: no
23:19mareko: robclark: are you implying that you need a memory barrier?
23:20robclark: it looks that way, looks like i is seeing the wrong 'last' in tc_batch_execute()
23:20robclark: I think we need some smp_load_acquire()/smp_store_release().. whatever the userspace equiv of that is
23:21mareko: p_atomic_read, p_atomic_set
23:21robclark: ok.. let me try that..
23:42jenatali: Is there a stock behavior that should happen if an app tries to read from a UBO that doesn't have a buffer bound?
23:43jenatali: Looks like the spec says undefined, but I'm still not an expert at GL terminology or reading GL specs...
23:48imirkin: jenatali: with robust contexts you're supposed to return 0
23:48imirkin: with non-robust contexts ... not 100% sure, will have to rtfs
23:48jenatali: imirkin: Hm... robust contexts... that's something to check into
23:48imirkin: basically the idea of robust contexts is to remove as much undefined behavior as reasonable
23:49imirkin: so you can read/write images / buffers out of bounds, etc
23:49imirkin: and program termination is not a reasonable way to handle that anymore :)
23:49jenatali: Looks like the spec says undefined: " When executing shaders that access uniform blocks, the binding point corresponding to each active uniform block must be populated... If any active uniform block is not backed by a sufficiently large buffer object, the results of shader execution are undefined..."
23:50jenatali: Yeah that makes a lot of sense, I more just meant I needed to see if we even claim it (can we not claim it?) or if this crashing app is trying to use it
23:50imirkin: jenatali: from ARB_uniform_buffer_object: https://paste.debian.net/plain/1187135
23:51jenatali: Yeah that's what I just found, thanks :)
23:51imirkin: the key being "may result in GL interruption or termination"
23:51imirkin: they don't mention termination of what ... life on earth? who knows
23:52imirkin: i think later GL specs may have gotten rid of the "termination" option
23:52imirkin: apparently people decided that exiting the program when there's a shader bug is undesirable
23:53jenatali: Yeah, seems reasonable. That's where I'm currently at :P
23:53jenatali: Looks like we don't claim the robustness extension, but D3D has robustness support in general, we're just missing a null check to take advantage of it
23:54imirkin: otoh, ARB_robustness says https://paste.debian.net/plain/1187136
23:54imirkin: but not all contexts are necessarily robust -- you have to pass in a flag to request robustness
23:54imirkin: GLX_ARB_create_context_robustness / WGL_ARB_create_context_robustness / EGL_something
23:56jenatali: Yeah, I'd seen that. Something tells me we're going to end up with a mostly-robust implementation running all the time, because apps are dumb
23:57imirkin: yeah, i don't know about the api level, but most of this stuff is "free" on nvidia gpu's
23:57imirkin: i.e. you can't NOT have it be robust, except for in-shader image/buffer read/write
23:57jenatali: Yeah D3D's got a lot of built-in robustness guarantees, you just have to set the right parameters to take advantage of them
23:57imirkin: where we throw in some additional bounds checks "by hand"
23:58jenatali: I.e. make sure you explicitly bind null instead of leaving pointers to freed memory