00:01 Lyude: lesson learned: if you're chasing down an UBSAN issue, it will be way more painful if you don't have KASAN enabled also (this probably should have been obvious, heh <<)
04:58 airlied: yay llvmpipe aniso passes conformance :-P
05:00 HdkR: yay
05:14 airlied: HdkR: you know what an anistropic image should look better? https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/0ad/0ad.trace/
05:15 imirkin: airlied: i assume you're aware of the aniso demo in mesa-demos?
05:16 airlied: imirkin: yeah just not sure what I should expect there either :-P
05:16 airlied: https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/
05:16 imirkin: airlied: try it with hw -- the ansio is pretty obvious
05:16 airlied: definitely seems to get worse though, so I might have a bug still
05:16 imirkin: "better" and "worse" is in the eye of the beholder, i suppose
05:17 airlied: yeah I'm trying to do the same as softpipe does, but I don't have traces for that
05:17 airlied: and hey softpipe could be buggy
05:17 imirkin: ftr, i'm talking about mipmap_tunnel
05:19 airlied: yeah I'm using mipmap_tunnel and texfilt
05:20 imirkin: airlied: https://imgur.com/a/DXL5rLe
05:21 airlied: imirkin: nvidia?
05:21 imirkin: and similarly with texfilt, every aniso level makes the "textured" result smaller
05:21 imirkin: yes
05:22 imirkin: this one happens to be on a GP108, but i don't think it looks that different even on much older hw
05:23 imirkin: airlied: happy to provide more screenshots with other settings if that's useful to you.
05:25 HdkR: airlied: Racing games without AF is painful, you can see the mipchain degradation on the road quite easily :)
05:26 airlied: https://imgur.com/a/7oyUyVj is softpipe currently
05:26 airlied: and llvmpipe matches that
05:27 imirkin: heh
05:27 imirkin: so ... slightly different
05:27 imirkin: why is it so square vs the nvidia one which is round?
05:27 airlied: yup, I kinsa suspect softpipe is doing it wrong, and I'm copying it :-P
05:27 imirkin: well, forget anisotropy
05:28 airlied:goes back to reading the initial paper to make sure it at least resembles the maths
05:28 imirkin: look at the =1 case ... the llvmpipe one has a weird shape to it
05:28 imirkin: whereas on nvidia it's basically around
05:28 imirkin: round*
05:29 airlied: well it's already strange even with 1.0 aniso
05:29 imirkin: exactly
05:29 airlied: which just is I guess texture filtering on cpu optimisations
05:29 imirkin: there are some additional env vars
05:29 imirkin: which turn those off
05:30 imirkin: airlied: GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod
05:33 imirkin: hm, no effect. unless they got renamed...
05:34 imirkin: gah, yes. GALLIVM_PERF=... now
05:34 imirkin: huh. without GALLIVM_PERF it looks even worse. with GALLIVM_PERF, i get something that looks like your sample.
05:35 airlied: the max anisotropy also doesn't seem to affect softpipe
05:35 airlied: once it's 2.0 it switches to aniso
05:36 imirkin: yeah, doesn't seem like the softpipe thing is necessarily the definition of perfection...
05:37 airlied: it seems good enough for the people requesting it, so I suppose it llvmpipe is consistent nobody will care majorly
05:38 airlied: and if it passes CTS than I can claim GL 4.6 :-P
05:38 imirkin: hehe
05:56 imirkin: airlied: heh, that portal diff is pretty funny
05:56 imirkin: looks like the LOD is totally off?
05:56 imirkin: the floor and wall textures are all much more zoomed in
05:59 airlied: imirkin: yeah it's wierd I must have messed up somethign, probably need to build apitrace locally
07:07 phryk: This might be a dumb question but where the sweet hell do I find the libdrm documentation?
07:11 airlied: phryk: likely not a dumb q, since depending on what you are looking for it may range from somewhere obvious to non-existant
07:12 phryk: Well, libdrm documentation – I can't seem to find anything. Trying to evaluate how hard doing direct rendering without an existing X or Wayland session is.
07:13 airlied: phryk: you don't use libdrm for that
07:13 airlied: you'd use mesa
07:13 phryk: You don't? Okay, then I'm on the wrong track anyhow :P
07:13 keithp: vulkan has code to render directly to the hw
07:13 keithp: the 'display' backend
07:14 phryk: IIRC VUlkan only works with certain hardware, pretty sure not with mine. Also I'm on FreeBSD so I wouldn't exactly count on Vulkan support even with fancier hardware.^^
07:14 airlied: libdrm is mostly just a wrapper around kernel anyuways, so https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html can also be helpful
07:15 keithp: vulkan works with intel and radeon; dunno if that's fancy or not
07:15 keithp: in any case, lots of samples about how to use drm inside that code
07:15 airlied: also depends on what you mean by direct rendering, do you want to use EGL
07:15 keithp: it's a lot of typing
07:17 phryk: airlied: my understanding of the graphics stack is currently very limited. i did some cairo and opengl stuff, but have no idea what is needed to render without an x/wayland session
07:18 phryk: keithp: what do you mean with "that code"? did you mean to include a link previously?
07:18 imirkin: phryk: have a look at kmscube
07:18 imirkin: it's a nice simple app
07:18 imirkin: which does GL + direct kms
07:18 imirkin: phryk: https://cgit.freedesktop.org/mesa/kmscube
07:19 imirkin: supports both atomic and 'legacy' modesetting ioctl's
07:19 keithp: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/vulkan/wsi/wsi_common_display.c
07:19 phryk: mhh, there's a port of that on freebsd… and it fails to run^^
07:19 keithp: that's the mesa vulkan display WSI layer
07:19 imirkin: phryk: what hw are you using?
07:20 phryk: "failed to create fb: invalid argument"
07:20 phryk: imirkin: thinkpad x250, some intel thing
07:20 imirkin: and do you have mesa installed?
07:20 imirkin: and built with gbm support?
07:20 imirkin: anyways, actually failure to create fb is a different thing
07:21 imirkin: should be straightforward to debug
07:21 imirkin: good luck
07:21 imirkin: for the purposes of this, libdrm is a thin wrapper around ioctl's
07:21 phryk: i have no idea what gbm even is, i do have working hardware acceleration via opengl, that much i can tell you.^^
07:21 imirkin: you're not at the point where that matters
07:22 imirkin: you're at the point of "create a fb"
07:22 imirkin: figure out why that fails
07:23 airlied: yeah broadwell hw likely, should be workable
07:40 phryk: alrighty, bookmarking for future reference. should probably get horizontal soon.
07:40 imirkin: phryk: running 'modetest' from libdrm may be instructive as well
07:41 phryk: and if i had any documentation for libdrm i could even find out how and why. :P
07:43 imirkin: not too likely
07:44 imirkin: the ioctl is failing
07:48 Sumera[m]: danvet: logs for the failing kms_cursor_crc test, maybe igt_wait_vblank_count is the culprit?
07:48 danvet: ah yes that's not going to work
07:49 Sumera[m]: why do we need to keep a count of vblank events normally?
07:51 danvet: Sumera[m], hm where do you see that?
07:51 danvet: for that igt_wait_for_vblank function, I think the correct thing to do is just silently move on if we get an EOPNOTSUPP
07:51 danvet: from a quick look through all the callers
07:54 Sumera[m]: danvet: the vblank counter? was going through docs- found it here in https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vkms/vkms_crtc.c#L32
07:54 Sumera[m]: okay, will see if I can modify the tests now
07:54 danvet: Sumera[m], the crc event also has a frame count
07:55 danvet: we need to make sure the frame count and the vblank count all match up for the same composition
07:55 danvet: drm_vblank.c keeps track of the vblank count for us
07:55 danvet: I think for non-vblank mode we can leave the frame count in crc as 0
07:56 danvet: Sumera[m], see drm_crtc_add_crc_entry
07:57 danvet: maybe we should change the kerneldoc for this to say that if there's not vblank support, then @frame should be 0
07:57 danvet: since it's kinda meaningless to talk about frames that way
07:57 danvet: and maybe check that in the function too to catch it
07:57 danvet:not sure
07:57 danvet: vkms is the first virtual hw with crc we have, so this is all new stuff to define :-)
07:58 Sumera[m]: danvet: I see, makes sense now
07:59 Sumera[m]: yes, about the frame count, I think that's another change I need to make in the code
08:41 pq: clever, wayland dictates absolutely nothing about how a Wayland compositor should composite. Weston can do Pixman, GL ES, and KMS planes for example. It used to have a RPi proprietary API backend too. And even an Android backend. If you want to write a Wayland compositor using a gfx API no-one else has ever seen, you can.
08:43 HdkR: I look forward to the Wayland compositor written for RedGPU
08:44 emersion: i've done wayland-over-snailmail with a friend, with a wayland compositor (myself) compositing with a sheet of paper
08:48 MrCooper: clever: Xorg will likely never be able to take advantage of HW overlay planes, while Wayland compositors either do already, or will in the long term
09:14 Sumera[m]: siqueira: Hi, I was following up on this patch here https://patchwork.freedesktop.org/patch/316851/?series=48469&rev=3
09:16 Sumera[m]: Most of the tests rely on igt_wait_for_vblank_count so they are failing in my case, so I was wondering how you tested the patch.
10:45 hch12907: does anybody has idea why llvmpipe asserts under Windows?
10:46 hch12907: ../src/gallium/auxiliary/util/u_simple_shaders.c:683:util_make_fs_blit_msaa_depthstencil: Assertion `0' failed.
10:46 hch12907: gdb says the text passed to tgsi_text_translate() is empty
10:47 hch12907: which is puzzling..
11:14 bnieuwenhuizen: anyone know how to check is two dmabuf fds point to the same buffer? (preferably without opening yet another drm device)
11:15 ickle: os_same_file_description
11:15 bnieuwenhuizen: ah thanks!
11:16 clever: MrCooper: i think xvideo is the limit of hw planes in xorg
11:17 MrCooper: clever: not even those are generally supported by Xorg drivers with KMS
11:18 clever: that gives me an idea, if i just fix the kms drivers in xorg, could xvideo perform better? ...
11:18 MrCooper: you seem to enjoy beating dead horses ;)
11:19 karolherbst: honestly.. just use wayland. We should have closed all X bugs with ENOTSUPPORTED last year
11:19 clever: ive not tried wayland yet, and dont know how well my apps would work on it
11:19 karolherbst: as long as they are open source, great
11:19 MrCooper: XVideo overlays are inherently incompatible with compositing, i.e. pretty any non-ancient desktop environment
11:20 karolherbst:has to use wayland anyway
11:20 karolherbst: mixed DPI setup and stuff
11:20 karolherbst: X is just... "2000" level software
11:21 MrCooper: it started in the 80s :)
11:21 karolherbst: had the fun of using windows recently, and they are doing quite a lot of impressive things tbh
11:22 karolherbst: especially this "I download your GPU driver in the background, install it and load it without you having to reboot"
11:23 clever: yeah, that sounds impressive
11:23 karolherbst: we really should make more use of robustness in the desktop space
11:24 karolherbst: and should stop killing the desktop just because the GPU messed up
11:24 clever: oh yeah, one sec
11:24 milek7: haha, if it works
11:24 milek7: recently screen just turned black and I had to reboot anyway..
11:24 karolherbst: well, nothing is perfect :p
11:24 clever: [root@amd-nixos:~]# Jan 20 16:49:47 amd-nixos kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=1182529748, emitted seq=1182529750
11:24 clever: Jan 20 16:49:47 amd-nixos kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process X pid 1219 thread X:cs0 pid 1243
11:24 karolherbst: clever: ohhh you use nixos... mhhh
11:24 clever: i ran into this about a week ago, and the X crashed hard
11:24 karolherbst: in this case.. you are screwed :p
11:25 clever: karolherbst: why? lol
11:25 karolherbst: ohh no, wait
11:25 karolherbst: I _always_ mistake it for cubeos :D
11:25 danvet: MrCooper, clever Xv as an Xwayland subwindow probably not the worst thing
11:25 karolherbst: clever: yeah.. that's why I say we should make use of robustness
11:26 karolherbst: application creates a robustness GL context and we just report back the GPU messed up to userspace
11:26 karolherbst: and userspace creates a new one
11:26 MrCooper: danvet: yep, that would make more sense
11:26 karolherbst:still need to wire it up for nouveau
11:26 clever: a different problem i have, is that a lot of games in steam, will do a full pointer grab
11:26 karolherbst: yeah
11:26 karolherbst: use wayland :p
11:26 clever: alt+tab does release the grab, however, it takes the game 30+ seconds to realize it
11:26 clever: upon the game realizing and giving up, it moves the pointer back to its window just once
11:26 karolherbst: and wayland with a proper compositor
11:27 clever: then focus follows mouse focuses it, and restores the pointer grab!
11:27 danvet: MrCooper, yeah adding it to -modesetting or something like that is a lost cause I think
11:27 karolherbst: yeah.. stuff like that isn't possible with wayland anymore
11:27 karolherbst: at least for X apps
11:27 clever: so you must alt+tab, then move the pointer away from that window for 30 seconds
11:27 clever: and there is a 5% chance of the window manager locking up solid when doing that
11:28 karolherbst: we should just release 1.21 without X :p
13:10 emersion: so, is the drm authentication stuff still necessary these days when you have a primary node?
13:11 emersion: it's not necessary for render nodes, so are primary nodes more restricted somwhoe?
13:11 emersion: somehow?
13:19 emersion: cc danvet maybe? ^
13:21 danvet: emersion, I think yes
13:21 danvet: but just open render nodes instead
13:21 danvet: the thing is, primary node gives you flink, so it's kinda nasty
13:21 danvet: render node doesn't, so it's free for all
13:21 emersion: hm, but i don't always have a render node, sadly
13:21 emersion: because of kmsro
13:22 emersion: (split display/render nodes)
13:22 emersion: (split display/render devices*)
13:22 danvet: primary node needed for buffer allocate for scanout?
13:22 emersion: hm, more like primary node needed for KMS, and then we have no way to figure out which render node to use
13:23 danvet: usually the only one you have :-)
13:23 emersion: it's super annoying, it trashes part of my beautiful design
13:23 danvet: wasn't that were we ended before I left?
13:23 danvet: with the reimport issues for fd2handle
13:24 emersion: yeah, but what happens if you have e.g. displaylink device, i should not use a render node like this
13:24 danvet: unsolved I think
13:24 emersion: hm, i don't remember that the fd-to-handle stuff was related to split render/display
13:24 danvet: imo for the split architecture you also want to do compositor side buffer allocations
13:25 danvet: so that you only allocate on the display when you actually try to scan it out
13:25 danvet: and not for all buffers, just in case
13:25 emersion: hm, i'd prefer not to
13:25 danvet: also, side-steps the primary node auth nonsense
13:25 emersion: because of memory accounting
13:25 danvet: well usually the display memory comes from a cma region
13:25 danvet: letting abitrary clients allocate from that isn't a good idea
13:26 emersion: i';d prefer to tell the client to use (1) the right render node (2) the scanout modifiers if scanout is possible
13:26 danvet: cma isn't a modifier
13:26 emersion: well, right now, if a modifier is scanout-capable, the driver must allocate something that can be scanned out
13:27 danvet: yeah that's not that great imo
13:27 emersion: yeah it's not great at all
13:27 emersion: but i'm not sure the solution is to allocate in the compositor
13:27 danvet: since essentially you allow any unpriviledged client to starve the compositor of scanout memory
13:28 danvet: compositors manages all the other display resources
13:28 danvet: so imo for displays requiring cma, it needs to manage that too
13:28 emersion: clients could also starve the compositor of regular memory
13:29 emersion: some equally bad things would happen in this case
13:30 emersion: (cc pq)
13:31 emersion: maybe should just prevent processes which aren't DRM master to allocate cma on systems with low scanout memory
13:32 emersion: but yeah. that ruins any chance to do direct scanout of client buffers
13:34 emersion: xexaxo1: have you had the chance to figure out a better solution for this split display/render EGLDevice issue?
13:34 danvet: emersion, no, you need server side allocate and then share
13:34 danvet: for this case
13:35 danvet: so you can still let clients render into the right buffer directly
13:35 danvet: emersion, also yes right now clients can just allocate memory
13:35 emersion: > clients could also starve the compositor of regular memory
13:35 danvet: but cgroups for drm is becoming real I hope
13:35 emersion: hm
13:35 danvet: plus regular memory you can already limit with cgroups, no problem
13:35 emersion: i mean regular GPU memory
13:36 danvet: yeah it'll happen
13:36 emersion: oh?
13:36 emersion: nice
13:36 danvet: so assuming this will never get fixed is kinda not so great
13:36 danvet: well, we've talked about it for years
13:36 danvet: but now both intel and amd are working on cgroups proposals
13:36 emersion: ok
13:36 danvet: and my take is the general gpu memory account we should probably just put into gem_create
13:36 danvet: so it accounts for everything (except ttm, but *shrug*)
13:36 emersion: but then could just have a different cgroup limit for scanout memory
13:37 danvet: yeah, but then if you set it too low, no one can rendering directly to a 4k fullscreen buffer
13:37 danvet: and you definitely don't have enough memory to allow every app to allocate a 4k scanout buffer
13:37 danvet: *cma memory
13:37 pq: danvet, even if the had the compositor to allocate scanout memory for clients, what good would that do?
13:38 danvet: pq, you'd only allocate it if that window has a hw plane allocate for it
13:38 emersion: danvet: the compositor could change it per-client, on the fly, if it wants to
13:38 danvet: otherwise you'd tell the client to allocate a normal render buffer (which you can't scan out)
13:38 danvet: or allocate a normal render buffer for it
13:39 danvet: emersion, pq probably means you need buffer revoke support to to reclaim the memory
13:39 danvet: otherwise server side alloc doesn't solve much
13:39 emersion: not long ago, xwayland allocates every buffer with USE_SCANOUT, so i'm not too worried right now
13:39 emersion: allocated*
13:39 danvet: pq, I think it's very similar problem to kms leases
13:39 danvet: it's a (slightly less limited) display hw resource
13:41 pq: danvet, we have dmabuf hints for "please allocate differently", and compositor cannot shoot down clients' buffer at will even if it did allocate them, it doesn't help with running out of scanout memory. Unless you kill the whole client.
13:42 vsyrjala: no one wants to automagically migrate stuff in/out of cma?
13:43 emersion: the server-side allocation protocol could have a "kick this buffer out" logic, but it would be a bit brutal, compositor could end up with nothing to display for a client
13:43 emersion: and client could end up with GL/Vulkan errors too i guess
13:43 pq: emersion, yes, the end up with nothing to display is not acceptable.
13:43 pq: Would it be possible for a compositor to move a buffer into or out of cma behind a client's back?
13:43 emersion: vsyrjala: i think nouveau does something like this? to limited success, there are some sync issues
13:44 emersion: but it sounds possible
13:44 emersion: pq: this sounds a bit like james jones' transition proposal
13:44 danvet: vsyrjala, dma-api layer is in between
13:45 danvet: but yeah migrating cma out of it might be an option
13:45 danvet: needs someone willing to convince hch he needs to change a few of his opinions
13:45 pq: does migrating into/out of cma require that the compositor was the one who allocated the buffer?
13:45 emersion: pq: james jones wanted to add an API to transition a buffer in-place from one modifier to another
13:45 danvet: hm the display generally doesn't have a dma engine
13:46 danvet: and you don't want to migrate big buffers with memcpy
13:46 pq: emersion, no, this is not that. This is not about buffer contents but buffer placement.
13:46 danvet: pq, revoke would need to be similar to kms leases
13:46 danvet: first you ask nicely
13:46 emersion: yeah, it's different, but similar
13:46 danvet: if the client doesn't obey, you kill it
13:46 danvet: similar to vt switch for compositors vs logind
13:47 danvet: emersion, I thought that was mostly for resolve passes and stuff like that
13:47 danvet: and I think it's still on the table, for vk
13:47 danvet: since vk has that as a concept already
13:47 danvet: maybe jekstrand ^^
13:47 emersion: danvet: that sounds complicated to implement. the compositor needs a scanout buffer *right now* because a new output needs to be enabled, but first needs to ask clients nicely to free their buffersd?
13:48 danvet: well keep a buffer in reserve if you need gaurantees
13:48 pq: a two-step revoking process might work, but it leaves the compositor dangling for timeout duration...
13:48 danvet: otherwise low memory is going to temporarily suck
13:48 danvet: that's always kinda the deal
13:48 danvet: but like with kms lease, if you don't revoke, then black screen
13:49 danvet: also this is all really for hard-isolating clients with cgroups, and we're kinda not there yet
13:49 danvet: but since wayland is meant to be resistant to getting pulled over the table and all that, probably a thing that will become relevant
13:49 emersion: yeah, my original questions was about split display/render devices being a hassle :)
13:50 pq: emersion, IMO direct scanout on something like displaylink is just not going to work at all. Does that help? :-)
13:50 danvet: yeah displaylink will involve some cpu copies anyway
13:50 emersion: well, yes, it won't work, but how do i detect that?
13:51 danvet: at least current drm/udl driver
13:51 pq: emersion, detect what exactly?
13:51 danvet: same applies to drm/tiny aux drivers over spi or similar
13:51 emersion: i have a DRM primary node which is missing a render node (e.g. rockchip), and a separate DRM device with both primary and render (panfrost)
13:52 pq: emersion, that the displaylink device can't render? Create a contect with Mesa, see if you got a software rasterizer.
13:52 emersion: how do i figure out that i need to use panfrost to render buffers that can be displayed on rockchip?
13:53 emersion: eh, yes, but there's no way to detect whether a got a software rasterizer…
13:53 emersion: i got*
13:53 emersion: and this still relies on primary nodes for rendering
13:53 emersion: i want to use render nodes for rendering
13:53 pq: you check GL_RENDERER string...
13:53 emersion: ideally side-step kmsro
13:54 pq: If you can't rely on kmsro telling you, then you just have to try yourself if KMS accepts what that render node produces.
13:54 emersion: yeah. allocate a buffer, try to import it into KMS…
13:54 pq: with modifier lists
13:55 emersion: i just hope kernel drivers correctly reject foreign buffers
13:55 pq: if they don't, you just file kernel bugs ;-)
13:56 pq: more problematic thing will be in cases where the buffer does work, but a more optimal configuration would exist too
13:56 emersion: are there such cases?
13:56 danvet: yeah, at least for cma we check at import and fail if it's not contiguous
13:56 pq: e.g. a hybrid gfx laptop
13:56 danvet: so fd2handle will keel over
13:57 emersion: but a hybrid gfx laptop will have both devices with render nodes?
13:57 danvet: luckily I think there's no drm in upstream which has both display + render and only display needs contig
13:57 danvet: since for that it'd only fail at addfb time
13:57 pq: emersion, yes, but which render node do you pick?
13:58 emersion: oh, that's easy, the one with the boot flag, except if the user overwrites it
13:58 emersion: overrides it*
13:58 emersion: we already have logic for this
13:59 emersion: or do you mean how do you pick the render node from the primary node used for KMS?
13:59 emersion: the answer to that is drmDevice
14:00 emersion: it tells you the primary <-> render node mapping (except for split render/display devices)
14:04 pq: emersion, yeah, there are heuristics for that :-)
14:05 clever: lrwxrwxrwx 1 root root 8 Feb 1 17:20 platform-fec00000.v3d-card -> ../card0
14:05 clever: lrwxrwxrwx 1 root root 13 Feb 1 17:20 platform-fec00000.v3d-render -> ../renderD128
14:05 clever: lrwxrwxrwx 1 root root 8 Feb 1 17:21 platform-gpu-card -> ../card1
14:05 clever: hmmm, and i'm confused as to how my device has 2 cards
14:05 emersion: … you can just read the discussion above
14:05 emersion: (joking)
14:05 pq: emersion, I think I lost your problem... in the rockchip case, you only have one rendering-capable render node.
14:06 clever: renderD128 is fairly obvious, it would deal with 3d->2d conversions/rendering, card1 i know is for video out, but then ... what is card0?
14:06 ascent12: Every DRM device gets a primary node, even if it doesn't do scanout
14:06 emersion: clever: you have split display/render devices. one is for display (sending buffers to screens, via connectors like HDMI), the other is for rendering (via e.g. GL)
14:07 clever: ah, so the 3d core needs its own card0, despite not having scanout capability?
14:07 emersion: pq: yeah. and in the displaylink + amdgpu case, i have exactly the same
14:07 ascent12: I don't know about "need", but it gets one anyway
14:07 emersion: clever: i think "need" is mostly for legacy user-space
14:08 clever: ah
14:08 emersion: that doesn't know about render nodes
14:08 clever: ideally, a proper userland would open all cards, and query which one has scanout?
14:08 ascent12: Depends
14:08 emersion: pq: my problem is figuring out when i should allocate with the separate render device for scanout
14:10 pq: emersion, always, unless it doesn't work?
14:10 pq: clever, yes, userland should open all primary devices on its seat to find out all the KMS resources and outputs it could light up.
14:10 clever: pq: and how do you query which ones are on the seat? and configure that from an admin point of view?
14:10 clever: ive just been hard-coding card1 and running as root
14:10 pq: clever, udev
14:11 ascent12: clever: logind seats work
14:11 emersion: pq: yeah, just need to figure that out pretty early in the initialization process, before i'm trying to light up any CRTC
14:11 clever: i havent played with multi-seat since the pre-systemd days
14:11 pq: clever, it's the ID_SEAT udev property.
14:12 clever: ahh
14:12 pq: emersion, yes, and I can believe it's annoyting.
14:13 ascent12: clever, pq: `loginctl attach $seat $device` does the same thing as well. Slightly more user friendly than writing udev rules, which I'm pretty sure it does internally.
14:14 pq: ascent12, indeed, I believe so :-)
14:14 clever: i also see a 73-seat-late.rules in my main distro, though currently, all of my machines are single-gpu ones
14:14 clever: and i think splitting a single gpu into multiple seats is a far more complex task
14:15 pq: clever, without any configuring, all DRM devices always go to the default seat I think.
14:15 pq: it is
14:15 ascent12: Yeah, everything goes to seat0 by default
14:15 clever: thats what i would expect, just assume its a single-seat system
14:27 danvet: tzimmermann, [PATCH] drm/nouveau: remove set but not used variable ‘pdev’ in nouveau_bios_init
14:27 danvet: for you?
14:27 tzimmermann: danvet, i though that was merged already :/
14:28 tzimmermann: thought
14:28 danvet: tzimmermann, oh I dind't check, just didn't see any reply
14:28 danvet:catchingup
14:28 tzimmermann: danvet, i didn't really check either :)
14:28 tzimmermann: i can look at it
14:28 MrCooper: imirkin karolherbst: "nvc0_screen_get_param: unhandled cap 241" spam in meson-gallium job: https://gitlab.freedesktop.org/daenzer/mesa/-/jobs/7041342
14:44 imirkin: MrCooper: not unexpected. as caps are added, we need to review them to figure out where they belong
14:51 MrCooper: imirkin: maybe make an unknown cap result in failure, and let CI take care of it
14:54 imirkin: MrCooper: the point is to make it a warn
14:54 imirkin: originally when people added caps, they'd add them to all drivers
14:54 imirkin: so it was easy to review those changes
14:54 imirkin: however someone complained, loudly enough apparently, and the push was to have "default" handling
14:55 imirkin: however i still want to know when a new cap is added
14:55 imirkin: this is a debug print, so only shows up in debug mode
14:55 imirkin: (and maybe debugoptimized? i don't know the rules)
14:56 MrCooper: I don't really care how the job log spam is fixed, so long as it is
14:56 imirkin: ok, let's just remove nouveau from that list then
14:57 imirkin: (that job is a a super-spammy job anyways though, not sure why you're so concerned)
15:03 MrCooper: not asking to throw the baby out with the bathwater :)
15:04 imirkin: can't think of another way of generically getting rid of the log spam
15:04 imirkin: i guess we could cache the unknown cap messages
15:05 imirkin: and only print them once per cap
15:05 imirkin: since there are a finite number of caps, this can just be a bitset / array initialized to 0
15:06 imirkin: can also add 2>/dev/null ?
15:06 imirkin: happy to ack any patch which leaves the warnings around.
15:09 karolherbst: imirkin: yeah.. I think caching is a good idea
15:09 karolherbst: just have a static bool stuff[WHATEVER_THE_MAX_CAP_IS];
15:10 karolherbst: I'll write a patch as they annoyg me as well :D
15:21 karolherbst: imirkin: what do you say about we just print it once and the first cap wins?
15:21 karolherbst: but that's probably also a bit annoying
15:22 karolherbst: thing is, we don't really have a PIPE_CAP_LAST, but I guess it doesn't hurt to add one
15:23 imirkin: karolherbst: once per cap. you can add a PIPE_CAP_LAST
15:23 karolherbst: yeah
15:53 karolherbst: ehhh...
15:53 karolherbst: what is the proper fix for casting a pointer to an 64 bit int on 32 bit builds?
15:53 karolherbst: cast to uintptr_t first?
15:53 imirkin: i think so, yea
15:54 karolherbst: at least that compiles
15:55 imirkin: yeah, don't know if it's "the" way, but def "a" way
15:55 karolherbst: yeah...
15:55 karolherbst: dunno if I think this error makes tons of sense, but.. well
15:55 karolherbst: but if we have a uint64_t in the ioctl, not much we can do
15:56 karolherbst: uhm.. actually
15:56 karolherbst: ahh no, doesn't matter
15:56 imirkin: you said casting a pointer to a 64-bit int
15:56 imirkin: casting a pointer to a 32-bit int is slightly less safe on 64-bit builds :)
15:57 karolherbst: sure
15:57 karolherbst: but it's about SVM anyway
15:57 karolherbst: literally dead code
15:57 karolherbst: on 32 bit that is
15:59 karolherbst: MrCooper: better? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/7048615
16:00 karolherbst: there is weird flushing going on, but whtvr
16:00 imirkin: oooh, someone updated shader-db in the container. yay
16:01 karolherbst: anyway, MR is here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8831
16:01 imirkin: wait what? why does it skip over ES 3.0 shaders on nva3? that's weird.
16:01 karolherbst: mhhh
16:01 karolherbst: I should add an = {};
16:01 imirkin: i'm sure it's unrelated to your changes
16:01 karolherbst: I hope so
16:02 imirkin: but didn't notice it before
16:02 imirkin: oh, ES is just broken - it doesn't work with 100 either.
16:03 imirkin: but it somehow works on nv30 / nvc0. supppper.
16:03 karolherbst: ehh :/
16:03 karolherbst: probably some cap req
16:04 karolherbst: maybe we should CI on the GL(ES) versions :D
16:04 karolherbst: imirkin: or maybe something shim related?
16:04 imirkin: yea, dunno
16:04 imirkin: could be
16:05 imirkin: i'll take a look later.
16:24 MrCooper: karolherbst: looks much better, thanks!
16:30 imirkin: karolherbst: hm, well at least with latest master, wflinfo does report ES 3.0 on nva3 with the shim (and then hangs, but i think it's waiting on some fence)
16:39 imirkin: there's something weird going on ... none of the drivers are reporting GL_OES_standard_derivatives even though it's clearly 100% supported everywhere - not just nouveau.
16:39 karolherbst: strange
16:39 imirkin: i'm thinking the runner might be doing something funky
16:39 karolherbst: that might be
16:41 xexaxo1: emersion: some ideas did came to mind, let me put them in the issue
16:56 idr: What's the NIR pass that renumbers SSA values?
16:57 pendingchaos: nir_index_ssa_defs
16:59 idr: Thanks
20:27 emersion: danvet: hm it seems like we're missing a license for libdrm
20:27 danvet: should be MIT?
20:27 emersion: yeah
20:27 emersion: is it ok to just drop a LICENSE file
20:27 emersion: ?
20:28 emersion: i see MIT headers everywhere indeed
20:28 emersion: ah, mesa is missing it as well. i guess everything's intentional?
20:28 emersion: sorry, i'm just used to seeing LICENSE in all projects
20:29 emersion: https://gitlab.freedesktop.org/mesa/drm/-/issues/58
20:46 jekstrand: Yeah, mesa and libdrm predate the LICENSE
20:46 jekstrand: I'm gladd GitHub and the like are pushing for LICENSE files. It's good practice.
20:46 jekstrand: But not all projects do it.
20:51 imirkin: is gitlab having some sort of issue fetching e.g. MR comments?
20:52 imirkin: i'm seeing 500 errors fetching the discussions.json and related
20:54 jekstrand: emersion: One thing to watch out for is that I think Mesa has a few files which aren't MIT. I'm not sure what we're supposed to do with LICENSE in that case.
20:54 bl4ckb0ne: got a `Something went wrong while fetching latest comments.` on an issue
20:55 imirkin: i've made a mention in #freedesktop
20:56 emersion: jekstrand: hm, could we in theory migrate to SPDX license identifiers?
20:56 emersion: jekstrand: the kernel also has mixed license
20:56 emersion: licenses*
20:56 karolherbst: I guess SPDX is the way to go
21:06 anholt: spdx is a solution looking for a problem imo
21:13 mattst88: anholt: for one thing it's a lot harder to make mistakes like https://bugs.gentoo.org/700938 / https://gitlab.freedesktop.org/libevdev/libevdev/issues/9 when using SPDX :)
21:14 mattst88: (tl;dr: libevdev was using the wrong license for its entire existence until a few days ago)
21:17 anholt: I've seen a lot of dubious spdx conversion of code I've been involved in, which I didn't care enough to get into arguments about and let slide, so I have low expectations of its accuracy.
21:30 imirkin: the conversion in the kernel ... could have been handled better
21:56 danvet: yeah the spdx conversion in the kernel pissed of tons of people
21:57 danvet: I guess for a project with tons of dual licensing going on it makes some sense, but not like it was done in the kernel
22:00 imirkin: for the kernel, maybe like a "get your shit in order" announcement, followed by a forced update a release later, would have made more sense