ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
bolson has quit [Remote host closed the connection]
bolson has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
sudeepd has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
rauji____ has quit []
yyds has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
alane has quit []
alane has joined #dri-devel
flynnjiang has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
simon-perretta-img has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
sudeepd has joined #dri-devel
simon-perretta-img has joined #dri-devel
glennk has joined #dri-devel
u-amarsh04 has quit []
amarsh04 has joined #dri-devel
kode54 has quit [Quit: The Lounge - https://thelounge.chat]
kode54 has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
krushia has quit [Ping timeout: 480 seconds]
bolson has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
bolson has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
amarsh04 has quit []
heat has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
u-amarsh04 has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
warpme has joined #dri-devel
RAOF has quit [Remote host closed the connection]
RAOF has joined #dri-devel
coldfeet has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
itoral has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
kts has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
coldfeet has joined #dri-devel
jsa has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
tzimmermann has joined #dri-devel
co1umbarius has quit [Remote host closed the connection]
tristianc6704 has quit []
tristianc6704 has joined #dri-devel
co1umbarius has joined #dri-devel
sudeepd has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Read error: Connection reset by peer]
co1umbarius has joined #dri-devel
yyds has quit []
sima has joined #dri-devel
yyds has joined #dri-devel
bolson has quit [Remote host closed the connection]
bolson has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
kxkamil2 has quit []
kts has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
kxkamil has joined #dri-devel
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
kts has joined #dri-devel
blabberstone has joined #dri-devel
blabberstone has quit [Remote host closed the connection]
jsa has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
jsa has joined #dri-devel
fab has joined #dri-devel
ungeskriptet is now known as Guest4853
ungeskriptet has joined #dri-devel
<pq> sima, I saw your F_ISDUP callout, but I don't think I have any recollection right now about where and why its used. daniels might recall something where we need to check if two fds are dups of each other?
<daniels> not inside the compositor, no
ungeskriptet is now known as Guest4855
ungeskriptet has joined #dri-devel
<emersion> we need for vulkan import
<emersion> but i use a DRM FD, and compare GEM handlers
<emersion> handles
<daniels> yeah, nice
bolson has quit [Ping timeout: 480 seconds]
<daniels> we don't need to dedup GEM handles because we hide behind GBM/EGL to do that for us and give the uniqueness guarantee
frankbinns1 is now known as frankbinns
<daniels> if we were doing it directly, indeed we'd just use a hash table of GEM handles which is iirc what Mesa does
Guest4853 has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
ungeskriptet is now known as Guest4858
<pq> daniels, wasn't there some GBM thing where I complained that something should check for something... thing?
ungeskriptet has joined #dri-devel
<pq> maybe you just fixed that already
<MrCooper> pq: Mesa needs to know if two DRM fds passed in by the app reference the same file description, for correct tracking of GEM handles
<daniels> depends on what 'that' was ...
<sima> I thought there was a case where we needed to compare dma-buf fd for sameness and there was no drmfd around to do the import trick
<MrCooper> doesn't ring a bell offhand
<emersion> i think we always have a DRM FD…
<emersion> would need to check mesa usage…
samuelig has quit [Quit: Bye!]
ungeskriptet is now known as Guest4859
ungeskriptet has joined #dri-devel
samuelig has joined #dri-devel
Guest4855 has quit [Ping timeout: 480 seconds]
gio has quit [Ping timeout: 480 seconds]
<MrCooper> emersion: incidentally, I just thought of the GEM handle comparison trick while taking a shower this morning :) out of curiosity, does wlroots also handle the case where the DRM file descriptions are separate, but the imported GEM handle matches the original one by coincidence?
<emersion> hm, what do you mean?
Guest4858 has quit [Ping timeout: 480 seconds]
Guest4859 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest4863
<MrCooper> even if the DRM file descriptions are separate, the GEM handle of the imported BO may have the same value as the original exported one by coincidence
ungeskriptet has joined #dri-devel
mvlad has joined #dri-devel
u-amarsh04 has quit []
amarsh04 has joined #dri-devel
<emersion> for vulkan we want to know if DISJOINT imports are required or not
<emersion> if two DMA-BUFs represent the same underlying memory, we don't need DSJOINT
<emersion> importing the FDs as GEM handles and comparing these handles is enough for this use-case
<emersion> you're saying that maybe the fiile descriptions are different, but the GEM handles are the same? can this really happen?
<emersion> hm, i suppose mesa might be using kcmp for a different use-case then?
<emersion> trying to figure out whether two DRM FDs are the same file description?
<emersion> i haven't looked at mesa usage
amarsh04 has quit []
Guest4863 has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
<pq> emersion, I think the question is whether you always import on the same DRM device fd, or sometimes on different DRM open files?
<emersion> I have multiple DRM FDs
u-amarsh04 has joined #dri-devel
<pq> GEM handles are specific to an opened DRM device file, aren't they?
vliaskov has joined #dri-devel
<pq> import buffer A on device 1, and buffer B on device 2, you might accidentally get the same number as a GEM handle I think
<emersion> sure
<emersion> for the equalty test, i use the same DRM FD of course
<pq> right, I think that was the question
<pq> so no accidental match is possible
<emersion> ah actually i misremembered
<emersion> i use the DMA-BUF inode number instead
<MrCooper> yep, different use case from Mesa then
<MrCooper> I was thinking Mesa could export a dma-buf from the reference DRM fd, import it into the comparison DRM fd, and compare the GEM handles; if they're different, it's definitely no the same DRM file description, otherwise would need to make sure they don't just have the same value by coincidence though
<sima> emersion, isn't there an older kernel where this kinda fails because it's all the same anon inode underneath all the dma_buf files?
<emersion> i think this would have bad side effects
<pq> if a coincidence could happen, then it can lie both ways: false-match and false-different.
<sima> yeah gem dma-buf fd2handle isn't guaranteed to be cheap
<emersion> MrCooper: importing a DMA-BUF will keep a ref to the memory
kts has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
<emersion> there's no atomic way to know if the import created a new GEM handle or not
<emersion> so you can't close it either
<MrCooper> I know, this would use a BO created for this purpose
<MrCooper> pq: false-different can't happen, importing a dma-buf back into the exporting DRM file description results in the same GEM handle
<pq> I guess I didn't understand what kind of algorithm you're describing. No worries.
<pq> I didn't even understand if you wanted to compare buffers or devices.
<emersion> why does mesa need to compare DRM FDs?
<MrCooper> DRM file descriptions
<pq> I assumed you wanted to compare buffers, because that's what has been talked about.
gio has joined #dri-devel
<MrCooper> emersion: it can get multiple DRM fds from separate API calls, and needs to know if they reference the same DRM file description, for correct tracking of GEM handles
<sima> emersion, just looked, before ed63bb1d1f846 your inode comparison trick doesn't work because all dma-buf share a singleton inode
<emersion> if it's about GEM handle ref'counting, it would be much cleaner to have proper ref'counting in the kernel…
<sima> that was v5.3
<emersion> sima, is there a way to check?
<MrCooper> pq: well the whole thing about comparing file descriptions started with the use case I'm talking about, some 4 years ago
<sima> emersion, create two different buffers, export them, if they have matching inode number then it's the singleton
<emersion> yeah not going to do that
<sima> or just assume that you won't get bug reports from this old kernels
* emersion shrugs
<MrCooper> emersion: maybe, I hope your time machine is working ;)
<emersion> i had no bug report about this yet
<pq> MrCooper, my memory goes back about an hour or two. :-)
<emersion> MrCooper: could be done with import flags or such
fab has quit [Ping timeout: 480 seconds]
<MrCooper> you mean a flag which always creates a new GEM handle on import? I guess that could work
sukuna1 has quit [Ping timeout: 480 seconds]
<emersion> or a flag that increments a counter
<MrCooper> I see
<emersion> always creating a new handle would be simpler, if it covers the use-cases
apinheiro has joined #dri-devel
<MrCooper> I do suspect there might be use cases which need to know if it's the same underlying BO
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #dri-devel
kts has joined #dri-devel
samuelig has quit []
samuelig has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
kts has joined #dri-devel
Company has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
fab has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
pcercuei has joined #dri-devel
<tomba> Is it fine to push fixes to drm-misc-next-fixes, if the fixes are already on drm-misc-next?
f_ has joined #dri-devel
<sima> tomba, needs a "cherry picked from $git_citation" line and a ping to drm-misc maintainers so they're aware because cherry picks tend to cause strange conflicts
<sima> but otherwise fine
<sima> mlankhorst, tzimmermann ^^
<tzimmermann> tomba, please use 'dim cherry-pick'
<tzimmermann> it's usually better to merge fixes into drm-misc-next-fixes or drm-misc-fixes first.
<tzimmermann> we can than backmerge into drm-mics-next
<tzimmermann> tomba, which commit needs to be cherry-picked?
<sima> yeah cherry-picks should be only for misplaced patches, not the default approach
jkrzyszt has joined #dri-devel
<tomba> tzimmermann: 87f36e03c0f1 and c72211751870. I pushed them to drm-misc-next before rc6, but I guess I was still late for the feature freeze.
terrifying31 has joined #dri-devel
terrifying31 has quit [Remote host closed the connection]
heat has joined #dri-devel
<tomba> tzimmermann: do you mean that it's better to merge fixes to drm-misc-next-fixes even outside the feature freeze? or only when in feature freeze, or close to it?
<tzimmermann> tomba, only when in feature freeze
<tzimmermann> tomba, these commits would have deserved to Fixes tag
<tzimmermann> tomba, shall i cherry-pick them into drm-misc-next-fixes. i'd add the Fixes tag then
<tzimmermann> ?
<tomba> tzimmermann: uh that is true. I'm not sure how I missed the fixes tag...
<tomba> tzimmermann: yes please
<tzimmermann> ok
<tomba> Is there a way to know when we are in feature freeze? https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html just says "occurs after -rc6".
<tzimmermann> tomba, -rc6 is the last tag that still receives new features from drm
<tzimmermann> any change must be drm-misc-next (or a similar per-driver tree) in the week before -rc6
<tzimmermann> maybe wednesday at the latest
<tzimmermann> PRs usually go out on thursdays and fridays. -rc6 happens on sunday
<tzimmermann> it's much harder to pick the correct branch during the merge window. i still haven't fully figured that out
<tzimmermann> i think drm-misc-next-fixes closes when the linux release happens
<tomba> tzimmermann: ok. so me pushing fixes on Saturday, and rc6 tagged on Sunday, didn't quite fit in =). but is there a way for me to know, between -rc5 and -rc6, when should I push a fix drm-misc-next and when to drm-misc-next-fixes?
<tzimmermann> before wednesdays, -misc-next is safe
<tzimmermann> mondays after -rc6, it should be drm-misc-next-fixes
<tzimmermann> for the time in between, it's probably best to not push fixes
jnoorman has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
<tzimmermann> dmr-misc-next might be done already, but drm-misc-next-fixes hasn't yet catched up
jnoorman has joined #dri-devel
<tomba> would it be possible to communicate the phase with tags? say, "if branch X has tag Y, but Linus hasn't tagged the final release, it's feature freeze".
<tzimmermann> no idea
<tzimmermann> maybe dim could warn about that
<tzimmermann> tomba, i've cherry-picked the commits
<tomba> tzimmermann: thanks!
<tzimmermann> sure, np
f_ has quit [Quit: To contact me, PM f_[xmpp] or send an email. See https://vitali64.duckdns.org/.]
<pq> I had no idea that epoll would be *that* broken vs fork. OTOH, I believe the only good use of fork is to exec ASAP in the child.
aradhya7 has quit [Quit: Connection closed for inactivity]
<DragoonAethis> pq: Quite a lot of software forks without execve, web servers especially like it
<emersion> sh(1) as well
<pq> DragoonAethis, I guess the first thing they guarantee is that there never is more than one thread is a process?
<pq> *in
<DragoonAethis> Nope, most of them are heavily threaded in worker processes too
<DragoonAethis> Another fun use case: Factorio (factory building game) on Linux can fork off to a separate process to implement non-blocking saving
<pq> DragoonAethis, how do they avoid the twilight zone of needing to be async signal safe in the child?
<pq> IOW, random deadlocks inside e.g. libc
vsyrjala_ is now known as vsyrjala
fab has quit [Ping timeout: 480 seconds]
<DragoonAethis> pq: No idea, but AFAIK fork spawns a single new child thread, and fork explicitly requires you to use async-signal-safe calls only in child processes from that point on: https://www.man7.org/linux/man-pages/man7/signal-safety.7.html
<pq> exactly, so can they pull that off? :-)
<pq> *so how can they
<pq> things like malloc() and fwrite() are no-go there
<DragoonAethis> Hmm, I can't say how web servers etc do it, but I worked on a project once that forked off into worker processes to handle incoming clients
<DragoonAethis> And tbh things just worked, I didn't care much about signal safety and what not, but there was effectively no shared state between the controller/worker processes
<DragoonAethis> It was a C++ project too
<pq> libc probably has some mutexes inside, so if you manage to fork just at the time when any of those mutexes are locked...
<DragoonAethis> It was doing the polling in the controller process and worker processes just got an exclusive handle to work with from that point on
<pq> the thread that locked the mutex won't exist in the child, so nothing will release the mutex
<DragoonAethis> Unless they do some cleanup in the fork wrapper as well
<DragoonAethis> So that the child process automatically does some internal libc cleanup
<pq> somehow I doubt that
<DragoonAethis> Yeah it does that, for a few of these at least
<DragoonAethis> Not all though
<pq> if the clean-up was trust-worthy, then why the requirement for async-signal-safe...
<DragoonAethis> Because libc is a bag of evil no-good APIs that can't be reasonably cleaned up, and somebody just needed to have a Exit Jail Free card in the docs so that proper cleanup did not have to be implemented?
<sima> tomba, tzimmermann I wouldn't worry too much, since if something is misplaced we can fix it with a cherry-pick
<sima> it's a few days out of 2.5 months after all
<pq> or because different libc work differently here
<sima> picking the right branch after freeze seems to be more tricky anyway
<DragoonAethis> >Although POSIX has dropped async-signal-safe requirement for fork (Austin Group tracker issue #62)
<sima> imo worry so much that you delay pushing a fix is worse, since then it might get lost entirely
<sima> and that happened plenty enough
<heat> you only need async-signal-safe if you're forking a MT process, because the lock state (and anything locked) will be messed up
<pq> heat, yeah, and many libraries use threads under the hood.
<heat> the code you're looking at (that releases a bunch of locks) is a best-effort thing, see https://git.musl-libc.org/cgit/musl/commit/src/process/fork.c?id=167390f05564e0a4d3fcb4329377fd7743267560
<heat> basically "we would rather crash rarely vs deadlock consistently"
<pq> DragoonAethis, I think your link is talking about making fork() async-signal-safe. As in, calling fork() from inside a signal handler.
<DragoonAethis> pq: Yeah, you're right, sorry
itoral_ has quit [Remote host closed the connection]
guludo has joined #dri-devel
sukuna has joined #dri-devel
mvlad is now known as Guest4927
mvlad has joined #dri-devel
Guest4927 has quit [Read error: No route to host]
<Company> robertmader[m]: Have you ever tested YUV playback with GTK's Vulkan renderer on non-intel non-amd?
<Company> I'm trying to confirm that this code has seen usage outside of radv
Calandracas has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
yrlf has quit [Quit: Ping timeout (120 seconds)]
sarnex has quit [Ping timeout: 480 seconds]
yrlf has joined #dri-devel
robert_mader has joined #dri-devel
<robert_mader> Company: writing again in IRC, not Matrix...: no, unfortunately not - but I got a RPi5 and soon a RK3588 which should allow me to test it in a while.
<robert_mader> Finally, one could test it on Qualcomm devices when building Gst with https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6114
<robert_mader> Company in theory it should be possible to make things work on Nvidia if we get https://github.com/elFarto/nvidia-vaapi-driver to work with Gst
<robert_mader> Or once the Gst vulkan decoders support dmabuf export
<robert_mader> P.S.: love the image you choose in the issue :)
i-garrison has joined #dri-devel
<Company> I just wanted to know how confident I should be in my code being correct
<Company> so that I know how authoritative I want to come across when arguing with dj-death ;)
<robert_mader> I mean - the fact that Intel is currently broken is evident by the big warning, no?
<Company> yeah, that's not in question
sukuna has quit [Ping timeout: 480 seconds]
<Company> the question is more if GTK is doing the right thing - say if a fix comes up that doesn't work with GTK - is that likely a bug in anv or in GTK
<Company> and if GTK is only tested against radv, it might very well be a GTK bug
<Company> that was the way I was thinking
kts has joined #dri-devel
<robert_mader> Meh, unfortunately it won't be particularly easy to test on other platforms for now. I guess we can't count on panvk to support it, v3dv probably should but the HW decoder on the RPi5 is weird - Qualcomm might be the best bet for now. Assuming that lavapipe is out of question.
<Company> lavapipe can't do dmabufs afaik
<Company> software rendering not doing dmabufs was always one of my big complaints
mvlad has quit [Remote host closed the connection]
mvlad has joined #dri-devel
jsa has quit [Read error: Connection reset by peer]
<DemiMarie> Is there a way to validate a dmabuf from a potentially malicious client, such that if it passes, it won't cause undefined behavior to use it?
<DemiMarie> The use-case is virtualization without copying buffers back to the CPU.
<Company> I would hope so, because that's how flatpak apps render.
imre has quit [Ping timeout: 480 seconds]
lemonzest has quit [Ping timeout: 480 seconds]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #dri-devel
<pq> DemiMarie, I believe there should never be undefined or explosive behavior, it is up to the import API to ensure that.
<pq> DemiMarie, if the dmabuf is a restricted buffer where a wrong access would cause a machine check fault and reboot or whatever, it is the kernel drivers' responsibility to make sure any attempt of such access is prevented before it can happen. IOW, fail the import.
<pq> reality can be lacking and buggy, of course
<pq> DemiMarie, I guess you'd want to have explicit fences, either straight from the client or extracted from dmabuf, so your own rendering won't be stalled.
<DemiMarie> pq: what about shadow compressed state on Intel?
<pq> I dunno, what about it?
<pq> why would it be an exception?
<DemiMarie> I recall some Vulkan API not doing proper validation and potentially causing GPU hangs.
<pq> and you want to work around driver bugs in your userspace program?
<pq> I feel like it should be easier to fix the driver and distribute that instead of coming up with a reliable out-of-driver check.
<Company> you could also just not advertise the critical modifiers (or formats) across process boundaries
<Company> that assumes you know which ones those are ofc
<Company> but flatpak/compositor has that problem, kernel/anything has it, and browser web process/ui process does, too - so it's not just vms
<MrCooper> Company: FWIW, lavapipe supports VK_EXT_external_memory_dma_buf now: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805
<Company> that would mean if I compile me a mesa git and force lavapipe, I should get dmabuf support?
<Company> let's see what happens
<Company> that's also a neat way for testing GStreamer dmabuf negotiation I guess
penguin42 has joined #dri-devel
<penguin42> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29105 says 'pipeline waiting for manual action' - what's that about - it seems to let me click the buttons to kick individual tasks to run
<agd5f> vsyrjala, feel free to add my RB
coldfeet has joined #dri-devel
<Company> MrCooper: hrm, that's still using udmabuf and my udmabuf (F40) is not user-writable
kts has quit [Ping timeout: 480 seconds]
<Company> (or user-readable for that matter)
<MrCooper> udmabuf seems to be the intended long-term solution for this
epoch101 has joined #dri-devel
mvlad has quit [Remote host closed the connection]
mvlad has joined #dri-devel
<MrCooper> jkhsjdhjs: https://patchwork.freedesktop.org/patch/593130/ should fix the SIGBUS issue
jsa has joined #dri-devel
wens has joined #dri-devel
greenjustin has joined #dri-devel
<jkhsjdhjs> MrCooper: yep thank you! I tested the patch on 6.9-rc7 and it seems to work fine
<MrCooper> cool
<cwabbott> ManMower: while looking at this I realized that upstream weston-rdp doesn't work with vulkan because it doesn't support dma-buf
<cwabbott> this seems to work, just copy-pasting the dma-buf stuff from the drm backend (minus feedback and direct display):
<cwabbott> but I have no idea if that's "proper" or not... is there a reason it hasn't been done already?
<ManMower> my guess is that it was just forgotten :)
<ManMower> though maybe it's problematic for multi-backend situations.
<cwabbott> fwiw, on the hw I'm working on there's no GL except through zink
<ManMower> the future is now
<cwabbott> :)
<cwabbott> so no graphics support at all except through dma-buf
<ManMower> most of my rdp testing lately has been multi-backend, so the drm backend would've initted that for me and I'd not have seen that problem.
<cwabbott> we've been using weston-rdp a lot recently because you really don't want to actually use a device like this as your daily driver, and display is often broken
<ManMower> cwabbott: I think that new bit should just be in the switch statement later in that function undeer the WESTON_RENDERER_GL case
<cwabbott> ManMower: is there a reason it's not that way in the drm backend?
<cwabbott> it has a similar switch-case but calls linux_dmabuf_setup() later
<ManMower> drm backend is a "primary backend" exclusively, so it should always be first to init and doesn't have to check
<ManMower> is weston's multi-backend stuff useful to you at all? you can light up the drm output and have the rdp output show the same thing...
<cwabbott> right now my only drm output is a phone display
<ManMower> that is not my preferred way to look at the matrix.
<cwabbott> I don't really want my desktop to have those dimensions...
<ManMower> gotcha
<cwabbott> in general weston-rdp headless is really useful for bringing up stuff when you don't have display working yet, or don't want to dedicate a monitor to the device
<cwabbott> and of course for newer devices it's going to be more and more zink-only, at least at first
illwieckz_ has joined #dri-devel
illwieckz has quit [Read error: Connection reset by peer]
krushia has joined #dri-devel
illwieckz_ has quit []
illwieckz has joined #dri-devel
<vsyrjala> agd5f: thanks. ok if i push that into drm-misc-next?
<agd5f> vsyrjala, yes, please go ahead
sudeepd has joined #dri-devel
<mlankhorst> agd5f: Hey, can I get some discussion going again on cgroups? https://lists.freedesktop.org/archives/dri-devel/2024-May/452150.html
<mlankhorst> Obviously appears to be a need for it
Haaninjo has joined #dri-devel
<agd5f> mlankhorst, sure. Will take a look. Seems like every time we try and do this through, it gets shot down by the cgroups maintainers
kts has joined #dri-devel
kzd has joined #dri-devel
<MrCooper> JoshuaAshton: in wsi_explicit_sync_free_levels[], what's the reason for preferring (WSI_ES_STATE_RELEASE_MATERIALIZED | WSI_ES_STATE_ACQUIRE_SIGNALLED) over (WSI_ES_STATE_RELEASE_MATERIALIZED | WSI_ES_STATE_RELEASE_SIGNALLED) ?
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
rz_ has quit [Remote host closed the connection]
rz has joined #dri-devel
davispuh has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
robert_mader has quit [Quit: Leaving.]
zackr has joined #dri-devel
kts has joined #dri-devel
f_ has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
<penguin42> is the fdo gitlab having a bad day ? I'm getting a 'Permission denied (publickey)' when it was working earlier
<penguin42> oh yeh, I see someone saying it on list
simon-perretta-img has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
lemonzest has joined #dri-devel
bolson has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
rauji____ has joined #dri-devel
<DemiMarie> Is there hope for Linux getting to where Windows is, where there is no implicit sync at all and everything is done via explicit sync?
<jenatali> FWIW, GDI on Windows still operates with implicit sync
jsa has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
<zackr> i'm looking at igt's prime_mmap_kms.c (https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tests/intel/prime_mmap_kms.c?ref_type=heads) which sets up the crtc, then grabs a prime fd for the framebuffer, then calls paint that just mmap's the dma-buf and writes to it, then it seems to expect the framebuffer to magically update (https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tests/intel/prime_mmap_kms.c?ref_type=heads#L226)
<zackr> does anyone know if that's actual dma-buf/kms expected behavior? meaning grabbing a prime fd for the active framebuffer and writting to it is expected to update the screen without any explicit flips in there
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
heat is now known as Guest5003
Guest5003 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
imre has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<MrCooper> DemiMarie: not realistically, we can't break backward compatibility with user space which depends on implicit sync
<DemiMarie> MrCooper: will it ever be possible for userspace that _does_ support explicit sync to be able to use features like userspace fences that don’t have completion guarantees?
<emersion> zackr: that's called front-buffer rendering
<emersion> i'm not sure KMS drivers are required to support it
<emersion> in particular, some KMS drivers might not realize that the buffer changed
<emersion> (especially things like GUD)
<zackr> emersion: yea, i'm not sure if that's the expected behavior. i can do dirty tracking for this stuff for vmwgfx but it's a pain so if that behavior is not expected i'd prefer to avoid it
davispuh has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
jeeeun84135190815 has quit []
<emersion> there's also PSR for instance
<emersion> by "dirty tracking", do you mean FB_DAMAGE_CLIPS and/or the dirtyfb ioctls?
<emersion> or something else?
jeeeun84135190815 has joined #dri-devel
<emersion> i would expect user-space doing front-buffer rendering to flip with the same FB after the buffer has be written to, personally
Kayden has quit [Quit: -> meeting]
simon-perretta-img has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
<zackr> emersion: for vmwgfx "dirty tracking" is a combination of all that plus implicit magic to cover up for the fact that the gem buffer/dma-buf isn't really a gpu buffer but a shadowed copy that will have to be updated (readback if written to on the gpu, upload when changed on the cpu)
simon-perretta-img has joined #dri-devel
<zackr> which is why front-buffer updates are a pain. we need to track the updates, then notice that the given buffer is actually a front-buffer then upload that immediately to be able to present it
<emersion> do you somehow detect that someone did a SYNC_END IOCTL?
<emersion> maybe sima knows what's expected here
<zackr> well, tbh currently we're broken wrt to this (meaning prime and fb updates). for a similar behavior on coherent surfaces we just page-fault on maps, explicitly mark whatever was accessed as dirty internally and then we scan command buffers and if we see that something has been used and is dirty we update it
<zackr> if we had more igt tests for dma-buf/kms/sync's that'd make it obvious. although not sure if we'd want igt to be the reference for expected behavior
<penguin42> (the gitlab ssh seems to have woken up)
<daniels> the prime user for frontbuffer rendering is xserver, though it's not (unless it's got weirder whilst I haven't been looking) mmaping a dmabuf to do that
simon-perretta-img has quit [Ping timeout: 480 seconds]
<zackr> tbh, i'm fishing a little bit. i know the new kde/kwin is broken on vmwgfx and it's definitely dma-buf/prime related. i know that the DRIVER_ANY tests in kms pass on vmwgfx, so i'm just looking at driver specific tests to see if i can dig up something to test that doesn't involve debugging a whole desktop
<emersion> daniels, dumb buffer mmap?
<emersion> wth or without a flip after dirtying the mmap?
<daniels> I think yes, and without
simon-perretta-img has joined #dri-devel
<zmike> linyaa: can you test https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29108 and confirm that it solves your issue
jeeeun84135190815 has quit []
jhli has joined #dri-devel
jeeeun84135190815 has joined #dri-devel
Kayden has joined #dri-devel
<emersion> daniels, do drivers have a way to know when user-space has mutated the dumb buffer?
smpl has joined #dri-devel
f_ is now known as f_|afk
alanc has quit [Remote host closed the connection]
f_|afk is now known as f_
alanc has joined #dri-devel
ity has quit [Remote host closed the connection]
ity has joined #dri-devel
<daniels> emersion: I can't remember if flipping is mandatoary or not tbh
<Company> dj-death: you got the reproducing working for !11125 ?
kaiwenjon has joined #dri-devel
<Company> DavidHeidelberg: your PASS => FAIL thing in !9989 is not related to F39=>F40 which had the change to qsort() behavior in libc?
jsa has joined #dri-devel
<jannau> flipping is not mandatory and it doesn't happen with the modesetting driver. This breaks X applications on apple silicon since the display driver has not vsync interrupt. That results fast animations since everything relies on vsync sequences for timing
<emersion> maybe we should have a CAP for this
<emersion> or… just make user-space flip
<emersion> jannau: does modesetting use dirtyfb oictls?
<emersion> ioctls*
fab has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<DavidHeidelberg> Company: wow. this. Could be the difference....
<Company> yay?
<DavidHeidelberg> now to find, when Debian did it
<DavidHeidelberg> because it worked for me before, but then it stopped (and I'm using testing/unstable)
<DavidHeidelberg> MesaCI is on Debian stable
<DavidHeidelberg> and there it works
<Company> what's Intel CI on?
<DavidHeidelberg> Company: they use apt, but question is which ver
<jenatali> Ugh, qsort has been a nightmare for Windows/MSVC too, causing all kinds of app compat bugs
<Company> jenatali: you get partial credit for that anyway, because you told me about that change back when
<emersion> jannau: so the driver could simulate a flip after the dirtyfb ioictl?
<jannau> since tearfree was merged it even does real flips if the option is enabled
<jannau> yes, we probably could do a page flip after in the dirty update assuming that a flip with the same framebuffer does not confuse the firmware
<dj-death> Company: yeah, but only on TGL/ADL
<dj-death> Company: I already spotted one bug
<dj-death> Company: still digging
<dj-death> DG2+ is not affected
<Company> I am on TGL
coldfeet has quit [Remote host closed the connection]
<Company> but had reports from somewhere else
<dj-death> I assumed, or something older
<Company> yeah
<dj-death> all older ones should be affected in a similar way
<Company> I just assumed everyone is affected because of the debug messages it prints
sukuna1 has joined #dri-devel
<mattst88> Company: what is the qsort behavior change? (is it related to the security issue from a couple of months ago?)
<Company> mattst88: equal items are ordered differently now
<Company> mattst88: I think it's related to https://www.phoronix.com/news/Intel-AVX-512-Quicksort-Numpy making its way into glibc?
<Company> not sure though
gouchi has joined #dri-devel
<mattst88> interesting.
<mattst88> looks like that commit (and the one it references) were both in glibc-2.39
<Company> so they reverted it again?
<janesma> Intel CI is on debian testing
<Company> so that in a year when we're all back to the old sort, MesaCI switches to the broken one?
<janesma> Company ^
<Company> DavidHeidelberg ^
fab has quit [Quit: fab]
<DavidHeidelberg> janesma: I'm on testing/unstable too.. so that would explain it
fab has joined #dri-devel
<Company> so CTS is comparing something as equal where the order actually matters?
<DavidHeidelberg> zmike: what do you run the tests on?
<zmike> define "what"
<DavidHeidelberg> system and version
<janesma> our docker containers have libc-bin/testing,now 2.37-15 amd64 [installed,automatic]
<zmike> f39
<Company> Fedora 39 has glibc 2.38 and the change was in glibc 2.39 I think which is Fedora 40
<janesma> DavidHeidelberg: isn't the pbuffer config selected at deqp compile time? we build with -DDEQP_TARGET=x11_egl
<DavidHeidelberg> I used x11_egl locally. I'll try to build it with mesaci config
* janesma expected recompiling deqp was the action that changed the behaviour
<zmike> I'm not using surfaceless locally
* janesma attempted pbuffer/surfaceless in the distant past and found that the configs were *not* the same
<zmike> but if it really is a glibc change breaking this then...
<DavidHeidelberg> ..then we'll need fix CTS :D
<janesma> it would be lovely if we didn't have to launch X, but the test suite was not in a position to test without it.
<DavidHeidelberg> janesma: you can use weston + xwayland :) in MesaCI it's usually less buggy than X
<Sachiel> it runs into the same issues as plain x
<DavidHeidelberg> janesma: hmm, nope, I build it as MesaCI and still getting the fail
<Company> zmike: time to dnf install --releasever=40 glibc and find out!
<zmike> that sounds like a project for tomorrow's me
fab has quit [Quit: fab]
fab has joined #dri-devel
* DavidHeidelberg section: dark humor; task: break previously working stuff
mbrost has joined #dri-devel
frieder has quit [Remote host closed the connection]
iive has joined #dri-devel
<penguin42> looks like the panfrost-g52 in CI is toast
<daniels> penguin42: it's been disabled
<dj-death> Company: fixed
<dj-death> Company: will upload the MR shortly
fab has quit [Ping timeout: 480 seconds]
<dj-death> let it be known I used the most advanced debug tool to find the issue : printf
<Company> debugging video is like that
alyssa has left #dri-devel [#dri-devel]
coldfeet has joined #dri-devel
davispuh has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
davispuh has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
* DemiMarie wonders if all libcs should just use block sort
davispuh has quit []
<Company> POSIX should just demand a stable sort
<penguin42> daniels: Ah, thanks; do I need to do anything with a pipeline in which it's already failed?
jkrzyszt has quit [Quit: Konversation terminated!]
<DemiMarie> Company: yup, and block is a stable in-place comparison sort, hence my suggestion.
jsa has quit [Ping timeout: 480 seconds]
rsalvaterra has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
f_ has quit [Quit: To contact me, PM f_[xmpp] or send an email. See https://vitali64.duckdns.org/.]
DavidHeidelberg has quit [Remote host closed the connection]
rsalvaterra has joined #dri-devel
DavidHeidelberg has joined #dri-devel
<DavidHeidelberg> Company: I tried downgrade to 2.38 without patches and sadly it still failed
<Company> boooo
<daniels> penguin42: nope, just reassign
<penguin42> daniels: Thanks
<daniels> np
rasterman has quit [Quit: Gettin' stinky!]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<Company> DavidHeidelberg: just to make sure: nothing of those tools are statically linked, or?
kugel has quit [Remote host closed the connection]
samuelig has quit [Quit: Bye!]
samuelig has joined #dri-devel
mvlad has quit [Remote host closed the connection]
kugel has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
kasper93 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
kugel is now known as Guest5067
kugel has joined #dri-devel
Guest5067 has quit [Ping timeout: 480 seconds]
kugel has quit [Quit: Lost terminal]
imre is now known as Guest5071
imre has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<DavidHeidelberg> Company: rebuilt mesa and GL-CTS with 2.38-1 package and still failing
<Company> then I'm sorry to have wasted your afternoon
<Company> it was a good idea at least
<DavidHeidelberg> well, it's not like we have idea where is the issue :D so every idea can be the right one
sima has quit [Quit: Leaving]
sima has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
sima has quit [Ping timeout: 480 seconds]
sukuna has joined #dri-devel
<DavidHeidelberg> so, for me and Intel, it's the GL-CTS which doesn't validate it correctly
<DavidHeidelberg> I checked against modified eglinfo https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/176 and the output is correct, but GL-CTS expectation is ... suddenly wrong
<DavidHeidelberg> Is there someone with exhaustive ability to see if there is something uncertain within this patch: https://github.com/KhronosGroup/VK-GL-CTS/commit/88ba9ac270db5be600b1ecacbc6d9db0c55d5be4 ?
<DavidHeidelberg> SOMETHING has to be undefined or random enough, when it gets compiled in one set, it validate correctly, but fails when compiled with different options/libs/arch/whatever
<DavidHeidelberg> From my examination, the "Expected" state seems to ignore this patch 100%. While the "Got:" part seems to be correct (at least regarding to EGL_CONFIG_SELECT_GROUP_EXT behaviour
kzd has quit [Quit: kzd]
sukuna1 has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: -> home]
<Sachiel> what test fails?
<DavidHeidelberg> ok, I think I have it. the GL-CTS check for the extension, and if it's not there, it completly ignores it
<DavidHeidelberg> sample one: ./modules/egl/deqp-egl -n "dEQP-EGL.functional.choose_config.simple.selection_and_sort.buffer_size"
<DavidHeidelberg> but whole group fails
<DavidHeidelberg> So in my build I don't see EGL_CONFIG_SELECT_GROUP_EXT exposed anymore
<Company> DavidHeidelberg: Not that I want to beat a dead horse - but that's C++ and using std::sort() - did libstdc++ have a similar issue maybe?
<jenatali> std::sort isn't guaranteed stable, there's std::stable_sort if you want stability
<Company> yeah, that's what I was about to suggest
<Company> switching to std::stable_sort for testing
smpl has quit [Ping timeout: 480 seconds]
<DavidHeidelberg> I see EGL_KHR_debug (one line above), but I don't see EGL_EXT_config_select_group
<Sachiel> how does that work? Does the driver the X server is using need to know about the extension too or is just a client thing?
guludo has quit [Quit: WeeChat 4.2.2]
<DavidHeidelberg> ... or maybe it always worked with GLVND disabled, but not enabled. We'll see after compilation finishes
<DavidHeidelberg> YUP. GLVND on/off is the difference.
<DavidHeidelberg> because with GLVND on it doesn't report the extension. So GL-CTS says.. I don't care... and this tests fails
<Sachiel> the test should probably check for the extension then
<DavidHeidelberg> it does.
<DavidHeidelberg> But mesa compiled with GLVND won't report it
<DavidHeidelberg> I verified I run with correct mesa, formats are listed, but the EXT is not reported
<DavidHeidelberg> that's why it worked for some people and setups.. where GLVND was not used
<zmike> so glvnd needs to explicitly add support for this or something?
<Company> sweet, progress!
<Sachiel> what happens with the cts for anything that doesn't support the extension?
<DavidHeidelberg> I need to figure out, why the extensions is not added there, the processing is different than on non-GLVND workflows
<DavidHeidelberg> Sachiel: it just do the test old way
<DavidHeidelberg> with the extension, the GL-CTS account for our extension for the sorting of visuals (so allows us put some extra visuals at the end of the list)
<DavidHeidelberg> but without EXT, it would scream and say there is some irregularity, as it does now for GLVND
<Sachiel> ah, the failure is the cts thinking there's no extension while the driver is using it, ok
<Sachiel> GL land is fun
<DavidHeidelberg> I though GLVND may strip last string from the array (something like \0 problem), but it seems to not to be the case (as I added extra entry which is not accounted anyway in GLVND mode)
<DavidHeidelberg> :D
<zmike> 🤕
<DavidHeidelberg> janesma: btw. maybe you could disable GLVND for CI, do you find some usefulness there?
sassefa has joined #dri-devel
<zmike> well it SHOULD work with glvnd
<zmike> what's going on there?
<karolherbst> this reminds me of the issue, that some applications used a fixed max buffer for the ext string and at some point mesa reported too much
<Sachiel> maybe someone should write GL_EXT_report_extensions_in_a_sensible_manner
kzd has joined #dri-devel
<DavidHeidelberg> interesting, I compiled mesa without glvnd, now with and I see both extensions (I added one extra).
<DavidHeidelberg> I removed the extra one EXT I added for testing, recompiled. Nothing, still see it. re-run meson setup, recompiled, still see it
<DavidHeidelberg> maybe I need to study glvnd a bit more, but still that's weird it happens also in Intel CI then, because it should be a clean build
sukuna has quit [Remote host closed the connection]
sukuna has joined #dri-devel
<zmike> seems like they use glvnd
<zmike> if it's failing
<DavidHeidelberg> that's for sure
<DavidHeidelberg> thats why asked janesma whats their motivation to use it in CI for one vendor one driver
<Sachiel> to test what distributions will use
<airlied> yeah we should probably prefer glvnd testing
<airlied> since I don't think anyone actually ships non-glvnd configuratios
sukuna has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
glennk has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
riteo_ has joined #dri-devel
riteo has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
iive has quit [Quit: They came for me...]
<DavidHeidelberg> I opened https://gitlab.freedesktop.org/glvnd/libglvnd/-/merge_requests/294 I hope it's right place, so far for GLVND builds enabled, I haven't found a way how to sneak it there than add it into GLVND
<janesma> thank you for investing the time to get to the bottom of this.
<DavidHeidelberg> good thing is, it'll work even without new glvnd, but the system will not know about it (generally no test was failing except the sort, so it shouldn't matter to real-world apps)
<DavidHeidelberg> janesma: thank you for helping :)
simon-perretta-img has quit [Ping timeout: 480 seconds]