ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Company has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
crabbedhaloablut has quit []
qyliss has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
kts has joined #dri-devel
qyliss has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Read error: Connection reset by peer]
co1umbarius has joined #dri-devel
simon-perretta-img has joined #dri-devel
DPA has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
<jenatali> karolherbst: should I take your comments as an ack? Guess I need to bug Faith unless there's someone else to review that pass
<karolherbst> jenatali: maybe? I'm not that familiar with the pass, all I fixed was some nir validation fail :')
<jenatali> Fair enough. I'll ping her tomorrow I guess
yyds has joined #dri-devel
vyivel has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
vyivel has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
lemonzest has quit [Quit: WeeChat 4.1.1]
yyds has joined #dri-devel
lemonzest has joined #dri-devel
tales-aparecida2 has quit []
tonyk has quit [Quit: Ping timeout (120 seconds)]
tonyk has joined #dri-devel
tales-aparecida2 has joined #dri-devel
jernej has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
ginnie has quit []
kts has quit [Ping timeout: 480 seconds]
lemonzest1 has joined #dri-devel
lemonzest has quit [Ping timeout: 480 seconds]
jernej has joined #dri-devel
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
aravind has joined #dri-devel
luben has joined #dri-devel
tales-aparecida2 has quit []
tonyk has quit []
tales-aparecida2 has joined #dri-devel
tonyk has joined #dri-devel
jernej_ has joined #dri-devel
jernej has quit [Ping timeout: 480 seconds]
soreau has quit [Ping timeout: 480 seconds]
jernej_ has quit [Ping timeout: 480 seconds]
soreau has joined #dri-devel
jernej has joined #dri-devel
qyliss has quit [Ping timeout: 480 seconds]
lanodan has quit [Quit: WeeChat 3.8]
lanodan has joined #dri-devel
bmodem has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
sima has joined #dri-devel
sima is now known as Guest6232
sima has joined #dri-devel
aravind has joined #dri-devel
alatiera has joined #dri-devel
Guest6232 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Duke` has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit []
Jeremy_Rand_Talos_ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
frieder has joined #dri-devel
eukara has joined #dri-devel
tzimmermann has joined #dri-devel
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
Daanct12 has joined #dri-devel
tursulin has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
fab has joined #dri-devel
guru_ has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
lanodan has quit [Quit: config test]
lanodan has joined #dri-devel
mvlad has joined #dri-devel
Daaanct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
<tzimmermann> javierm, hi javier. what's your opinion on that lengthy discussion at https://lore.kernel.org/dri-devel/CAAhV-H4hkx0BJ-Y6rNCNgDw_yr4S7uDcTV_249EK-4AbqU5BDg@mail.gmail.com/T/#t ?
<tzimmermann> it seems like the aperture code has a bug, so that simpledrm binds after i915
<javierm> tzimmermann: I just noticed your email and answered. I need to read that lengthy discussion after having some coffee
<tzimmermann> ok :)
<tzimmermann> please ping me once you're done. i have a question
<javierm> sure
jkrzyszt has joined #dri-devel
ficoPRO10 has joined #dri-devel
aradhya7 has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
crabbedhaloablut has joined #dri-devel
frankbinns has joined #dri-devel
pcercuei has joined #dri-devel
apinheiro has joined #dri-devel
rasterman has joined #dri-devel
qyliss has joined #dri-devel
macslayer has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
aravind has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
<javierm> tzimmermann: Ok, went through that thread now
<javierm> tzimmermann: The problem seems to be that when having both simpledrm and a native DRM driver built-in, simpledrm is probed after the native DRM driver removed the conflicting devices?
<tzimmermann> yes
<tzimmermann> that is my understanding
<tzimmermann> but it should not happen, as i outlined in my reply to the patch
<javierm> tzimmermann: yes, the aperture infra should call sysfb_disable() from aperture_remove_conflicting_devices()
<tzimmermann> and AFAIU the i915 device is the primary vga device
<tzimmermann> otherwise it wouldn't be handled by simpledrm at all
<tzimmermann> i don't understand what's happening
<tzimmermann> javierm, is it possible to probe devices in parallel?
<tzimmermann> such that i915 would probe the native device, while simpledrm probes the platform device?
<javierm> tzimmermann: I think there's a way to make the probe be async
<tzimmermann> javierm, ok i keep that in mind
<tzimmermann> hyperv_drm seems to use that, but nothing else within drm
<tzimmermann> javierm, there's a question/idea i have: the platform device has currectly no conenction to the pci device. maybe we should make the platform device a subdevice of the native one?
<tzimmermann> the native device is available from vga_default_device()
<tzimmermann> that would allow to model such dependencies
<javierm> tzimmermann: yeah, the only connection is the aperture. What I don't understand here is why that is not enough
<javierm> do you think is a race then?
<tzimmermann> neither do i
<tzimmermann> no idea
<tzimmermann> i hope they can further debug it
<javierm> I think your question is the crux, is sysfb_disable() being called at all?
<javierm> that would explain why simplerm is probed at least
<javierm> *simpledrm
<tzimmermann> and it should unless the i915 device is not the vga default
<tzimmermann> javierm, do you know if there's a clear order for probing a parent and its subdevices?
<javierm> tzimmermann: I think there is not, unless device links are used
<tzimmermann> device links?
<tzimmermann> i see. that looks like something different
lynxeye has joined #dri-devel
<javierm> so AFAIU that's the only way to give some ordering to the device <-> driver match / driver probe
<javierm> otherwise is brute force and that's why we have -EPROBE_DEFERRAL
<tzimmermann> javierm, i think it solves a different problem
donaldrobson has joined #dri-devel
<javierm> tzimmermann: so what Huacai's patch did is to call sysfb_init() in the subsys init call to register the "simple-framebuffer" device as early as possible
<javierm> tzimmermann: then the i915 pci device is registered by ACPI, that matches the i915 driver and is probed
<tzimmermann> ok?
<javierm> then i915 calls drm_aperture_remove_conflicting_pci_framebuffers() and since is the primary device, it should call calls sysfb_disable()
<tzimmermann> exactly
<javierm> so either that does not happen (because is not the primary?) or the simpledrm driver is matched in the meantime
<javierm> in the window between i915 is probed and the simple-framebuffer device is removed
<javierm> tzimmermann: could that be possible? Only if using that .probe_type = PROBE_PREFER_ASYNCHRONOUS but neither simpledrm nor i915 set it?
<tzimmermann> idk
<javierm> yeah, me neither
<tzimmermann> javierm, there's a comment about sysfb running after PCI at https://elixir.bootlin.com/linux/v6.5/source/drivers/firmware/sysfb.c#L130
<tzimmermann> can we move the sysfb code to a later point?
<tzimmermann> something like: (1) probe pci bus and devices, (2) sysfb, (3) probe pci drivers in modules ?
<javierm> tzimmermann: it used to be in device_initcall() before Huacai's patch changed to subsys_initcall() and that seemed reasonable to me
<javierm> tzimmermann: but yes, I think you are correct and we could make it sure that happens after all the real devices have been registered by ACPI, OF or whatever
<tzimmermann> that would put i915 before sysfb; unless it's a module
<javierm> probably device_initcall_sync() or even late_initcall()
<javierm> tzimmermann: yes, and sysfb_init() would then be a no-op because will check if is disabled already
<tzimmermann> exactly. the sysfb code would return immediately
<javierm> tzimmermann: can you mention in the thread and propose a patch? And also update the comment that should not only happen after PCI but after all the devices have been registered
<tzimmermann> well, it's just an idea for now. i'd like them to first debug this further
<javierm> that makes sense, it will delay a little bit when the simple framebuffer is present but seems the correct thing to do
<javierm> tzimmermann: Ok
<javierm> tzimmermann: regardless, I think that you are correct that should happen after device_initcall()
<tzimmermann> but more generally speaking, we should have a clear idea about the dependencies here
<javierm> tzimmermann: ideally all drivers should request their memory regions and this handled at the device core
<karolherbst> gfxstrand, jenatali: any opinions on this MR? It adds a couple of workarounds for Intel's DPCPP which arne't too horrible.. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25701
kts has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
DottorLeo has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
konstantin has joined #dri-devel
<MrCooper> Mesa advertises EGL configs which claim RGB10 is renderable with GLES, but is_format_color_renderable says it's not; which is correct?
cmichael has joined #dri-devel
tursulin has quit [Quit: Konversation terminated!]
ficoPRO10 has quit [Ping timeout: 480 seconds]
ficoPRO10 has joined #dri-devel
<javierm> pq, emersion: any thoughts on https://bugzilla.kernel.org/show_bug.cgi?id=218115? The commit mentioned in the report is 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the primary plane")
<javierm> which just makes the FB_DAMAGE_CLIPS property to be exposed by the virtio-gpu driver
<emersion> javierm: my first guess would be a bug in the driver's implementation of FB_DAMAGE_CLIPS?
<emersion> since i haven't received bug reports for any other driver
<javierm> emersion: the implementation is very basic, it just does a drm_atomic_helper_damage_merged() to get a merged damaged rectangle
<javierm> but also I didn't notice any flickering with mutter
<emersion> does mutter support this prop?
<javierm> emersion: it does, yes
<emersion> is your mutter version high enough?
<sima> javierm, aside, but virtio_gpu_crtc_atomic_flush looks very funny
<javierm> emersion: I tested to whatever was latest HEAD at the time the patch was posted
<emersion> the impl in wlroots is very basic as well, basically just forwarding damage
<sima> it sets output->needs_modeset = true, which virtio_gpu_primary_plane_update looks at
<sima> but the helpers call atomic_flush _after_ plane_update
<sima> should probably be in atomic_begin, or I'm just extremely dense rn :-)
<sima> also not sure whether the early return if there's no damage is entirely correct ...
<emersion> i haven't found a way to submit an empty damage region via the uAPI
<sima> flip without any damage
<emersion> so i just do full damage in that edge case
<sima> implies full damage
<emersion> empty damage = nothing changed
<emersion> full damage = everything changed
<sima> not how the internals work, see drm_atomic_helper_damage_iter_next() and iter->full_damage in that code
<sima> but yeah aside from the atomic_flush confusion I don't see anything obviously wrong in the virtio damage handling
<sima> ah I think I see how the atomic_flush works now, the check does catch the initial modeset for different reasons
<sima> and from then on the disable sets the output->needs_modeset for the subsequent enable, where the issue was per 3954ff10e06e4
<sima> so it does work
<javierm> sima: flip without any damage implies full damage? That's not what all the drivers that use this drm_atomic_helper_damage_merged() helper behave
<sima> just rather confusion way to implement this :-)
<sima> javierm, you get a full damage rect if there's none from that helper
<sima> emersion, I guess we have a bit a perf issue of needless uploads if you just move a plane around :-/
<emersion> :sadface:
<sima> so we might need a special "I actually mean no damage, trust me" knob somewhere
<sima> but not sure how to squeeze that into the current uapi without breaking things anywhere
<javierm> sima: yes, but returns valid == false
<emersion> is the no damage case this: FB_DAMAGE_CLIPS=0 and same FB_ID as before?
<sima> javierm, did you check or just guessing?
<emersion> we could add a case for a zero rect
<javierm> valid = true is set in the loop
<emersion> no super great uAPI, but oh well
<emersion> we can't do empty blobs can we?
<sima> emersion, I don't think the code treats that different than not setting any damage blob at all :-/
<sima> javierm, yeah, but damage_iter gives you one rect for the full damage case
<javierm> sima: oh
<sima> see the special case handling around iter->full_damage
<sima> so it /should/ work
<sima> obviously reality begs to differ :-/
<javierm> sima: that helper makes the wrong assumption then
<sima> javierm, why?
<javierm> sima: because then the valid true or false makes no sense, it will always be true
<sima> javierm, it's false when the fb is off
<javierm> so we could just remove it and make it return void
<javierm> sima: right
<javierm> sima: nvm then, sorry for the confusion
<sima> which you already check for earlier in the virtio code
<sima> it's just trying to bullet-proof drivers because too many people test as far as "it boots" and never try to even turn the crtc off ...
<javierm> sima: not my implementation btw :) I just enabled the damage clipping since the update plane callback already had the logic
<sima> yeah tbh I have no idea why it doesn't work ...
<emersion> there is a distinction between "frame damage" and "buffer damage", fwiw
<emersion> the uAPI is the "frame damage", ie. since last frame
<emersion> it's different from the updated regions of the specific buffer since it was last submitted
<sima> uh the uapi is in plane src coordinates and buffer damage
<emersion> really?
<sima> yeah
<sima> well
<sima> you need both, so if you use the same buffer twice on 2 planes you need to give it the same clip rects
<sima> well maybe viewport clipped
<emersion> "list of damage rectangles on a plane in framebuffer coordinates"
<sima> uh
<emersion> "area of plane framebuffer that has changed since last plane update"
<emersion> sounds like it's since last frame and in buffer coords
<emersion> which is what i would expect
<sima> maybe we have a confusion about the differences in semantics
<sima> emersion, frame damage in framebuffer cordinates sounds right after a bit of pondering
<sima> hm
<sima> ok I think this might actually be the bug
<sima> like if you page-flip, then userspace sends the damage against the previous frame
<sima> which works for manual upload cases
<sima> but virtio needs the damage against the previous use of that buffer for uploading that buffer correctly
<sima> which then fails
<sima> but it does work if you a) do only FB_DAMAGE_CLIPS while keeping the same FB_ID or b) only change FB_ID without any damage rects
aravind has quit [Ping timeout: 480 seconds]
<javierm> sima: which is the reason why damage clipping with DRM_MODE_PAGE_FLIP_ASYNC doesn't work when using the legacy KMS API right?
<sima> javierm, legacy flip is always implied full damage, so that one should work
<javierm> sima: I remember we discussed a similar issue before for https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2979
<sima> it's atomic flip with damage which fails
<sima> javierm, yeah I think we need a new drm_atomic_helper_buffer_damage_merged which handles this case
<sima> probably with a defense "upload everything" approach sadly
<sima> and then roll that out to all the drivers that do damage handling with buffer uploads
<sima> which is a lot of them :-/
<sima> oh we have some drivers which do buffer damage with the iter too, so we'd also need a buffer_damage version of that
JohnnyonFlame has joined #dri-devel
<javierm> sima: yeah, drm_atomic_helper_damage_merged() isn't that smart. jfalempe found that for some drivers with very slow vram copies it could cause perf issues if the damaged rect was almost a full damage
<sima> actually no, I think all the damage_iter users are correct as-is
<sima> javierm, yeah if you upload to vram then do the damage_iter and it will be correct, since that needs frame damage
<sima> but virtio and similar virt drivers need buffer damage
<sima> javierm, from a few quick greps I think only virtio and hyperv need to be fixed
DottorLeo has quit [Quit: Konversation terminated!]
<pq> sounds good to me - is anyone still confused about what frame damage and buffer damage are?
<sima> hm ast cursor maybe also needs buffer_damage
<sima> pq, I think I clued up on it
<pq> I could point to the EGL ext spec that explains it with ascii art
<javierm> pq: which one is that? I would be interested in the ascii art :)
<sima> yeah if we have a good one, putting it into docs as a link would be good
<javierm> pq: that's amazing indeed
<javierm> we need more ascii art in docs
<javierm> sima: are you going to write that drm_atomic_helper_buffer_damage_merged() helper and change virtgpu and hyperv to use it?
<emersion> ^ another resource with pretty pictures
<javierm> emersion: that's super. Thanks!
bmodem has joined #dri-devel
<javierm> *superb
<emersion> np :)
<sima> javierm, probably not ...?
<sima> I should get some lunch, got sidetracked ...
<pq> much nicer pics indeed!
<javierm> sima :) fair, I can give it a shot but unsure if I fully understand what needs to do that helper
<sima> javierm, I'm also not sure anymore whether hyperv needs it
<sima> but ast cursor probably does need it
<jani> agd5f_: hwentlan__: we've got Lyude's review and mripard's ack on merging https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-3-imre.deak@intel.com via drm-intel. we've asked for your acks a week ago, as there's also a small amdgpu diff. any objections? we'd like to move on with this
<javierm> sima: if FB_ID changed then do a full update ?
<sima> ok gm12u320 just freaks me out
<sima> has an async worker
<sima> refcounts the fb
<sima> but the fb_map is in the plane state
<sima> probably a use-after-free race :-(
<javierm> sima: FB_ID changed and no damage rects I mean
<sima> repaper looks like it should use shadow plane helpers, because it just gets it exactly wrong like everyone did before shadow plane helpers got fixed
<sima> javierm, FB_ID changed means full damage irrespective of whether you have clips or not
<emersion> sima, does it?
<emersion> because all compositors will change FB_ID each page-flip with partial damage
<emersion> double buffering etc
<sima> https://paste.debian.net/hidden/5fbbd523/ <- javierm extremely untested
<sima> emersion, yeah drivers that need buffer damage will suffer with this, but it's not worse than before damage clips and we need to fix them first
<sima> the overwhelming number of drivers with damage actually want frame damage, so still a decent win
<sima> plus the drivers with extremely slow upload _all_ want frame damage
<sima> so no regression in the cases where it really matters big time
<sima> javierm, so I think virtio and ast cursor needs buffer_damage and repaper is just busted
<emersion> ok, just saying that this is effectively the same as not having FB_DAMAGE_CLIPS at all, in 99.99% cases
<sima> everyone else looks fine to me
<sima> emersion, yeah but I think it only impacts virtio and ast-cursor for the drivers we currently have in upstream
<sima> so meh
<emersion> i am not aware of any user-space performing front-buffer rendering *and* FB_DAMAGE_CLIPS
<sima> plus in theory we could accumulate frame damage and still optimize this
<emersion> i'd suggest just not exposing FB_DAMAGE_CLIPS at all instead
<sima> emersion, everyone doing DIRTYFB ioctl
<emersion> hm
<sima> which is a pile of legacy stuff
<emersion> i see
<emersion> i was considering atomic only
<sima> like boot splash, -modesetting, ...
<sima> yeah for atomic I guess everyone does flips
<javierm> sima: maybe https://paste.centos.org/view/raw/de5b0f7d then ?
<sima> emersion, also I think if it hurts we can fix this with minimal history tracking of damage and fb
<sima> javierm, yeah, but only for the buffer_damage version of iter_init
<sima> if you do this for everyone emersion will cry
<emersion> :P
<emersion> sima, makes sense to me
<pq> wait, using FB_DAMAGE_CLIPS with atomic flips is useless, the drivers see full frame damage anyway?
<sima> pq, no
<sima> it does work, but it's buggy for drivers who need buffer damage right now
<pq> sima, then I totally misunderstood your: "FB_ID changed means full damage irrespective of whether you have clips or not"
<sima> which is a very small part of all the drivers that support damage (really just one if you ignore cursor ast)
<sima> and the quickest fixes for that one driver is to just go full damage
<sima> pq, yeah, but _only_ for drivers that need buffer damage (which is virtio only I think)
<emersion> pq, that's just an easy unoptimized thing to do in case the driver wants buffer damage
<pq> aah
<emersion> yeah i got scared as well lol
<sima> javierm, oh correction, vmwgfx uses the iter directly and also needs buffer damage I think
<sima> so 2 drivers impacted
<javierm> sima: Ok
<sima> javierm, and I misread ast-cursor, it should be fine (since the buffer in vram is per-plane, not per-fb)
<javierm> I'm going to have lunch now but I will try to reproduce the virtgpu issue on a VM with weston and then give it a try to your suggestion
<sima> yeah same
<sima> and a walk, it's nice&sunny outside
yyds has quit [Remote host closed the connection]
<javierm> sima: enjoy!
<emersion> :D
<sima> javierm, I guess summarized: if the upload target is per plane or per crtc, then you need frame damage and the current code is ok
<sima> if the upload target is per-buffer (like with virtio), then you need buffer damage and we have a bug with the current code
<sima> but it's sometimes a bit tricky to tell from reading driver code
rasterman has quit [Quit: Gettin' stinky!]
<pq> that summary sounds good to me
<pq> if it's per-buffer, you also need "buffer age" or similar damage accumulation algorithm
<pq> soon one might be reinventing Pixman regions
<pq> a single bounding rectangle can become very pessimistic fast
Daaanct12 has quit [Quit: WeeChat 4.1.1]
<pq> but also it's not good to carry myriads of rects in a region, sometimes reducing the number of rects at the cost of enlarging damage is beneficial - that's a problem I haven't seen a solution for yet
<pq> *region struct
rasterman has joined #dri-devel
rasterman has quit []
rasterman has joined #dri-devel
<javierm> sima: awesome. Thanks again
itoral has quit [Quit: Leaving]
Company has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
<emersion> pq, Pixman region is actually not so great
<emersion> mstoeckl had ideas for a better data structure
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
<pq> cool
<pq> with union and intersection operations both?
<emersion> we were mainly interested in union
<pq> I think Weston intersects damage with opaque region etc. to find out the areas to paint with/without blending.
<pq> so there might be use for intersection as well, beyond intersecting with a simple rect
<pq> emersion, is still axis-aligned pieces, or do you go with arbitrary geometry?
bmodem has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kts has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
kts has joined #dri-devel
<Company> pq: in GTK I have something like 16 rects hardcoded and when the rect gets larger I just union the rects
<pq> how do you choose which rects to combine?
<emersion> *all* the rects always combined
<Company> I think I just combine all of them
<pq> ok
<emersion> which may not be great if two opposite edges are updated
<Company> yeah, but how often does that happen?
<Company> that you end up with >16 damage regions on opposite sides
<Company> to be fair, GTK's use case is somewhat different, because we diff the render node tree
<pq> I was once looking at the damage inside Xwayland with old-school X11 apps...
<Company> and when I abort, it's usually half-way through diffing a tree, and then I can bail out and use the bounds of the container node
<pq> or maybe it was a proprietary app... anyway, tiny damage rects all over the screen in the hundreds
<daniels> pq: I think you're talking about the app which ran fullscreen -> Xwayland -> Weston, shipping using pixman-renderer
<Company> pq: https://streamable.com/hw2fob to get an idea how it works in GTK
<pq> daniels, yes, I am
<daniels> that was pretty pathological in a bunch of ways ...
yuq825 has quit []
<pq> emersion, I totally agree that trying upstream new stuff into pixman is not a... how to say it nicely... plan I'd choose. :-)
<emersion> yeah :o
<Company> do you have requirements for float regions?
<emersion> pq, if you ever need, feel free to ping me for reviews there
<Company> because all our stuff is floats, but we round to ints so we can use pixman's regions
<emersion> i don't need floats no
<emersion> for damage it's not very useful
<emersion> easy enough to floor/ceil
Ahuj has quit [Ping timeout: 480 seconds]
<pq> damage can always approximated outwards, opaque regions can always be approximated inwards, and neither in the opposite direction.
<pq> float regions are probably not too useful until everyone has a display with pixels smaller than they can see :-)
<pq> for compositor purposes
<Company> yeah, it's only useful for transforms
<Company> and if you have too many of them
<Company> but I guess even with fractional scaling it's only the final one - and if the boxes are 1px larger than required, so be it
<Company> for opaque regions it's somewhat relevant though
<Company> because you want maximized windows to cover their full area
<Company> and not round wrong and end up with the bottommost line not covered
<pq> Opaque regions can be shrunk freely without causing wrong behaviour. You're right about window regions though.
yyds has joined #dri-devel
jsa1 has joined #dri-devel
<Company> I meant opaque regions covering the whole window
<Company> so you can do direct scanout
<pq> right
<Company> and with 125% or 175% you have odd prime numbers screwing up everyone's math
Mangix has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
xq has joined #dri-devel
<xq> heya o/ I'm working on some pretty low level linux program right now, using DRM via ioctls, and i'm searching for a place to drop some questions on that topic. Is this the right place? If so: There's the DRM_PLANE_TYPE_PRIMARY define, and i can query properties, but how do i know which property is the correct one to use?
Mangix has joined #dri-devel
rasterman has quit [Ping timeout: 480 seconds]
<pq> xq, this is the place. Have you seen https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#kms-properties etc. yet?
pekkari has joined #dri-devel
<pq> xq, properties are identified by their string names. You look for a specific string name, and you'll find the uint64_t that is used to refer to that property on that specific KMS object.
<xq> pq: no, i haven't seen that. googling for the docs is kinda impossible i guess :D
<xq> thanks, this is enough info for me to continue <3
<pq> xq, maybe consider using libdrm. Things are still very low level even with it.
<xq> yeah, i know. but libdrm enforces me to link C :D
<pq> Ok. I don't think you'll find many (any?) examples that didn't use it, though.
<xq> yeah, i'm just reading libdrm sources for reference right now
<xq> so i do a DRM_IOCTL_MODE_GETPROPERTY with drm_mode_get_property, check for the name and if it matches, i found the correct property id, which i then can use always(?) to match to the property without having to query again?
rasterman has joined #dri-devel
<pq> xq, maybe check https://gitlab.freedesktop.org/emersion/drm_info for an example how to read everything for starters?
<pq> xq, the property id is (can be) specific to the object id you queried it from, so don't assume the same property id works for all objects that have the same named property.
<xq> ok
<xq> because i figured that the property often has several objects assigned
flto_ has joined #dri-devel
<pq> an object has several properties, and many objects can have the same property (but different value since it's a different object)
<xq> yeah, that's what i figured
flto has quit [Ping timeout: 480 seconds]
i509vcb has joined #dri-devel
flto_ has quit []
flto has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
greenjustin_ has joined #dri-devel
greenjustin has quit [Ping timeout: 480 seconds]
<MrCooper> pq: hundreds of rects, cute ;) the game in https://gitlab.gnome.org/GNOME/mutter/-/issues/3034 has a SHAPE region with thousands
<xq> pq: drivers/gpu/drm/drm_mode_config.c:232 i think i found what i was searching for. so i can basically only rely on the string "type" in userspace for planes
<pq> MrCooper, eh heh. Well, I'm happy to not need to deal with SHAPE as one cannot simplify that region much, if the launcher looks like what I can guess it might look like.
<pq> xq, correct, that's what I was trying to say. :-)
<xq> thanks for the help. now i can finally remove the hardcoded plane ids :D
<MrCooper> pq: yeah, I'm afraid the only hope there is that Wine is unnecessarily using SHAPE for translucency
<pq> xq, the same name string usage also applies to enum property values, although many older enums may have numbers defined in the headers too. You can always rely on the strings.
<emersion> sway doesn't do the SHAPE stuff and it's definitely causing issues
<emersion> black regions on some game launchers
<pq> I think black regions are an improvement there.
AnuthaDev has joined #dri-devel
<MrCooper> emersion: in this case the main issue seems to be Xwayland itself submitting GPU commands for thousands of rects, some of which are just 1x1
<MrCooper> I guess in principle it would be possible to make this work more efficiently in xserver, for someone who enjoys diving into a huge pile of baroque C code
neniagh has joined #dri-devel
<Company> GTK3 had some code to turn bitmaps into regions
pekkari has quit [Quit: Konversation terminated!]
<Company> because some X API needed a region but we only had a bitmap or so
<Company> you could do the same and turn the region into bitmap
<MrCooper> I was thinking an alpha mask, but yeah
<Company> yeah, just a bunch of memsetting
yyds has quit [Remote host closed the connection]
<Company> I'm reminded of roaring bitmaps
neniagh_ has quit [Ping timeout: 480 seconds]
<Company> they tile the full range and then every tile can be represented either by an actual bitmap, an EVERYTHING/NOTHING flag, run-length encoding and I think those are all the possibilities
<Company> I might be forgetting one
<Company> so you could have a region impl that dynamically switches between the options depending on number of rects
AnuthaDev has quit [Quit: AnuthaDev]
<emersion> sima: so i got my very first dma heap working for vc4. i'm wondering a bit about permissions though
<emersion> if we are to use it from Mesa, we need to be able to open it?
<emersion> right now it's only root-readable
<emersion> is it ok to make it world-accessible by default?
<emersion> or is it not, and we need to come up with something else to pass the heap FD around?
xq has quit [Quit: Leaving]
macslayer has joined #dri-devel
fxkamd has joined #dri-devel
tursulin has joined #dri-devel
<emersion> (funny note, seems like allocating a 4k scanout buffer fails with ENOMEM on rpi4 -- 1080p works fine)
<daniels> cma too small?
<Company> (noticed yesterday that rpi4 is having issues with ENOMEM if I want to use GL and Vulkan at the same time, but didn't investigate that yet)
xq has joined #dri-devel
<emersion> yea probably cma too small
<emersion> daniels, btw if you have thoughts wrt the above, lemme know
<daniels> hmm yeah, about permissions?
<daniels> I'd be tempted to give them all the same perms as rendernodes, on the grounds that you can already allocate infinite memory through those ...
<emersion> yea, but not scanout memory
<emersion> but yeah
<emersion> abusing scanout mem is not so different from abusing regular mem
<xq> pq: thanks for the help, i got it running \o/
fxkamd has quit []
djbw has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
agd5f_ has quit []
agd5f has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
AnuthaDev has joined #dri-devel
ficoPRO10 has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
ficoPRO10 has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
Danct12 has left #dri-devel [A-lined: This user has been AViVA-lined!]
Danct12 has joined #dri-devel
donaldrobson has joined #dri-devel
<enunes> emersion: I've been looking into rpi4 stuff as well, in particular what to do with that wl_drm usage in the v3dv wayland wsi. are you looking into something similar at the moment?
<enunes> in particular it doesn't seem like we can delete it without breaking direct scanout of clients as of now. I tried to delete it and, well, it broke
<enunes> I seem to recall that dma heap was a proposed solution for that
<enunes> from what I understand so far and a chat with leandrohrb5 , the dmabuf feedback implementation in wayland wsi doesn't magically solve it by itself either
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<daniels> enunes: the dmabuf-feedback stuff won't _magically_ fix it, but it does tell you where the compositor's scanout device is, so you can use that to open it and allocate from vc4
greenjustin__ has joined #dri-devel
cmichael_ has joined #dri-devel
<enunes> daniels: so that would mean to just replace the wl_drm driver-specific use with another dmabuf feedback implementation right? and other drivers might still need to do the same?
<enunes> I'm trying to figure out if there's something we can do in the common layer to avoid that, or special cases like v3dv vc4 might still need their own wayland dmabuf feedback code
cmichael has quit [Ping timeout: 480 seconds]
<emersion> enunes: yes, this is what i'm trying to fix
<emersion> i think we could pass a scanout dma-buf heap to the common code and let it do the right thing
<emersion> but yeah, the current behavior of always picking scanout memory isn't very nice
<daniels> well, all the code to collect all the dmabuf feedback stuff is there in the common code - it looks like all you have to do is take the target_device dev_t from dmabuf-feedback (which we already have in wsi_common_wayland) and pull that into v3dv which currently expects an fd
<daniels> bcm isn't special here, it's not the only platform where hitting scanout requires you to allocate from the display device
<emersion> daniels, can't allocate scanout if we're not DRM master
<emersion> dumb buffers are only for DRM masters
<daniels> ... master? that would imply that only the compositor can allocate, so it doesn't really matter what you do in Wayland WSI
<emersion> hm, sorry
<daniels> auth'ed primary node?
<emersion> not master, authenticated primary node
<emersion> yeah
<daniels> right, I thought that got relaxed a few years back so auth was no longer required
<emersion> and that's not the future
flom84 has joined #dri-devel
<emersion> the motivation for not relaxing that is that random clients really shouldn't use dumb buffers
<emersion> hence dma heaps
<daniels> DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl, 0),
<daniels> ^ no AUTH flag there
<daniels> (imagine that reads create rather than destroy)
<daniels> but yeah, I agree wrt heaps being the actual future
<emersion> hm.....
<emersion> why the heck does v3d tries to auth then...
<enunes> it does allocate a dumb buffer currently
<emersion> yeah but it doesn't need the auth stuff
cmichael_ has quit []
<emersion> well, primary nodes may not be accessible at all
<emersion> headless, or systemd-less (systemd will facl the primary node when physically logged in)
frankbinns has quit [Ping timeout: 480 seconds]
jeeeun84135190 has quit []
flom84 has quit [Remote host closed the connection]
<emersion> hm, it doesn't seem like dumb buffers ever required DRM master…
<emersion> (or maybe my git-log fu isn't good enough?)
<enunes> so one thing I'm trying to wrap my head around is, if the dmabuf feedback offers formats known to be good for scanout and a request for allocation, couldn't the common code do the allocation through that and let the compositor handle it?
flom84 has joined #dri-devel
jeeeun84135190 has joined #dri-devel
<enunes> or does this hit a loop if this would go back to the mesa wsi code?
<daniels> enunes: right, it can and does
<emersion> but this calls back into the driver for the actual allocation
<daniels> yep
<daniels> the one thing I can see that's missing is allowing the driver to get the device node for the device the compositor is telling it should allocate for
<emersion> that's not a big deal for v3d, because the display driver will always be vc4
<emersion> might be for others
Company has quit [Quit: Leaving]
<enunes> but then it should be able to allocate even in the other device anyway as long as it's linear etc?
<emersion> except when running (1) on a compositor without wl_drm (2) headless (3) systemd-less
tobiasjakobi has joined #dri-devel
<enunes> I mean, allocate in the gpu device without the trouble to get to the display device
<emersion> (because v3d uses dumb buffers and wl_drm auth)
<emersion> so, no scanout?
glLiquidAcidARB has joined #dri-devel
glLiquidAcidARB has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
<enunes> if it's a format that can be scanned out and with a modifier understood by the display device / no modifiers, should be scanout-able?
<daniels> that usually stumbles on either a) the display controller having a stronger pitch alignment constraint which we currently have no way to communicate, or b) the display controller requiring contiguous alloc because it doesn't have S/G IOMMU
<daniels> I think vc4 fails both
donaldrobson has quit [Ping timeout: 480 seconds]
<enunes> ok fair, so if we had ways to communicate all these constraints, I suppose it would not make a difference in this case which device we used to allocate then
mripard has quit [Read error: Connection reset by peer]
lynxeye has quit [Quit: Leaving.]
<enunes> so I guess it is worth it to try to plug the target device coming from dmabuf feedback into the v3dv wsi code, as well as deleting the authentication, and see if we can remove the wl_drm code this way?
mripard has joined #dri-devel
<daniels> I think that's a great start, yeah
<daniels> and given that it's so hardware-specific, you could just hardcode a particular alignment if you're allocating for vc4
tobiasjakobi has quit []
alyssa has left #dri-devel [#dri-devel]
greenjustin__ has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
mort_6 is now known as mort_
frieder has quit [Remote host closed the connection]
<i509vcb> Are EGLSync and EGLSyncKHR the same object type? I heard apparently in EGL 1.5 EGLSyncKHR became EGLSync but I see no evidence of such a thing in the EGL specification?
<i509vcb> (EGL_ANDROID_native_fence_sync appears to work on plain EGLSync from what I've seen)
frankbinns has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Aura has quit [Ping timeout: 480 seconds]
<emersion> there are aliases yes
<emersion> you should see in the Khronos XML
frankbinns has quit [Ping timeout: 480 seconds]
Aura has joined #dri-devel
flom84 has quit [Ping timeout: 480 seconds]
ficoPRO10 has quit []
iive has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
AnuthaDev has quit []
rz_ has joined #dri-devel
rz has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
crabbedhaloablut has quit []
YuGiOhJCJ has joined #dri-devel
JohnnyonFlame has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<sima> emersion, probably need an allocations service so that a single app doesn't exhaust the heap?
<sima> allowing everyone is a bit much yolo perhaps
<emersion> hm
<emersion> the scope of this work would increase a whole lot
<emersion> plus it's already free-for-all atm
<emersion> and also an issue for regular memory as said above
<emersion> regular GPU memory that is
<emersion> if we do want an alloc service, logind/seatd seem like a natural place… or maybe the compositor directly
<dj-death> karolherbst: not sure if you've played much with reading structures from global memory in rusticl
<dj-death> karolherbst: but looks like like this in OpenCL : VkDrawIndirectCommand param = *(global VkDrawIndirectCommand *)indirect;
<dj-death> karolherbst: that will result in a load to temporary variable in NIR
<dj-death> karolherbst: and lower_io is lowering all of that to scratch load/store
<dj-death> karolherbst: which is ridiculous if you use all those values immediately
<dj-death> karolherbst: maybe you have some special passes to avoid that kind of stuff?
aravind has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<dj-death> ah just don't lower_io temp variables
<dj-death> and use nir_lower_vars_to_ssa instead
heat_ has quit []
heat has joined #dri-devel
<karolherbst> yeah, lower to ssa first
<dj-death> somehow not doing anything :(
<karolherbst> mhhh... weird...
<karolherbst> maybe throw some load propagation at it as well?
<karolherbst> but indirects are also kinda... uh... annoying
<karolherbst> kinda depends on how the shader looks like before io lowering
aravind has quit [Ping timeout: 480 seconds]
Duke` has quit [Ping timeout: 480 seconds]
<jenatali> dj-death: Sounds like you're missing opt_memcpy?
<dj-death> jenatali: no, it's there
<dj-death> looks like I'm getting into those nir_deref_instr_has_complex_use() cases
<jenatali> :(
a-865 has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
<dj-death> yeah it's casting
<dj-death> deref_ptr_as_array too
a-865 has joined #dri-devel
guru_ has quit [Read error: Connection reset by peer]
i-garrison has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
oneforall2 has joined #dri-devel
<jenatali> dj-death: Last time I looked, that ptr_as_array and casting was inserted by memcpy lowering
<jenatali> Which, you should be able to get a field-by-field deref copy through memcpy optimization first
<dj-death> jenatali: thanks, will have another look
apinheiro has quit [Quit: Leaving]
<DavidHeidelberg> eric_engestrom: as u wrote the priority gitlab-runner wrapper, do you think it would be doable something like "if any other runner won't pick job in 30 seconds, use this runner" wrapper?
* DavidHeidelberg moves to #freedesktop w/ this discussion
aradhya7 has quit [Quit: Connection closed for inactivity]
YuGiOhJCJ2 has joined #dri-devel
YuGiOhJCJ has quit [Read error: Connection reset by peer]
frankbinns has joined #dri-devel
djbw has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]