ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<jekstrand>
airlied: May go back to crucible
<jekstrand>
airlied: I know ANV supported it for a while, mostly because we were lazy in crucible.
<jekstrand>
And maybe the spec allowed NULL pools?
<jekstrand>
Anyway, not a thing these days.
mattst88 has quit [Quit: leaving]
mattst88 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
stuart has quit []
<airlied>
cool I burned it out anyways
<HdkR>
How does mesa determine a wine game for application profiles?
<HdkR>
Does the wine preloader shunt itself out of memory so it can replace the `/proc/self/exe` FD?
<airlied>
I think it justs overwrites argv[0] at a guess
<HdkR>
Mesa can pull in argv[0]?
pnowack has quit [Quit: pnowack]
<anarsoul>
are there any known issues with src/mesa/state_tracker/st_cb_drawpixels.c:draw_stencil_pixels()?
<airlied>
HdkR: util_get_process_name is the place to start pulling the therad
<zmike>
jekstrand: did you have a counter-proposal for dmabuf creation or were you just doing a drive-by? your scenario isn't one that I was intending to target in this MR, but if it's simple enough...
<airlied>
I think you have to use udmabuf to get a real one
<zmike>
yeah, that's what I thought too, but I'm not necessarily looking to handle doing that if there's no demand for it
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
mbrost__ has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
<HdkR>
airlied: Alright, I'll have to check on that. I want to make sure I don't break that
<HdkR>
`TheWond:disk$0` I'm assuming mesa managed to nab it based on this thread name
<HdkR>
Mostly want to make sure I nab the executable name the same way so I don't manage to heck things up
<HdkR>
(If I can, early initialization versus late initialization)
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
idr has quit [Quit: Leaving]
mhenning has joined #dri-devel
* airlied
stops channelling his inner jekstrand for today, all the common code I can find :-P
<zmike>
are you really channeling him if you haven't even written a compiler
gpiccoli has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
<airlied>
zmike: just cleaning up jekstrand, not compiler writing :-P
Company has quit [Quit: Leaving]
<zmike>
I suppose you wouldn't want to take too much of his work
gpiccoli has joined #dri-devel
zackr has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
mhenning has quit [Quit: mhenning]
neonking_ has quit [Remote host closed the connection]
neonking_ has joined #dri-devel
<anarsoul>
I think I found what's the issue with piglit fbo-depthstencil drawpixels on lima (and vc4, v3d and older freedreno)
<anarsoul>
u_transfer_helper calls its flush_region() which does a blit from still mapped resource without doing a flush_region() for this resource
<anarsoul>
it works for resources that don't use staging buffer for transfer (e.g. for lima with tiling disabled)
<anarsoul>
but as long as there's a staging buffer it breaks
<anarsoul>
because the CPU didn't copy staging buffer back to the resource
mclasen has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
krushia has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
tzimmermann_ has quit []
bmodem has joined #dri-devel
Duke`` has joined #dri-devel
mbrost has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
bmodem has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
sdutt_ has joined #dri-devel
sdutt has quit [Remote host closed the connection]
sdutt_ has quit []
sdutt has joined #dri-devel
slattann has joined #dri-devel
slattann has left #dri-devel [#dri-devel]
slattann has joined #dri-devel
itoral has joined #dri-devel
lemonzest has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
wvanhauwaert has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
smaeul has quit [Read error: Connection reset by peer]
smaeul has joined #dri-devel
K`den has joined #dri-devel
Kayden has quit [Read error: Connection reset by peer]
flacks_ has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
<emersion>
jekstrand: no, gbm wouldn't work for me
<emersion>
it's an optional dep
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<emersion>
(so is vulkan)
gouchi has joined #dri-devel
gouchi has quit []
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
K`den is now known as Kayden
tzimmermann has joined #dri-devel
frieder has joined #dri-devel
alanc has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
ahajda has joined #dri-devel
itoral has quit [Remote host closed the connection]
tursulin has joined #dri-devel
itoral has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
srslypascal has joined #dri-devel
MajorBiscuit has joined #dri-devel
MajorBiscuit has quit []
MajorBiscuit has joined #dri-devel
tanty has quit []
tanty has joined #dri-devel
pjakobsson_ is now known as pjakobsson
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<javierm>
emersion: as airlied said, I think the least bad option would be a cap in a render node
<javierm>
emersion: I suggested in the past for the DRM core to fill a DRIVER_HAVE_SYNC_IMP_EXP cap or something
<emersion>
yea
jkrzyszt has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
danvet has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<MrCooper>
emersion: it is a bit surprising though that the decision whether or not to expose the explicit sync Wayland protocol cannot be based on the backend capabilities
<emersion>
it's not about the backend here
<emersion>
it's about the renderer
<emersion>
and it's very arbitrary
<emersion>
oh, and not just renderer
<emersion>
renderer + allocator
<MrCooper>
aka backend :)
<emersion>
nah
<emersion>
wlroots backends just display buffers and nothing else
<emersion>
they can't allocate buffers, they can't render
<MrCooper>
alright, s/backend/renderer + allocator/ then
<emersion>
it's like having a function which checks if a string contains a space, but it needs to also operate on a temporary directory for some reason
<emersion>
it just doesn't make sense to encode this in the API
<emersion>
mutter/kwin/weston/etc are fine because they don't expose this kind of API, it's all internal
<MrCooper>
but a layering violation where frontend-ish code does backend-ish things is better? :)
JohnnyonFlame has quit [Read error: Connection reset by peer]
<emersion>
i don't see the violation
lynxeye has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<pq>
emersion, danvet, I feel that the cursor hotspot discussion is starting to unravel, so hopefully I can step away soon.
* emersion
would rather not step in again tbh…
<emersion>
thanks for defusing that discussion
<emersion>
defusing?
<emersion>
hm, not quite the word i was looking for
<pq>
jekstrand, re: dmabuf ioctls; I guess you already looked at VGEM for creating dmabuf for tests and it doesn't work for some reason?
<emersion>
VGEM is not widely available
<pq>
jimjams, oh hi! I forgot to say hi, I did mean to. :-)
<pq>
emersion, oh, the test question was not about a test suite like igt?
<emersion>
ah, no :P
<pq>
alright
<emersion>
it was about checking whether a DMA-BUF IOCTL is supported by the kernel
<emersion>
at compositor init time
<pq>
yeah, that's the other discussion I've been following with half an eye
<emersion>
> Jason “I’m literally writing an NVIDIA compiler as I read your blog post” Ekstrand
<javierm>
now that I understand the problem better I think that's reasonable for them to use the aperture helper
rasterman has joined #dri-devel
jagan_ has quit [Remote host closed the connection]
Daanct12 has quit [Remote host closed the connection]
jimjams has quit [Quit: Connection closed for inactivity]
saurabhg has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
pepp has quit [Read error: Connection reset by peer]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
lemonzest has joined #dri-devel
itoral has quit [Remote host closed the connection]
bmodem has joined #dri-devel
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
rpigott has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
mclasen has joined #dri-devel
rkanwal has joined #dri-devel
itoral has quit [Remote host closed the connection]
sdutt has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
pixelcluster has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
tzimmermann has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
tarceri has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
saurabhg has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
rpigott has joined #dri-devel
devilhorns has joined #dri-devel
<tzimmermann>
danvet, is it ok to cherry-pick from misc-next into misc-fixes ?
itoral has quit []
aravind has joined #dri-devel
<tagr>
does anyone know if primary planes are assumed to be restricted to one CRTC? conversely are CRTCs allowed not to have any primary planes? Tegra for example doesn't have planes that are restricted to one particular CRTC, so right now we expose them all as "overlay" planes and only redirect the CRTCs .primary pointer to one of them, but ultimately they are all exposed as OVERLAY to userspace
aravind has quit []
aravind has joined #dri-devel
<tagr>
another option would be to artificially statically assign one plane to each head and emulate classic primary overlays, but that would mean that those can no longer be arbitrarily assigned and might reduce the amount of overlays for single-CRTC use-cases
<emersion>
tagr: each plane has a possible_crtc bitmask
<tagr>
unless perhaps if primary planes can also be shared among multiple CRTCs, which I guess comes with its own challenges (how do you steal it from another CRTC if you request it for a new one)
rasterman has quit [Quit: Gettin' stinky!]
<emersion>
hmm
<tagr>
emersion: yeah, I'm aware of that, but the question is how sensible it is to set multiple bits in possible_crtcs for a primary plane
<tagr>
I know it's technically possible, but it also means that one CRTC could request all primary planes, which means that trying to light up a new CRTC with "its" primary plane could fail because that plane is busy
<emersion>
hm i guess that device has a single CRTC even if the bitfields are set to 0xFF
<emersion>
that's fine
<emersion>
you can just fail the atomic commit
<emersion>
hm wait
<emersion>
i got confused: that's fine but for a different reason
<emersion>
a plane can only be attached to a single CRTC
<emersion>
via the CRTC_ID plane prop
<emersion>
hm no confused again, not quite what you're referring to
<pq>
There are many more reasons why one existing CRTC using lots of planes can prohibit a new CRTC from lighting up. Ideally userspace then retries with the old CRTC reduced to minimum plane usage. I'm not sure if anyone actually does that.
<pq>
but that's what userspace should do
<emersion>
anyways, i've already seen drivers with more than 1 bit set in possible_crtcs
<emersion>
for primary plane
<tagr>
ah... okay
<emersion>
i can't find the drmdb again sadly
<pq>
yeah, any kind of plane, even primary, with multiple bits set for possible crtcs should be fine (fingers crossed)
<tagr>
would it also be okay for a driver not to expose any primary planes? should userspace always be prepared to fall back to overlay planes if it can't find a primary plane?
<pq>
userspace may commonly assume that a CRTC cannot the lit without exactly one primary plane.
<tzimmermann>
tagr, i think kernel drm itself is supposed to deal with no-primary/multiple-primary planes. there is legacy code/drivers/ioctls that don't take it too well
<tzimmermann>
the crtc.primary field is still in use in several helpers and drivers, even though it's deprecated
<emersion>
tagr, not exposing any primary plane would confuse user-space too much
<tzimmermann>
tagr, if you find something and can clean it up, go for it
<emersion>
but it'
<emersion>
s just about the plane type
<emersion>
see the link above:
<emersion>
> All drivers should provide at least one primary plane per CRTC to avoid surprising userspace too much.
<tzimmermann>
tagr, as emersion just said, userspace will probably expect a single primary plane on each crtc
<tzimmermann>
anything is confusing
<tzimmermann>
anything else
<pq>
*at least* one
<emersion>
but yeah, it's fine to have 3 CRTCs, 3 primary planes, and possible_crtcs set to 0b111
<emersion>
for all of these primary planes
<pq>
the plane types are just to help userspace find an accepted configuration with less trial-and-error
<tagr>
and it's fine if an application then uses more than one primary plane for one CRTC if it runs out of overlay planes?
<emersion>
yes
<pq>
I'm not quite sure what "runs out of overlay planes" means, but yes regardless.
lemonzest has joined #dri-devel
<tzimmermann>
tagr, what does 'multiple primary planes for one crtc' mean? the primary plane is supposed to be the background and at least as large as the display and not movable. there can really only be one. why would you expose more?
<pq>
that ^ is what userspace usually assumes
<tagr>
pq: well, I was assuming that applications would typically go and grab any primary plane that works on the CRTC that they want to set up and if they want to display something in an overlay they would traverse the list of overlay planes and use them, and the question is whether they could also use primary planes if they run out of overlays if those primary planes work on the CRTC (via possible_crtcs)
<tagr>
tzimmermann: it wouldn't necessarily be multiple primary planes per CRTC, but multiple primary planes that can be reassigned among different CRTCs
<pq>
tagr, apps, probably wouldn't try to use more than one primary plane on a CRTC, but no-one forbids trying.
<tzimmermann>
tagr, i see
<tagr>
on Tegra all planes are equal, really, and they can be arbitrarily reassigned
<tagr>
to any of the CRTCs in the system
<tzimmermann>
tagr, have you ever tried to expose only overlay planes?
<tagr>
one particular system for example has 4 CRTCs and 6 planes, each plane would have possible_crtcs = 0xf
<tagr>
tzimmermann: yeah, that's exactly what I'm doing now
<pq>
tagr, right, so if you N CRTCs, then label N planes as primary and then rest as overlay, and set them all to have possible_crtcs as all CRTCs.
<pq>
*if you have
<tzimmermann>
tagr, tegra-based systems might not run X very often. so your chances are above average ;)
<tagr>
tzimmermann: I've actually run X on these devices fairly regularly and that seems to work fine
<pq>
that's what I think is the best compromise between likelihood of working and flexibility
Company has joined #dri-devel
<tzimmermann>
oh!
<tagr>
but it's apparently confusing some applications
<tagr>
pq: yeah, given this discussion I think so too
<tzimmermann>
tagr, what are you applications? i think only the display manager should care
<tagr>
tzimmermann: I should mention though that we also cheat a little by pointing crtc->primary at one of the overlay planes
<tzimmermann>
tagr, that makes sense to me
<pq>
you could also advertise a hw plane as both primary and overlay planes, and then reject the atomic commit if you get overbooked. :-)
<tagr>
tzimmermann: which should ensure that the legacy IOCTLs all work
<tzimmermann>
IOW x11
<tagr>
pq: heh... that'd be an interesting experiment... but would also mean coding a few extra checks that the core now takes care of
<tagr>
tzimmermann: it's been a long time since I looked at the modesetting driver code, but I think it uses universal planes nowadays when supported
<emersion>
that was reverted i think?
<tagr>
I'll go check what that implements for missing primary planes
<emersion>
maybe it got added back since then
<danvet>
tzimmermann, yeah
<danvet>
tzimmermann, re cherry-picking
<tzimmermann>
danvet, thanks
<danvet>
only thing really is to reference the commit in -next so that when there's a conflict, there's enough hints to figure out what should be done
<danvet>
and why the conflict exists
<danvet>
git tends to be confused when you have mostly different commits, but some cherry-picks
rasterman has joined #dri-devel
<danvet>
tzimmermann, dim cherry-pick might be useful as a helper
<danvet>
I'm not sure how much it's too tied to the drm-intel.git cherry-pick process though, but maybe if that's the case we should fix that :-)
<tzimmermann>
tagr, IIRC the kernel has code to disable atomic modesetting to the X server. that could make crtc.primary a hard requirement for X (not sure though)
<tzimmermann>
danvet, i'll try. i have a fix that is different in drm-misc-next and upstream. so i wanted to fix drm-misc-next first and then cherry-pick into -misc-fixes
<tagr>
tzimmermann: that's only for atomic modesetting, not for universal planes
<tzimmermann>
ah, ok
<tagr>
but I think newest X servers override that by setting the capability to 2, which signals that it's "fixed" X userspace
<tagr>
hm... actually that doesn't seem to be the case
<tagr>
I think we had discussed it at some point, but looks like that was never implemented
<danvet>
tagr, the problem is no one wants to actually put in the work to fix it
<danvet>
so it's easier to just fix xwayland and run on some reasonably good wayland compositor
<danvet>
also given that there's no xserver releases really anymore there's really not much point
<emersion>
does it really matter though?
<emersion>
would xserver really benefit from atomic?
<tagr>
danvet: yeah, I vaguely recall having this discussion some 1 or 2 years ago...
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
vup has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Akari has quit [Read error: Connection reset by peer]
pepp has joined #dri-devel
Akari has joined #dri-devel
bmodem has quit [Remote host closed the connection]
chaim has joined #dri-devel
sdutt has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
<orbea>
danvet: there are still a lot of users using X11 and wayland may never be an option for them regardless if they want it or not
konstantin has joined #dri-devel
<MrCooper>
the vast majority of users wouldn't be able to tell the difference
<MrCooper>
(a former co-worker ranted how he couldn't use Wayland because this and that, then it turned out he'd been unknowingly using Wayland for some time :)
<orbea>
MrCooper: lot of wms don't work with wayland and no one is every going to update to do so
<orbea>
*ever
<orbea>
at least some cases this would require a full rewrite
<MrCooper>
those are either niche already, or will be if they don't make the jump
<orbea>
individually they are niche, but given enough niche choices and you got a relatively larger user pool.
<danvet>
orbea, people can step up to maintain X too
<danvet>
where "maintain" means actual feature development, not just small bugfixes and point releases
<orbea>
If there is no one who has the energy, time or knowledge to rewrite several dozen finished and working wms then who is going to maintain X11?
bmodem has quit [Ping timeout: 480 seconds]
<danvet>
orbea, in that case things will keep working just exactly as it has
<danvet>
we tend to be pretty good at backwards compat
<danvet>
but new fancy stuff is out
<orbea>
yea, that is my concern. Eventually there will be a lot of new fancy stuff with no way for people to use that without entirely chaing their workflow
<orbea>
*changing
<jekstrand>
zmike: I really don't get why you want to give out a FD that isn't a dma-buf and claim it's a dma-buf. The reason why VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT exists is to guarantee that the exported thing is a dma-buf and therefore compatible with everything else that can consume dma-buf. What you are exposing is clearly not that.
<jekstrand>
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT, however, only guarantees that it's a FD which can be dup()'d and imported back into the same driver. That's exactly what you've implemented.
<zmike>
so that's what all the typing was
<jekstrand>
emersion: Bummer.
<danvet>
tagr, read your scroll back on your 6 planes for 4 crtc, arbitrarily assignable
<jekstrand>
emersion: Would it be a reasonable dep to require if the client wants sync_file support?
<jekstrand>
zmike: :P
<danvet>
essentially apps are supposed to walk over crtc and primary planes in lockstep to figure out how they map
<danvet>
which /should/ be the only confusing thing
<danvet>
otherwise possible_crtcs and the Z property (forgot the name) should be all a compositor needs
srslypascal is now known as Guest1564
srslypascal has joined #dri-devel
<emersion>
zpos
<jekstrand>
pendingchaos, zmike: Should the SSBO deref MR be back-ported? Is there an observable bug being fixed?
Guest1564 has quit [Ping timeout: 480 seconds]
<zmike>
jekstrand: it fixes copy_prop and copy_prop_vars passes
<emersion>
jekstrand: i mean i won't die on this hill…
<emersion>
but tbh wondering whether i should really care about explciit sync again
frieder has quit [Remote host closed the connection]
<jekstrand>
zmike: Ok, I'll tag it all stable
frieder has joined #dri-devel
<jekstrand>
emersion: Yeah, but gregkh appears willing to. 😂
idr has joined #dri-devel
<emersion>
lol
<jekstrand>
emersion: Generally, as much as I'd love to see explicit sync demoed with sync_file before we go all the way to UMF, I totally get it. It's a giant pain right now to get it right. I'm happy for now if we can just get the Vulkan drivers off of their busted workarounds and we don't need fancy detect stuff for that.
<emersion>
i might end up just doing the kernel string comparison
<emersion>
yes, it will break sometimes, but i don't care
<jekstrand>
Yeah
<jekstrand>
It shouldn't actually break. That would be a uAPI guarantee violation. It will just not detect backports which is fine.
<emersion>
in theory a distro could ship a revert for that patch i guess?
<emersion>
but not sure why they'd do that
<jekstrand>
Yeah
<jekstrand>
That would be bad
<emersion>
but yeah, i prefer to do bad hacks internally, than do bad hacks *and* encode the hacks in my API :P
<jekstrand>
That's fair, I guess.
<emersion>
so yeah, tl;dr ship it!
<jekstrand>
Ok
<jekstrand>
danvet: ^^
konstantin has quit []
heat has joined #dri-devel
<danvet>
jekstrand, emersion has drm-misc commit rights?
<danvet>
can I feel lazy and useless pls?
<emersion>
sure
<jekstrand>
Woo!
<jekstrand>
I should go finish editing my blog post
<emersion>
alright, pushed drm-tip as well, let me know if i missed something
<jekstrand>
danvet: Do I need to wait for a drm-misc-next -> drm-next merge for the Mesa patches?
<danvet>
oh just merge conflict, I was worried for a sec that we screwed up the uapi
<danvet>
imo no, but airlied has been more worried in the past
camus has joined #dri-devel
jimjams has joined #dri-devel
jkrzyszt has joined #dri-devel
<danvet>
bnieuwenhuizen, do I need to read that entire big thread on your amdgpu patch set?
tarceri_ has joined #dri-devel
tarceri has quit [Read error: Connection reset by peer]
jkrzyszt has quit [Ping timeout: 480 seconds]
<anarsoul>
zmike: do I need to wait for another r-b for !16923 or it's good to go?
<danvet>
mlankhorst, mripard tzimmermann pls make sure drm-misc-fixes is on -rc1
<danvet>
helge deller probably going to push a few fixes
<zmike>
anarsoul: Kayden can probably take a look
<anarsoul>
zmike: OK, I'll wait for him to take a look
camus has quit [Ping timeout: 480 seconds]
slattann has quit [Quit: Leaving.]
saurabhg has quit [Ping timeout: 480 seconds]
rkanwal has quit [Quit: rkanwal]
konstantin has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
gouchi has joined #dri-devel
rkanwal has joined #dri-devel
iive has joined #dri-devel
nvishwa1 has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
saurabhg has joined #dri-devel
Akari has joined #dri-devel
<mripard>
danvet: on it
<danvet>
mripard, thx
<danvet>
mripard, I also jumped onto the devm bridge discussion
<danvet>
if you want maybe best to discuss it here quickly ...
<mripard>
if you say it's alright, then it's good for me too
<danvet>
mripard, so I think all the issues you raise are real, but I think we want a slightly different solution to them
<danvet>
but also, it's hard to predict the future :-)
<mripard>
what I didn't really like is the false impression of safety it was giving, but I also appreciate that it doesn't really change anything compare to the current situation
<danvet>
mripard, yeah both devm and drmm don't solve problems when you start out with bugs :-)
<mripard>
when you're saying that the drm_bridge stuff isn't exposed to userspace, that's true for properties and all, but connectors would likely be attached to the last bridge in the chain, no?
thaytan has quit [Ping timeout: 480 seconds]
<danvet>
mripard, yeah the connector is exposed to userspace
<danvet>
and would have its own lifetime
<danvet>
also drmm is guaranteed to outlive devm
<mripard>
but pretty much every driver allocates it through a call to devm_kzalloc
<danvet>
so bridge accesssing connector is fine by design
<mripard>
since at probe time, a bridge doesn't have access to the DRM device anyway
<danvet>
mripard, oh yeah allocating drm_connector with devm_kzalloc is wrong
<danvet>
in general, devm_kzalloc is almost always a bug
mclasen_ has joined #dri-devel
<mripard>
yeah, but for bridges we can't really do anything else
<danvet>
mripard, maybe we need a drmm_ function which moves it from devm_ to drmm?
<mripard>
we get "access" to the DRM device at .attach time
<mripard>
yeah, that's what I was thinking too
<danvet>
or we need to switch to allocating the drm_connector only at attach time
<danvet>
which I thought was the grand rework pinchartl was pushing to pull the connector creating out of the bridge driver itself
<mripard>
that would "cancel" the devm hook, and add a drmm hook to free it
<mripard>
or something
<danvet>
yeah
<danvet>
problem is, that doesn't work with the current drmm/devm implementations
<danvet>
since those just do a kalloc with a bit of tracking structure prepended
<danvet>
mripard, I think in general "uapi is drmm, hw is devm" is a good rule of thumb, but sometimes something is a bit stuck in the middle
<danvet>
and I guess drm_bridge could be a bit both
<danvet>
the other problem is that a bunch of things around bridge aren't super clear
mclasen has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
danvet: last 4 ails maybe questions about DMA usage BOOKKEEP
thaytan has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
<danvet>
bnieuwenhuizen, ok I'll try to read those
<danvet>
just looked a bit overwhelming :-)
<danvet>
bnieuwenhuizen, so maybe I'm missing something key, but what I think is your understanding of BOOKKEEPING is what I think we should do for epxlicit sync cs
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
rkanwal has quit [Quit: rkanwal]
<dcbaker>
zmike: I've got " 20427d01ac zink: fix framebuffer attachment usage asserts for ..." and " cb5973a3dd zink: only update layout when doing mixed zs " that both need some previous patches, which are non-obvious :)
<zmike>
dcbaker: I'll do those myself
<zmike>
are you doing the release now?
<zmike>
(i.e., how urgent is this)
<dcbaker>
mareko: I've got "05eb9530ca ac/gpu_info: always retile DCC on gfx10 and newer chips" queued for 22.1, but there's a lot of refactoring that's happened between then and now, and I can't get it to apply
<dcbaker>
zmike: release is a week from today
<zmike>
ok
<dcbaker>
so whenever it's convenient
* zmike
is struggling not to lose context on something today
<dcbaker>
no worries
<mattst88>
dcbaker: could we get a mesa-21.3.9 release? (should I bug eric_engestrom instead?)
<dcbaker>
mattst88: for amber?
<mattst88>
dcbaker: yeah
<mattst88>
my intel/perf compile-time improvements made it in after 21.3.8, so it takes ages to compile i965
<dcbaker>
I'm not sure what the status of getting all of the configuration changes in is (ie, naming the glvnd plugins)
<dcbaker>
mareko: thanks!
mbrost has quit [Ping timeout: 480 seconds]
<dcbaker>
mattst88: I can cut a release whenever, but I keep dropping the ball following up with ajax on whether we're ready and what still needs to get done
<dcbaker>
daniels: we'd talked about getting that mr labeling script going, IIRC, you just need me to get it into a docker image, right?
wv has joined #dri-devel
<mattst88>
dcbaker: I packaged mesa-amber in gentoo recently, and I haven't heard any feedback on way or another... so maybe it works :)
<mattst88>
some confusing things that I think we may want to improve: mesa-amber installs libgbm and libglapi and conflict with mesa
<mattst88>
if you turn off gbm support, you lose some winsys integration features
<dcbaker>
looks like ajax got the amber stuff into staging. let me have a look (I have to go run some errands in a couple minutes, but I'll come back to this after I get back)
<Kayden>
libglapi should probably just get renamed on the amber branch?
<Kayden>
libgbm though...oof
<jekstrand>
While people are releasing things... Waffle?
mbrost has joined #dri-devel
<dcbaker>
jekstrand: yes, that's on my list to do today as well, sorry for the long delay
devilhorns has quit []
<dcbaker>
mattst88: release script is churning, assuming all goes well I'll send out the announcement when I get back
<jekstrand>
dcbaker: It's only ben 7 months and an entire job ago. What's another few hours? :P
<dcbaker>
lol
<mattst88>
dcbaker: thanks!
<dcbaker>
no problem
<mattst88>
I think we should start treating waffle as something like libdrm that anyone can release
<Kayden>
anarsoul, zmike: R-b
<anarsoul>
Kayden: thanks
X512 has joined #dri-devel
<X512>
What is waffle?
<jekstrand>
jenatali: Is something wrong with nir_test in Windows CI or is that a problem in my branch? :-/
* jekstrand
runs the test locally on Linux
toolchains has joined #dri-devel
Peste_Bubonica has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
<jenatali>
jekstrand: It's a problem in your branch
<jenatali>
You can download the testlog from the build artifacts
rkanwal has joined #dri-devel
<jekstrand>
Yeah, it is
<jekstrand>
Need to fix the unit tests and, while I'm at it, add more. :D
<jenatali>
Was Windows CI the only one that caught that?
<X512>
zmike: Is it OK that last_present_prune loop in kopper_present run for more than 1000 iterations?
<zmike>
no, probably that shouldn't happen
<X512>
And cdt->swapchain->presents suddenly become NULL sometimes after many iterations.
<X512>
I can't find any code that set cdt->swapchain->presents to NULL.
rkanwal has quit [Quit: rkanwal]
<zmike>
that's because there is no such code
<X512>
Then why it can become NULL during loop but not NULL before entrering loop?
<zmike>
new swapchain in error condition?
<jekstrand>
jenatali: Appears to be. :-/
Peste_Bubonica has quit [Ping timeout: 480 seconds]
<jenatali>
jekstrand: I saw someone disabled building unit tests in Linux CI recently
<jenatali>
There's definitely more tests that don't run on Windows, so someone probably should try to turn those back on...
alyssa has joined #dri-devel
* alyssa
tries implementing priority scheduling
<alyssa>
evidently I did something wrong because it doesn't work, wee
<anarsoul>
:)
<X512>
zmike: cdt->swapchain changes during last_present_prune loop, is it OK?
mbrost has joined #dri-devel
<zmike>
what
<zmike>
no, that probably shouldn't happen
konstantin has joined #dri-devel
<alyssa>
observing that if I disable v-sync, Neverball "runs" at 400fps according to gallium_hud by in fact displays only like 4fps
<zmike>
it's a very slow 400fps
<alyssa>
assuming that's due to bad scheduling
<alyssa>
I wired up context priority but that didn't fix itself ...
<alyssa>
(I would expect priority scheduling to fix it because sway's present frames would always take precedence over neverball's render frames, so sway should achieve its desired 60fps)
srslypascal has quit [Quit: Leaving]
saurabhg has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
srslypascal has joined #dri-devel
<anarsoul>
alyssa: do you have context priority support in your compositor?
<anarsoul>
alyssa: can you push your code somewhere?
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
<alyssa>
yes, I can confirm that different priority levels are being used
<zmike>
X512: yeah I'm out of context atm but iirc it's intended to work based on the timing cadence of acquire and present
<jekstrand>
alyssa: One sched_entity per-priority probably works if you don't want to change your uAPI much. Otherwise, you want queue objects of some sort.
<zmike>
it might be the case that things are different on your setup and so there needs to be synchronization somewhere
<dcbaker>
mattst88: release is made, email sent, docs merging
konstantin has quit [Remote host closed the connection]
toolchains has quit [Read error: No route to host]
toolchains has joined #dri-devel
<dcbaker>
jljusten: I'm trying to make the waffle release, but I can't check out the website branch, it's giving me a permission error for "files/release/waffle-0.2/waffle-0.2.tar.xz"
<dcbaker>
does that work for you?
<anarsoul>
alyssa: stupid question, but are you sure you installed panfrost kernel module with the change?
<X512>
zmike: What guarantees that swapchain is not already freed in kopper_present in that patch?
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
<zmike>
dunno, but that's what I've got time for today
<jljusten>
dcbaker: what branch are you testing? I can try to push it to my repo to see what happens.
<dcbaker>
I'm trying to just check out the website. lfs fails to fetch that .tar.xz and git says "sorry here's the branch you started on with a bunch of random stuff in it"
<zmike>
I think it probably just needs a fence or something and then a deferred destructor instead of how it works now
<zmike>
I can figure it out tomorrow
toolchains has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
<alyssa>
anarsoul: yes
<anarsoul>
alyssa: that's weird
<jekstrand>
Are there any shared buffers in the driver (screen-level) that might be forcing synchronization by accident?
<anarsoul>
alyssa: drm_sched picks a job from a higher priority entity first
<jljusten>
dcbaker: I saw your submit/1.8.0-release branch. I think you need to update the www directory for 1.8.0.
<anarsoul>
so if a job from compositor reaches the kernel is should be run first
<alyssa>
jekstrand: Yes, I imagine so ....
<alyssa>
It turns out implicit sync doesn't work that well, surprised pikachu
<jljusten>
dcbaker: Regarding "checking out pages", you might need to push to your personal repo under the "master" branch. .gitlab-ci.yml has pages with "only master".
<anarsoul>
jekstrand: classic priority inversion, this time on GPU side?
<dcbaker>
gross :/ Okay, I can do that
Duke`` has quit [Ping timeout: 480 seconds]
<anarsoul>
or rather on GPU driver side
<jljusten>
dcbaker: Of course there could be some lfs issue beyond all that.
<dcbaker>
that is some strange behavior. I pushed to myremot/main and it said "lfs blah balh balh on server, run this command" and now git checkout of website works...
<dcbaker>
thanks git-lfs…
<jljusten>
I'm assuming the mesa website probably employs some even more obscure hacks to make the tarballs work. ?
X512 has quit [Quit: Vision[]: i've been blurred!]
<dcbaker>
they're just in an http repo and the webiste just links to them, you push them via scp
<dcbaker>
there's a script that does it all
<dcbaker>
I'd like to get the script to work with waffle as well, but there's some extra stuff there I think
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
<alyssa>
anarsoul: ok, I've added a ton of kernel level instrumentation, the issue is somehow worse
<alyssa>
sway is only submitting work every few seconds!
karolherbst has quit []
karolherbst has joined #dri-devel
<Sachiel>
60spf gaming
<jekstrand>
Perfect for those sunny days!
<alyssa>
eyy
<alyssa>
So the issue isn't scheduling -- the kernel is starved of compositor work to schedule.
<alyssa>
^GPU scheduling
<anarsoul>
alyssa: so mesa bug?
<alyssa>
Possibly
<alyssa>
CPU usage looks reasonable.. 50% for neverball and <1% for sway
<alyssa>
and playing with nice didn't make a difference.
gouchi has quit [Remote host closed the connection]
<alyssa>
it's definitely GPU related, though
<alyssa>
blackholing neverball's rendering brings its CPU up to 100% but gets sway to work normally
<alyssa>
maybe this is a symptom of oversynchronizing like jekstrand thought?
mbrost_ has quit [Ping timeout: 480 seconds]
<alyssa>
i give up. useless little optimizations are all im good for.
<jekstrand>
alyssa: Do you have any per-screen BOs?
<alyssa>
probably
<alyssa>
the tiler heap for one
<jekstrand>
Yeah, bin_pool, desc_pool for blitter, bin_pool for indirect.
<jekstrand>
Why are those per-screen?
<danvet>
pq, emersion for the hotspot/virtual cursor thread, do we have a good way forward now?
<alyssa>
those 3 are all read-only and wouldn't cause any extra syncing if we did expicit sync
<danvet>
the thread looked a bit inconclusive in places
<anarsoul>
alyssa: don't you like spending 1 day debugging something that results in a one-liner fix? :)
<alyssa>
i'd offer to help with that but i'm obviously useless for anything that matters to users
<alyssa>
so i guess i should get back to writing compiler passes that nobody cares about
* danvet
took a while to get what spf means
mbrost_ has joined #dri-devel
<alyssa>
danvet: seconds per frame
<jekstrand>
It's also a measure of how good your sunblock is.
<jekstrand>
alyssa: Panfrost kernel driver always treats everything as being written. So if two things share a BO and it's in the submit_job list, they serialize on it.
<danvet>
alyssa, oh btw for your context priority question, I guess that means first step is to add a ctx uapi so you can create a sched_entity per gallium pipe/vk queue
<danvet>
jekstrand, yeah but sway should be able to squeeze in slightly more often than once per minute or so
<danvet>
except if it tries to wait for the buffer to finish rendering first
<jljusten>
dcbaker: We wanted to see how it worked out if git-lfs was used to store the tarballs. Then they live in the same repo as everything else. I think it seems to be working ok.
<jekstrand>
Yeah, the over-sync theory doesn't really jive with the starvation thing
<danvet>
make sway rt priority and it really should win easily since dma_resv fairness should be purely a cpu game
<alyssa>
jekstrand: yeah
<dcbaker>
jljusten: I think it's working okay, I just wanted the script to generate the tarballs, sign them, and create the release notes like mesa :)
marex has quit [Ping timeout: 480 seconds]
<alyssa>
danvet: ctx uapi, eh
<alyssa>
would that hurt chromium which for some reason creates a new context for every page
<danvet>
alyssa, maybe as a hack in the kernel, change USAGE_WRITE to USAGE_READ
<danvet>
since you schedule the entire fd over a single sched_entity it should still be ordered enough to not blow up
<alyssa>
nyh
<anholt>
alyssa: in chrome os they multiplex pages onto contexts, and honestly they should be doing that for desktop linux too
<alyssa>
OK
<danvet>
yeah real ctx uapi is nice
<anholt>
(but that would take, you know, caring about desktop linux)
<danvet>
especially when you do full vm isolation and all that for some real arb_robustness
krushia has joined #dri-devel
<alyssa>
i guess
<alyssa>
what do i know. not a graphics person.
<jekstrand>
A queue per context isn't going to hurt anyone. It's a few more sched_entity's but meh.
<bnieuwenhuizen>
anholt: wdym multiplexing pages?
<anholt>
bnieuwenhuizen: until very recently, chrome would have a GL context per page. but they recently turned on an option originally built for android that reused contexts between pages to keep memory usage down.
<anholt>
s/pages/tabs/
<bnieuwenhuizen>
ah thx. Totally didn't see what pages were , now it makes sense
<jekstrand>
Not 4K pages. The other kind. :P
<bnieuwenhuizen>
I wish they were only 4k. Would save me hundreds of dollars in DRAM cost :P
<jekstrand>
hehe
<alyssa>
dram it
ppascher has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: kindergartens that way]
lemonzest has quit [Quit: WeeChat 3.5]
<jekstrand>
airlied: I'm still thinking about command/descriptor pools.
<jekstrand>
We have a bit of consistency in command pools among drivers that copied+pasted RADV but ANV is totally different.
<jekstrand>
I don't think we have much consistency at all among descriptor pools.
<jekstrand>
For descriptor pools, ANV doesn't actually vk_alloc() each descriptor set. Instead, it has a flat blob of memory in the pool and sub-allocates them from there.
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<bnieuwenhuizen>
jekstrand: we only sub-alloc in the linear allocation case as we didn't want to reinvent our own allocator for system memory
<jekstrand>
Meanwhile, ANV does vk_alloc() each command buffer every time and never recycles.
<bnieuwenhuizen>
is your allocation story any easier? (e.g. fixed size system RAM for descriptor sets or such?)
<anarsoul>
jekstrand: out of curiosity, starting from what generation Intel GPUs became vulkan-friendly?
<bnieuwenhuizen>
otherwise we may have diverged, but maybe not because the problem is different?
bluebugs has joined #dri-devel
<airlied>
jekstrand: moving intel to recycling is pretty trivial
<airlied>
ideally I'd like to move all the drivers to recycled and remove the option
<airlied>
yeah descriptor pools will require a bit more thought, but I definitely see some opporunity for sharing
<airlied>
anarsoul: gen8
<anarsoul>
airlied: thanks
<airlied>
anarsoul: gen7 is painful vulkan wise
chaim has quit [Quit: Konversation terminated!]
<jekstrand>
airlied: Sure. Recycling is good but I'm unsure how best to do it and how much to recycle.
<jekstrand>
There are reasons (VK_EXT_private_data, mostly) why we need to at least tear down and re-initialize the vk_object_base. IDK if we really want to re-initialize everything, though.
<jekstrand>
And I'm not sure I want to only re-init vk_object_base() behind the driver's back in case there is something it needs re-initialized.
<jekstrand>
I don't know what that'd be, though.
<jekstrand>
:-/
technopoirot has quit [Ping timeout: 480 seconds]
rcf has quit [Quit: WeeChat 3.4.1]
rcf has joined #dri-devel
<airlied>
jekstrand: the last MR I pushed leave the reinit to the driver
<airlied>
the reinit common code does the basics
<airlied>
if a driver has it's own things to do, it can do that
<airlied>
I could pull the driver cmd_buffer reset out into the drivers
digetx has quit [Ping timeout: 480 seconds]
wv has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
ngcortes has joined #dri-devel
digetx has joined #dri-devel
pixelcluster has quit []
neonking_ has quit [Remote host closed the connection]
tursulin has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
pcercuei has quit [Quit: dodo]
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<airlied>
danvet, daniels, jekstrand : is there anything at LPC this year?
<danvet>
airlied, no gfx miniconf afaik
<danvet>
daniels and me chatted and decided we both don't have the time to run the show
iive has quit []
technopoirot has joined #dri-devel
icecream95 has joined #dri-devel
<daniels>
dcbaker: yeah just into a docker image which takes the token as a param & runs until death labelling and sleeping then I can take it from there - thanks!
<daniels>
(but not this week, I’m on holiday)
tzimmermann_ has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
mbrost__ has quit [Remote host closed the connection]
mbrost__ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Ping timeout: 480 seconds]
<dcbaker>
daniels: it’ll probably take me a day or too to figure out docker anyway. Have a nice vacation!