00:03milek7: imirkin: what do you mean by that it doesn't do anything? it usually writes gl errors to stderr
00:04imirkin: oh hm. i thought that was just enabled on debug builds
00:49marex: ah ... I thought I finally got it all working, but it was only mesa pulling some other shader from the cache
00:57anholt: mareko: I did a skim of the atomics reduction series and it looks pretty great. do you need more reviewers at this point?
01:11anholt: robclark: I think once !8298 lands, it'll be time to revisit !4971
01:16robclark: anholt: well, webgl aquarium is a pretty good benchmark for !4971 .. I'd be pretty happy if we can get to a point where indirect uploads for uniform state doesn't hurt (since I guess we'll need that regardless for threaded-context)
01:26mareko: anholt: yes please
01:36bl4ckb0ne: is there a way to clear the current egl context? I saw from the doc that calling eglMakeCurrent with EGL_NO_DISPLAY is not valid
01:45HdkR: eglMakeCurrent(<current dpy>, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
01:49bl4ckb0ne: EGLGetCurrentDisplay will do, thanks HdkR
01:50bl4ckb0ne: would a patch to accept EGL_NO_DISPLAY be accepted?
01:52marex: imirkin: that sprite_coord_enable, it is only seldom set when running e.g. neverball
01:53marex: imirkin: so I have this patch https://gitlab.freedesktop.org/marex/mesa/-/commit/2a47cc2d8faf57bc33af0c342b8fa25941054f85 , which makes neverball work
01:53marex: but when I only run the lowering pass if sprite_coord_enable bitfield is !0, then neverball point sprites are corrupted again
01:53HdkR: bl4ckb0ne: Doubt. That would be against spec. With surfaceless you can just create a surfaceless dpy
01:53imirkin: marex: is it in the shader key?
01:54imirkin: marex: the same shader might be used both with pcoord replace and without
01:54imirkin: marex: also only replace the varyings specified in the bitmask
01:54imirkin: check other drivers how to go from varying slot to bit position
01:55imirkin: iirc tex0 == bit 0, tex 1 == bit 1, etc
01:55marex: imirkin: I added 16bits of it into the shader key, yes
01:55marex: imirkin: all right, in that case, I will continue in a few days once I digested it all
01:56marex: I think I'm getting some understanding of it, but it's still very incomplete
01:56imirkin: yeah, this stuff takes a bit to wrap one's head around it
01:57marex: imirkin: jekstrand: thanks for your patience and explanation, that really did help
01:57marex: more than the docs and digging through code, by far
01:57bl4ckb0ne: HdkR: i think its not specified in the spec but i see your point
01:58HdkR: bl4ckb0ne: `As with other commands taking EGLDisplay parameters, if dpy is not a valid EGLDisplay handle, an EGL_BAD_DISPLAY error is generated` Right from EGL spec 1.5
02:04bl4ckb0ne: HdkR: ty, fixed my issue
02:54jenatali: Is there a list of places where the draw module is used? I'm curious on the tradeoff between size/speed for including LLVM in our GL driver, considering that on Windows we wouldn't be using a system shared LLVM
02:56airlied: jenatali: it's used in GL for old feedback modes
02:56jenatali: Ah, I think I saw that in my searches but didn't look close enough
02:59jenatali: Yeah... it's apparently like 30MB per architecture to include LLVM in the GL driver just for that. I think I'm going to see about adding an option to build with LLVM, since we want it for our CL compiler, but not including LLVM in the draw module - or else I guess we could build those components separately, but an option seems simpler
03:00airlied: jenatali: it should fallback to the non-llvm draw paths
03:00jenatali: airlied: Yeah, building just the GL driver without LLVM works fine. But building GL + CL at once automatically includes LLVM into the GL driver, which bloats it
03:01airlied: also glRasterPos
03:01jenatali: Yeah that one I found
03:02airlied: do you build from separate trees?
03:02jenatali: No, right now we build them both together
03:02airlied: that might be tricky to untangle then
03:02jenatali: I'll see how bad it is - if it's not too bad I'll send an MR, if it's ugly I'll just build them separately on our side
03:02airlied: I suppose your CL drivers as-is doesn't use much gallium
03:03jenatali: Yeah we just need the Clang/LLVM frontend to get SPIR-V, from there it's just the NIR bits that're used
04:16marex: jekstrand: imirkin: https://gitlab.freedesktop.org/marex/mesa/-/commit/2a47cc2d8faf57bc33af0c342b8fa25941054f85 so I think I figured out the NIR part, but TGSI still eludes me
04:16marex: thats for later though
04:18marex: correction , this https://gitlab.freedesktop.org/marex/mesa/-/commit/ad0ebd8f3299cab9d8612a19d8a6fc92865e3f88
09:22emersion: daniels: gbm question: what should be the fallback when gbm_bo_get_plane_fd isn't available?
09:22emersion: daniels: does this sounds the least bad possible thing to do? https://github.com/swaywm/wlroots/pull/2672
09:23emersion: would i be able to check that each plane has the same handle?
09:23emersion: (and fail if that isn't the case)
09:27daniels: emersion: yeah, I think that makes sense: always call per-plane FD when available, if not available call get_handle and fail if it's different between any planes, then call get_fd
09:27daniels: (my god what a pain)
09:27emersion: yeah :S
11:12danvet: emersion, maybe I wasn't clear, aside from the "must use" we should also explain when and what to consider maybe?
11:12emersion: hm, what do you mean?
11:13danvet: essentially if you have your fd from someone else, or shared with someone else like gbm
11:14danvet: you must use that thing for importing
11:14emersion: yeah, ok
11:14emersion: makes sense
11:15danvet: I'll add comments
11:16kusma: ccr: That sounds an awful lot like what's mentioned here, perhaps you could file a ticket? https://gitlab.freedesktop.org/mesa/mesa/-/issues/3661#note_671465
11:18kusma: ccr: I *assume* it's PIPE_SHADER_CAP_INDIRECT_CONST_ADDR that somehow triggers it, probably in combination with missing PIPE_CAP_PACKED_UNIFORMS if I understand zmike's comment right.
11:20ccr: kusma, https://gitlab.freedesktop.org/mesa/mesa/-/issues/4132 :)
11:21ccr: funny, 3661 is my ticket and while I've read the comments that one about the assert hadn't registered in my brain
11:32emersion: danvet: so if a process sends a DRM FD to another process, and then both use GBM on it, things will go boom because the two GBMs won't be able to know the ref'count of the other instance?
11:44kusma: ccr: awesome, thanks :)
11:45kusma: ccr: doh, I should have realized that was you :)
11:45danvet: emersion, yeah if those two gbm share the same drmfd
11:45danvet: they both get the same gem_id back
11:45danvet: but neither has that gem_id in its lookup table
11:45danvet: and also no shared refcount
11:46danvet: so if the last refcount drops on the first gem_bo it'll do a GEM_CLOSE
11:46danvet: and now the handle the 2nd gbm thought it has has become invalid
11:46danvet: or eventually will have some other buffer
11:54MrCooper: aka "don't use the same DRM file description in multiple processes"
11:55pq: It's like no-one ever imagined that one day people could be passing device FDs from one process to another, even though the mechanism for that has existed much longer.
11:56imirkin: the real problem is that GEM's aren't refcounted
11:57imirkin: adding refcounting on them would solve all these problems instantly afaik
11:57MrCooper: time to dust off that time machine
11:57pq: don't drivers (in userspace?) rely on being able to de-duplicate bos?
11:58ccr:hums the BTTF theme
12:01imirkin: MrCooper: well, could easily add a GEM_OPEN_REFCOUNT / GEM_CLOSE_REFCOUNT
12:01imirkin: i guess i haven't thought it through
12:01imirkin: but it all seems achievable
12:14danvet: imirkin, userspace would still need to de-dupe to not upset command submission and other things
12:14danvet: so seemed silly to refcount both in userspace and in the kernel
12:14danvet: and now it's locked in and needs a time machine
12:15danvet: MrCooper, even same process, iirc cros' ozone does the same trick and then gets pissed about the fallout
12:15danvet: or at least was
12:18imirkin: danvet: and we can't add some new ioctl's for new userspace to make use of?
12:20danvet: could add a flag I guess
12:21danvet: but it doesn't help you much, since you still need to support current kernels
12:21danvet: and so no one bothers
12:22emersion: but let's sayu someone bothers
12:22emersion: would it still be possible? pq's question sounds relevant
12:22danvet: well kernel patch + igt + userspace, all revieweed
12:22danvet: usually thing
12:22danvet: we'd need to refcount gem_handles per fd
12:22emersion: do driver rely on the kernel guarantee?
12:23danvet: so you can only opt-in break it by userspace that hopefully knows what it's doing
12:23danvet: hence the flag
12:23imirkin: or just add different calls for open/close
12:23emersion: ah, i guess keeping the guarantee and adding a ref'count would be enough
12:23danvet: you might need to also opt-in gbm
12:23danvet: or it falls apart
12:23imirkin: (or maybe just like add a refcnt call which does +/-1, and closes when it hits 0)
12:24danvet: there's a reasons gbm has locks over this
12:24pq: I mean, didn't driver command submission ioctls get upset if userspace submitted the same bo multiple times (even if different handles)?
12:24imirkin: yeah, the +1 -1 case simultaneously is quite annoying
12:24danvet: pq, yup, that's why we have it
12:24pq: ..in the same ioctl
12:24imirkin: pq: nouveau driver does
12:25danvet: so we'd still need the de-dupe within a given gbm instance
12:25imirkin: not sure if it's more global than that
12:25danvet: but e.g. the compositor (for kms only) could have it's own thing
12:25danvet: but really at that point, open the device yourself and you have all that
12:25emersion: opening the device yourself might not work
12:25danvet: emersion, why?
12:25emersion: i've been wondering… you could in theory open the redner node and give it to GBM for allocation
12:26emersion: then keep the DRM primary node where you are DRM master to drmPrimeFDToHandle
12:26emersion: but what about dumb buffers?
12:26danvet: emersion, it's not per-node
12:26danvet: it's per open
12:26danvet: gem_id is local to your fd
12:26emersion: you'd need to be able to open the primary node
12:26emersion: well, sure
12:26danvet: well if you're a compositor, and you can't do that
12:26emersion: what i'm worried about is
12:26danvet: why do you care about that drmfd?
12:27emersion: compositors get the DRM FD from logind/seatd
12:27danvet: but if we assume modern system
12:27emersion: nothign says that you can just open() it again
12:27danvet: then you can open the render node for rendering whenever you feel like
12:27emersion: open()ing the render node, i'm not too worried about
12:27danvet: and that should be enough
12:28emersion: what i'm worried about is dumb buffers
12:28emersion: these only work on the primary node
12:28danvet: not sure my patch to restrict them ever landed
12:28emersion: i get EPERM on the render node
12:28danvet: but they're just normal gem buffers
12:28danvet: emersion, with fd2handle and handle2fd?
12:28emersion: yeah. so assume i create a dumb buffer, export it to a DMA-BUF via drmPrimeHandleToFD
12:29emersion: then i want to get back my handle in a completely separate place, maybe in a different lib
12:29emersion: if i just do drmPrimeFDToHandle, things will go boom
12:29emersion: because it'll give the same handle
12:29danvet: well yeah
12:30emersion: and when both sides decide to GEM_CLOSE, rip
12:30danvet: yeah don't do that :-)
12:30danvet: but this is irrespective of dumb buffers
12:30danvet: this can happen with anything really
12:31emersion: so… i'd really like to be able to have two primary nodes, one for DRM master and KMS operations, and one for dumb buffer allocs
12:31emersion: err, twop primary FDs
12:31danvet: but if you import the same fd twice
12:31danvet: you still go boom
12:31danvet: even with the twice opened fd
12:31emersion: the KMS part can refcount on its own
12:32danvet: so why can't these two parts talk with each another?
12:32emersion: because they aren't necessarily in the same lib, for instance
12:33emersion: let's say i have lib1 which creates some DMA-BUFs, and lib2 which consumes them
12:34emersion: it just doesn't work if they share the DRM FD
12:34danvet: yeah but how did they end up with the same fd and don't talk with each another?
12:34danvet: also this is dumb buffers we're talking about
12:34emersion: and there's no reliable way for me to have two DRM primary FDs
12:35danvet: I'm not sure hiding dumb buffers behind a library interface that pretends dumb buffers with sw rendering and gl/vk rendering are the same thing is a good idea
12:35emersion: yeah, non-dumb-buffers don't have this issue because i can just open() the render node
12:35emersion: well, that's what i'm doing :S
12:35danvet: yeah I'm not sold ...
12:35emersion: why is it a bad idea?
12:36danvet: next up people take this nice library which might give you dumb buffers
12:36danvet: or real buffers
12:36emersion: it's just DMA-BUFs
12:36danvet: and just dma-buf share them all around, whether dumb or real
12:36emersion: is there an issue with that?
12:36danvet: yeah, that cat is out of the bag by accident
12:37danvet: dumb buffers were supposed to be dumb
12:37danvet: and people just love to abuse them for rendering, and buffer sharing, and everything
12:37danvet: and then complain it doesn't work
12:37danvet: sometimes at least
12:37emersion: i don't really get it
12:37danvet: worksforme is unfortunately very strong with dumb buffers
12:38imirkin: along with mapping :)
12:40emersion: i don't really want to scrap my nice API just because dumb buffers are dumb
12:40pq: emersion, dumb buffers were never guaranteed to work properly with GPUs. Dumb buffers can be mmapped to CPU and displayed on KMS, and that is it. Anything else that may work is a happy/unfortunate accident. Therefore the end user experience is far from reliable.
12:40emersion: i guess i'll just open the primary node twice and be done with it
12:41pq: emersion, I suppose you can *try* to use a dumb buffer with a GPU, but you very much need a seamless fallback for it when it fails. Though I'm sure if danvet accepts even this approach?
12:42pq: *I'm not sure
12:42emersion: wait, dumb buffers weren't designed for GPUs?
12:42emersion: but it's part of DRM
12:42pq: dumb buffers were specifically designed to be NOT used with GPUs
12:42emersion: and there's no other way to do sw rendering
12:43pq: display != GPU
12:43emersion: ah. for me GPU includes both display and render
12:43pq: when I say GPU, I mean a device capable of rendering
12:43danvet: pq, pragmatically, the cat is out of the bag, but airlied more than me has screamed about this stuff in the past
12:43emersion: i'm just talking about primary nodes here
12:43pq: emersion, it would help to drop that PC-specific thinking ;-)
12:44danvet: emersion, dumb buffers where designed for boot splash
12:44danvet: everything else is a more or less happy accident
12:44danvet: plus a looooot of worksforme
12:44pq: emersion, a primary node could be a display, render, or both. GPU=render, KMS=display.
12:44emersion: i don't expect dumb buffers to work on GPUs
12:45danvet: so e.g. on most arm socs you have to allocate a dumb buffer on ther display primary node
12:45danvet: and share that with the render device
12:45danvet: because nothing else works
12:45danvet: but it's really not all that great
12:45emersion: yeah, i don't want to do that
12:45danvet: emersion, well you have to, because nothing else will both render and scanout
12:45danvet: on some socs
12:46emersion: well i don't care about these socs :P
12:46emersion: i just want to make it so i can have a sw rendering path which submits DMA-BUFs
12:47emersion: without running into these ref'counting issues
12:47emersion: but i guess the answer to that is "add ref'counting to the kernel" now?
12:47pq: emersion, does the sw renderer also allocate the dmabufs? It probably shouldn't.
12:48emersion: i want my sw rendering path to allocate dumb buffers, turn them into DMA-BUFs, import them on KMS, then display them
12:49emersion: now that i'm thinking about it, GBM can do dumb buffers as well…
12:49emersion: so i could get the magical GBM ref'counting if i wanted to
12:49emersion: except i'm not sure GBM dumb buffers hook into the right driver ref'counting stuff
12:49pq: weston GL-renderer with Mesa software renderer works.
12:50emersion: yeah but you don't do DMA-BUFs in this codepath right?
12:50emersion: it's just GEM handles
12:50pq: mmm no
12:51pq: if dmabuf was the common interface, then you could mix up dumb buffers and GPUs
12:52emersion: i don't plan to use dumb buffers when i have a render node
12:53pq: doesn't your library have other users too?
12:54emersion: users could force it into doing that, just like they can directly do it too
12:55pq: not using an opaque structure with accessors to represent buffers, that could refuse to give a dmabuf fd if it's a dumb buffer?
12:55emersion: so yeah, i have this opaque buffer structure with accessors
12:56emersion: the only accessor is "get a DMA-BUF FD" right now
12:56pq: sure, but the difference is, does one need to jump through hoops to do the wrong thing, or is it too easy
12:56emersion: but how do i get to display the dumb buffer on the KMS side, if all i have is an opaque structure which refuses to give a DMA-BUF?
12:56pq: get_gem_id could be another
12:57emersion: yeah, except you need to be really careful about not giving a gem handle for a completely unrelated FD
12:57emersion: you need to make sure both sides use the same DRM FD
12:58pq: yup, so do that
12:58emersion: so maybe have a get_gem_handle(target_drm_fd)?
12:58pq: I suppose
12:58emersion: which checks that the local DRM FD is the same as the target?
12:59pq: same file description, yeah... but that might be a problem actually, I'm not sure how
12:59emersion: my opaque structure has ref'counting built-in so that wouldn't be an issue
13:00pq: maybe there was a new syscall or something, I remember discussing this in the past, but I forget the conclusion
13:00emersion: kcmp has KCMP_FILE apparently
13:01pq: that sounds familiar
13:01emersion: > Note that this syscall requires the kernel be compiled with CONFIG_CHECKPOINT_RESTORE set.
13:01pq: yeah, that's the one
13:02emersion: honestly… that isn't great
13:03pq: the other option is just documentation: this handle will be valid only for the device you created your sw renderer object with
13:06emersion: mesa has os_same_file_description
13:35emersion: in any case, thanks for the advice pq and danvet
13:36pq: glad it was at least entertaining ;-)
13:41danvet: mripard, ack with the typos fixed?
13:41danvet: on todo.rst
13:42mripard: danvet: yep
13:51MrCooper: danvet: same process is solvable in userspace, at least in theory; and per-fd refcount would break existing userspace which tracks GEM handles across different fds referencing the same file description
13:53derRichard: hopefully this is the right place to ask. i'm developing a drm panel driver for linux and so far i'm unable to find a way on how to set the panel orientation. calling drm_connector_init_panel_orientation_property() triggers a warning in __drm_mode_object_add(). i fear the drm panel driver is not allowed to use this function. can you please point me in the right direction?
13:55pq: derRichard, you're in the right place, but that's all I know about that. :-)
13:59danvet: derRichard, I think this isn't wired up yet
14:00danvet: or at least tricky
14:00pcercuei: derRichard, read the "rotation" DT property, it's a standard property for panels (see Documentation/devicetree/bindings/display/panel/panel-common.yaml)
14:01danvet: pcercuei, but is that wired through already to the drm prop?
14:02danvet: pcercuei, I'm not finding where the prop is added
14:03danvet: hm found it
14:03danvet: at least for panel-simple.c
14:03danvet: but that's kinda the wrong place
14:04danvet: yeah get_modes is very late, and might be too late
14:04danvet: sravn, ^^
14:04derRichard: pcercuei: i fear this works the other way around. my device needs to tell drm what the current rotation is. and not devicetree telling the driver what the expectet roation is.
14:04danvet: derRichard, so it is wired up already with the property pcercuei mentioned
14:04danvet: but it might be somewhat buggy
14:05derRichard: goal is that xrandr can tell how the panel was mounted
14:06danvet: drm_connector_set_panel_orientation <- this doesn't work for you?
14:07danvet: derRichard, also upgrade to latest kernels, preferrably development trees
14:07derRichard: hm, i don't have this function, i'm still on 5.4
14:07danvet: your function got renamed
14:07danvet: yeah that's horribly old :-)
14:07danvet: for graphics at least
14:08derRichard: well, i'm in embedded world, it's actually rather new :P
14:08derRichard: and mainline. no vendor tree. at least something ;)
14:08danvet: yeah it's getting somewhat better
14:08danvet: it's not longer 5 year old vendor tree by default
14:08danvet: but if you want to upstream, then it needs to be on upstream
14:09derRichard: of course
14:09derRichard: but the whole bsp right now works only with 5.4. i can only work in small steps
14:10danvet: hm I'm still confused why this even works in upstream
14:10danvet: derRichard, but yeah for examples of how it's done
14:10danvet: $ git grep drm_connector_set_panel_orientation
14:10danvet: in upstream
14:10danvet: 3 panel drivers using that
14:10danvet: sravn, tagr isn't drm_connector_set_panel_orientation() called from get_modes too late, i.e. after drm_dev_register?
14:10derRichard: panel-simple is super generic
14:11derRichard: let me see whether i can find all commits i need for backporting
14:12danvet: derRichard, well there's 2 others if you need something specific
14:14derRichard: hmm, in mainline drm_connector_set_panel_orientation is called in get_modes, just like in my driver on 5.4. but i do hit the warning
14:15danvet: yeah that's what I'm confused about
14:15danvet: I'd expect the upstream code to warn
14:17derRichard: at least this time it is not me being dense ;-)
14:22derRichard: panel-simple.c has the change since 5.10. maybe nobdoy really noticed so far ;-\
15:41derRichard: danvet: should i send a mail to the mailinglist or file a bug regarding the issue?
15:47danvet: derRichard, usually tagr and sravn are around here, they are herding panel stuff
15:47danvet: ask them
15:47danvet: derRichard, but yeah if you can hit a warning on upstream, that's good for a bug report somewhere
15:48derRichard: right now i don't have a 5.10 kernel with a working panel. ;-\
15:48derRichard: let's wait for tagr and sravn a bit
18:05neobrain[m]: mhm since when does issue editing require solving captchas? Would it be feasible to skip that for people with repo write access?
18:06MrCooper: I've never had to do that
18:10neobrain[m]: I've just seen it for the first time while fixing up formatting in another user's issue description, so it would be a recent change I suppose... or if it's not a Mesa config thing, maybe gitlab just decided I'm a bot :/
18:11imirkin: all bots complain about that...
18:14emersion: i've seen this as well
18:14emersion:swears he's not one of them
18:49zmike: I haven't
18:49zmike:has good programming
18:50ccr: program good. bug bad.
18:51ccr: Conan the Debugger
19:11sravn: derRichard, danvet: Renovating my new house comsume all my spare time and energy these days so no help from me until March/April time - sorry. And no, I cannot answer the orientation stuff from the top of my head
19:31derRichard: sravn: no big deal :-)
19:44zmike: anholt: any chance you (or someone else) wants to check out !8498
20:02airlied: danvet: one Linus->Linux typo in your page faults writeup
20:05danvet: thx fixed
20:06airlied: danvet: next write up should be what a userspace fences stack looks like, how it interacts with mm etc
21:55keithp: ajax: so, my question is 'how does anything work' without that patch?