ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pochu has quit [Ping timeout: 483 seconds]
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
Company has quit [Quit: Leaving]
orbea has joined #dri-devel
sdutt has joined #dri-devel
jewins1 has quit [Ping timeout: 480 seconds]
_alice has joined #dri-devel
_alice has left #dri-devel [#dri-devel]
_alice has joined #dri-devel
Lightkey has quit [Ping timeout: 480 seconds]
Lightkey has joined #dri-devel
heat has joined #dri-devel
camus has joined #dri-devel
camus1 has joined #dri-devel
sdutt_ has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
boistordu_old has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
boistordu has quit [Ping timeout: 480 seconds]
mixfix41 has quit [Ping timeout: 480 seconds]
sdutt_ has quit [Ping timeout: 480 seconds]
sdutt_ has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
mlankhorst has joined #dri-devel
camus has joined #dri-devel
lemonzest has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
pochu_ has quit [Ping timeout: 480 seconds]
pnowack has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
frieder has joined #dri-devel
danvet has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
itoral has quit []
lynxeye has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
bcarvalho has joined #dri-devel
sagar_ has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
sagar_ has joined #dri-devel
tursulin has joined #dri-devel
pendingchaos_ is now known as pendingchaos
rasterman has joined #dri-devel
pochu has joined #dri-devel
pnowack has quit [Read error: Connection reset by peer]
rsalvaterra_ has joined #dri-devel
pnowack has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
<cwabbott>
jekstrand: no, I meant the change to validation that I asked for
<cwabbott>
you commented on it but didn't actually change it
yk has joined #dri-devel
rsalvaterra has joined #dri-devel
aravind has joined #dri-devel
rsalvaterra_ has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
yk has quit [Remote host closed the connection]
Company has quit [Read error: No route to host]
Company has joined #dri-devel
The_Company has joined #dri-devel
jernej has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
flacks has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
imre has quit [Remote host closed the connection]
kusma has joined #dri-devel
<kusma>
jekstrand: Is it just me, or is the PRIME codepath in the Vulkan WSI helpers getting image layouts wrong? It passes a srcLayout of VK_IMAGE_LAYOUT_PRESENT_SRC_KHR to vkCmdCopyImageToBuffer, which according to the spec is invalid...
<kusma>
also, I don't think there's any guarantee of that layout being the correct one, at least I don't see any transitions in vkcube into VK_IMAGE_LAYOUT_PRESENT_SRC_KHR...
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
jernej has joined #dri-devel
vivijim has joined #dri-devel
heat has joined #dri-devel
<kusma>
Ah, that last part was me messing up; I just missed the renderpass finalLayout stuff. But I think the other stuff is an issue...
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
<sneil>
ns0123
aravind has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
rsalvate_ has joined #dri-devel
rsalvaterra_ has quit [Ping timeout: 480 seconds]
rsalvate_ has quit [Ping timeout: 480 seconds]
<jekstrand>
kusma: Uh.... It's quite possibly wrong. We take a few liberties in WSI
<jekstrand>
cwabbott: Right... So what are you thinking? Not validate them at all? I was figuring we could relax the rules later as-needed.
rsalvaterra has joined #dri-devel
<kusma>
jekstrand: OK, I guess it wouldn't hurt too much if I threw in a couple of barriers around that copy, then? I mean, those cmdbufs are recorded up-front, and HW that doesen't need the barriers can easily nop them while recording...
<jekstrand>
kusma: Yeah. We can barrier to/from BLIT_SRC safely.
<kusma>
Cool.
sdutt has joined #dri-devel
<jekstrand>
It's a pity we have to eat a double-barrier there but oh, well.
<kusma>
Sure, but since this only happens init-time unless it's actually needed, then I think that should be fine?
camus has joined #dri-devel
<jekstrand>
I'm not worried about recording the command buffer but executing it. :)
<kusma>
Right, but won't the drivers that don't need this barrier just skip it while recording?
<kusma>
If not, well... Maybe fix the drivers? :)
<jekstrand>
It depends on if the barrier to PRESENT_SRC is heavier than the one to BLT
<jekstrand>
And ANV might be broken. :(
<kusma>
I'm not sure I follow... I would assume this is incorrect as-is unless these barrier is actually a no-op...
<jekstrand>
Uh, anv isn't broken but it does do an unnecessary transition.
<kusma>
So in the drivers where this is a no-op, I would expect both barriers to be thrown out during command list recording.
<jekstrand>
kusma: Generally, PRESENT_SRC is a stricter layout than TRANSFER_SRC because it has to be able to handle both scanout and compositing while TRANSFER_SRC just needs to be usable as a sampler or image source so you can run your transfer shader.
camus1 has quit [Ping timeout: 480 seconds]
<jekstrand>
So doing -> PRESENT_SRC -> TRANSFER_SRC is more wasteful than going straight to TRANSFER_SRC
<jekstrand>
That's what I'm complaining about
<kusma>
Right, but we should already be in PRESENT_SRC at the start of this.
<bnieuwenhuizen>
jekstrand: you also get to do the barrier back TRANSFER_SRC->PRESENT_SRC after the copy ...
<jekstrand>
kusma: Yes. bnieuwenhuizen: Yes.
<jekstrand>
I think I just need to add one extra line of code to ANV to make it no-op TRANSFER_SRC on PRIME bounce images.
frieder has quit [Remote host closed the connection]
<kusma>
So it's really arbitrary -> PRESENT_SRC -> TRANSFER_SRC -> PRESENT_SRC vs arbitrary -> PRESENT_SRC. Both go to the strict layout.
<kusma>
jekstrand: OK, I'm not really in a hurry here, just trying to figure out how to solve this issue.
<jekstrand>
kusma: What you're trying to do is correct
<jekstrand>
kusma: And the right thing to do for now
<jekstrand>
Sorry if I'm making it sound like it isn't
<kusma>
No, you're not, I just want to make sure I'm not making things needlessly slow for other drivers :)
<jekstrand>
kusma: What's neadlessly slow is doing the really heavy -> PRESENT_SRC transition
<kusma>
Anyway, I think we're on the same page here.
<jekstrand>
PRESENT_SRC -> TRANSFER_SRC should be fast and/or no-op.
<jekstrand>
So I'm not worried about it
<kusma>
jekstrand: Yeah, that one is coming from the application in my case (vkcube)... But we're assuming to be in that state at the end anyway...
<kusma>
So I guess to solve that one, we'd either have to somehow inform the application that we don't really need to be in the present-state at the end, or somehow promote that state in driver/wsi glue
<kusma>
I guess the latter would be better, but the semantics sounds a bit nasty. The driver could probably look at the prime_blit_buffer member of the wsi_info structure to figure out it can cheat without getting caught?
<kusma>
(because there's no way that an image with prime_blit_buffer set will actually be scanned out anyway)
sdutt has quit []
<jekstrand>
kusma: Yeah, it's a hard problem to solve. :(
sdutt has joined #dri-devel
<zmike>
kusma: ping?
The_Company has quit [Read error: No route to host]
tester641 has quit [Remote host closed the connection]
<airlied>
what's the solution to oops I forgot Fixes: line to get something in stable?
<kisak>
pull requests to staging/release-series
<zmike>
yea just make a MR against the stable branch
* airlied
will try harder to remember fixes to avoid this overhead :-P
<airlied>
ugggh ppc64le in CI crashes that aren't happening on real ppc64le hw I tested on ftl
pochu has quit [Ping timeout: 480 seconds]
<airlied>
time to work out how to get those containers running locally I suppose
rasterman has quit [Quit: Gettin' stinky!]
<sravn>
pcercuei: Are you going to apply "drm/ingenic: Convert to Linux IRQ interfaces"?
<kayden>
anholt_: have you looked at auxiliary/pipebuffer at all? I'm looking at moving iris to use slab allocators for most resources, so we can allocate larger/fewer GEM objects...and there is supposedly some common code there that I could use
* zmike
has implemented this
<kayden>
but now that I'm looking at it, I'm not sure I really care for it
<kayden>
pb_buffer.h seems genuinely common but does nothing of substance
<kayden>
pb_slab.* and pb_cache.* seem to be radeonsi-originated and used there
<kayden>
the *bufmgr* stuff seems to be vmware originated and used there, but explicitly not used in radeonsi because they're inefficient/slow/a bad fit for them
<kayden>
pb_slab.c and pb_bufmgr_slab.c both define struct pb_slab in conflicting ways
<kayden>
it seems like you get stuck with a lot of policy too, like number and sizes of buckets, when and how often to purge caches, ...
<kayden>
I noticed the new d3d12 MS stuff uses pipebuffer too. but vc4/v3d have bufmgr code originating from i965, which makes the iris bufmgr code almost as much common heritage as the others...heh
kayden is now known as Kayden
<zmike>
it has a lot of conflicting/confusing stuff in it for sure
<Kayden>
zmike: oh thanks for that, that's helpful
<anholt_>
Kayden: yeah, I definitely just wrote the intel code again for v3d/vc4, and while I was vaguely interested in pb, it didn't seem like it did a whole lot.
<anholt_>
and most of my slab allocation issues were solved by u_upload
mlankhorst has quit [Ping timeout: 480 seconds]
<airlied>
like a lot of radeonsi led features they dont do much until they matter then they do lots :-0
<pcercuei>
sravn: sure
<zmike>
haha
<airlied>
if you can saturate your gpu without saturating your cpu then you might never need some of them
<zmike>
the secret ingredient is stalling
<Kayden>
anholt_: yeah...trying to decide whether to switch over to it, or just rip off pb_slab and do it myself
<sravn>
pcercuei: Thx, dropped from my follow-up list then
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
<pcercuei>
sravn: pushed to drm-misc-next
gouchi has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
vivijim has quit [Quit: leaving]
<ngcortes>
what branch should I fetch to get upstream drm-tip?
<ngcortes>
I'd like to build that kernel and test on ERROR