<emersion>
that's a pretty calm and detailed reply for anger :P
<pq>
I don't sleep well the next nights if I let my anger run rampantly, so it's just self-preservation.
<emersion>
ahah, i know what you mean
<emersion>
i really hope they get it this time, this thread is getting old
<pq>
It's a mutual misunderstanding of what the other is talking about. I've notice it happens *always* with me vs. some people, and almost never with me vs. some other people.
<emersion>
i mean, it's not like they're very good at explaining their viewpoint
saurabhg has joined #dri-devel
<pq>
we'd think that, but maybe we just don't get it
<pq>
seems like the definition of violent agreement
<emersion>
understanding how VM software works was a very teeth-pulling-like experience
<pq>
it's important to get more people involved at that stage, because otherwise it's very unlikely to get anywhere
<MrCooper>
seems pretty clear to me that Zack just doesn't get it for some reason
saurabh_1 has joined #dri-devel
<emersion>
yeah, i don't think we can bring the discussion further if they don't budge
soreau has quit [Read error: Connection reset by peer]
<MrCooper>
which is surprising, since I know him as a very smart and fun person
Daaanct12 has joined #dri-devel
soreau has joined #dri-devel
<pq>
Maybe Zack never says when he agrees with something? Which to me leaves the impression that they don't agree on anything.
<MrCooper>
could be (I'm probably guilty of that myself too often)
<emersion>
when arguing, agreeing with something can be seen as "giving up ground", so maybe…
<emersion>
(yeah, not blaming them for that)
heat_ has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
vup has quit []
vup has joined #dri-devel
aura[m] has quit []
Eighth_Doctor has quit []
cef has quit [Quit: Zoom!]
sumoon_ has joined #dri-devel
sumoon has quit [Read error: Connection reset by peer]
FireBurn has joined #dri-devel
ifreund has quit [Ping timeout: 480 seconds]
ifreund has joined #dri-devel
<FireBurn>
@airlied I remember you having "great fun" with an issue you found where you created a patch that no one was happy about, to fix something that no one understood why it wasn't working
neonking has quit [Remote host closed the connection]
neonking has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
saurabh_1 has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
Daaanct12 is now known as Daanct12
<daniels>
I think Zack completely understands the issue, just sees VMware's current behaviour as totally immutable, and any change would have to be on the part of others
<javierm>
tzimmermann: there are only two drivers calling drm_aperture_remove_conflicting_framebuffers() directly, drivers/gpu/drm/ast/ast_drv.c and drivers/gpu/drm/hyperv/hyperv_drm_drv.c
Kayden has quit [Quit: f2f :/]
<javierm>
tzimmermann: I wonder if those could be modified to just use drm_aperture_remove_conflicting_pci_framebuffers() and drm_aperture_remove_framebuffers() respectively
<javierm>
and make drm_aperture_remove_conflicting_framebuffers() private to drivers/gpu/drm/drm_aperture.c
<tzimmermann>
javierm, i once tried with ast and the pci function didn't work correctly
Haaninjo has joined #dri-devel
<javierm>
tzimmermann: I see
<javierm>
tzimmermann: I also wonder if the primary = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW is something that the helper should also contemplate ?
<javierm>
or is that something specific to ast ?
<tzimmermann>
no idea
srslypascal has quit [Read error: Connection reset by peer]
srslypascal has joined #dri-devel
<javierm>
tzimmermann: Ok. Not that trivial to do that cleanup then
<tzimmermann>
wasn't that in the architecture code somewhere?
<tzimmermann>
if set, it's likely the boot-up vga
<javierm>
tzimmermann: what I meant is that the aperture helper doens't check that flag to choose if the primary has to be kicked out or not
<tzimmermann>
it's already done in remove_conflicting_pci_framebuffers()
<javierm>
tzimmermann: oh, indeed
<javierm>
wonder why ast does this then... and not just use drm_aperture_remove_conflicting_pci_framebuffers()
<javierm>
I can't see what could be the difference...
<javierm>
tzimmermann: anyways, just asked in case you already tried this and that's the case. So no worries
<tzimmermann>
i couldn't either back then
<javierm>
tzimmermann: and what about hyperv ?
<tzimmermann>
idk
<javierm>
but wouldn't help that much to use drm_aperture_remove_framebuffers() if we still have to keep drm_aperture_remove_conflicting_framebuffers() for ast
saurabhg has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
has blorp worked out well for anv?
<alyssa>
likewise, has the internal meta vulkan calls worked out well for radv?
mceier has joined #dri-devel
<alyssa>
and I guess related--
<alyssa>
has blorp worked out well for iris?
<alyssa>
what about u_blitter for radeonsi?
<zmike>
u_blitter is great when you're not hitting some obscure, decades-old bug
<alyssa>
zmike: zink uses u_blitter instead of vkCmdCopy etc?
<zmike>
both
<zmike>
they're totally different
<zmike>
lots of drivers use u_blitter
<alyssa>
mmf
<alyssa>
(panfrost uses u_blitter and is fine with it, panvk is open coding everything and it doesn't look like it'll scale well, on the maintainability axis, but I'm not sure what the right direction to move us is)
<alyssa>
blorp seems *really* complicated, both internally and for clients to use
<alyssa>
I'm not sure how much Intel is gaining from it
<zmike>
radv uses a complex meta shader infrastructure which has various shaders for all the internal ops
<alyssa>
everything on the vk side is super complicated isn't it :|
Kayden has joined #dri-devel
<daniels>
blorp lets you use a totally different hw ring which isn't touched by vert/frag/etc, so you do get a win from the complexity if you can parallelise that way
<alyssa>
daniels: right, ok
<dj-death>
daniels: hmmm intel's blorp is definitely the 3d pipeline
srslypascal has quit [Quit: Leaving]
JohnnyonF has joined #dri-devel
<daniels>
orly? my knowledge is v out of date then
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<daniels>
is BLT no longer a separate ring to RCS/etc?
<cwabbott>
BLT is still a thing but it was always slower than the 3d path on intel so it was never considered useful
<dj-death>
and also BLT doesn't do any compression stuff
<cwabbott>
hence you need to do BLits On the Render Path
<dj-death>
which makes it quite not useful
<dj-death>
and with command buffers, that would be complicated to use in Vulkan
<ajax>
i thought i saw something about the blt ring finally being useful on gfx12+ ?
mbrost has joined #dri-devel
<dj-death>
ajax: yeah gfx12.5+
<dj-death>
ajax: I think Kayden has some patches
<ajax>
!13877, merged
<dj-death>
I don't remember that it does everything though
<daniels>
cwabbott: ooooh, that's a nice acronym
<dj-death>
yep. :)
nchery has joined #dri-devel
<Kayden>
the HW blitter became a separate ring from render starting with Gen6+ (Sandybridge), and from then on was much slower than 3D (render got faster, blitter didn't)
<ajax>
hm. if you use blorp for a stretch blit is that a blerp?
<Kayden>
it's now completely disabled because beyond being slow it has...........issssssues.
<Kayden>
on Tigerlake (gen12+) they added new commands which actually can saturate memory bandwidth
<dj-death>
and they're in the same ring?
<Kayden>
it's a separate ring still
<dj-death>
okay
JohnnyonFlame has joined #dri-devel
<Kayden>
I have an anv branch to add a transfer queue using BLT on XeHP/DG2
simon-perretta-img_ has joined #dri-devel
<Kayden>
iris uses the blitter on Tigerlake and later for hybrid graphics copies and external BOs
simon-perretta-img_ has quit [Remote host closed the connection]
<vsyrjala>
i though some FAST_ blitter commands appeared several gens ago already? or was it too limited still?
simon-perretta-img_ has joined #dri-devel
<Kayden>
I have patches to use it in more cases as well but we hadn't benchmarked those, Marek had cautioned me that it was a loss on radeonsi so I wanted to be careful
<Kayden>
Gen9 did add XY_FAST_* blit commands but they were pretty limited
mbrost has quit [Remote host closed the connection]
<Kayden>
XY_BLOCK_COPY_BLT is way nicer
mbrost has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
<jekstrand>
bbrezillon: Yeah, I think that's fine.
camus has quit []
<bbrezillon>
jekstrand: thanks!
<jekstrand>
yw
<FLHerne>
Did the Windows driver find a way to use BLT sanely? If not, why keep adding it to new hardware at all?
<FLHerne>
(until making it useful instead)
<alyssa>
FLHerne: So, you might assume that Intel's hardware team listens to Intel's software team.
<ajax>
who knows. intel hardware only just lost support for fxt1 texture compression in the last, what, two years?
<ajax>
not all decisions are coherent
pcercuei has quit [Quit: brb]
nvishwa1 has joined #dri-devel
famfo has quit []
famfo has joined #dri-devel
<idr>
ajax: The explanation I got for that was FXT1 was really intertwined with DXT, and nobody wanted to re-implement that chunk of the sampler to save a couple % of gates.
pcercuei has joined #dri-devel
mriesch has quit [Remote host closed the connection]
mriesch has joined #dri-devel
Duke`` has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
<ajax>
idr: i guess that's not surprising given how similar the two formats are
<idr>
And my guess is that on DG2 that small % times a bunch of samplers starts to be an important number of gates, so it became worth the effort.
<idr>
But nobody tells me anything. *shrug*
<ajax>
honestly i found it kind of endearing that it still worked
<linkmauve>
benettig or daniels probably, but really anyone involved with GitLab, I just git fetch’d mesa/mesa and it blew up my repository from 438 MiB to 4 GiB, and even after a git gc --aggressive it’s still 1.1 GiB total for just the bare repository.
<linkmauve>
Is there anything we can do to bring it back to a reasonable size, or is there a reason it’s that way now?
<linkmauve>
The git fetch also took a very long time, pulling a lot of branches, but I can’t see why because it scrolled out of view.
tzimmermann has quit [Quit: Leaving]
alyssa has left #dri-devel [#dri-devel]
<linkmauve>
Ah, doing a git clone again brings it back to 373 MiB, so maybe I just have to move over my branches to a new repository.
<daniels>
if you're fetching +refs/merge-requests/*/head then there's not much we can do about that ...
<linkmauve>
I’m only fetching +refs/*:refs/* according to my .git/config it seems.
<linkmauve>
But I do see a bunch of such lines in the fetch: * [new ref] refs/merge-requests/16962/head -> refs/merge-requests/16962/head
<daniels>
right
<daniels>
so you're pulling every single MR
<linkmauve>
Is there a way to tell git not to do that?
<linkmauve>
Or to prune them now that they got downloaded?
<linkmauve>
But nevermind, if it’s a configuration issue on my end it’s no big deal, I was just worried it might have been a migration issue given the issues from the past few days.
srslypascal has joined #dri-devel
thellstrom has quit [Quit: thellstrom]
mszyprow_ has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
shankaru has quit [Quit: Leaving.]
mszyprow has quit [Ping timeout: 480 seconds]
saurabhg has quit [Ping timeout: 480 seconds]
slattann has quit [Quit: Leaving.]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
JohnnyonF has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
LexSfX has quit []
LexSfX has joined #dri-devel
saurabhg has quit [Read error: Connection reset by peer]
MajorBiscuit has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
ahajda has joined #dri-devel
slattann has joined #dri-devel
<zmike>
dcbaker: I've pushed those patches you had conflicts with
cef has quit [Ping timeout: 480 seconds]
<dcbaker>
zmike: awesome, thanks!
<dcbaker>
If we ever get to meet in person I owe you a drink for all your help
<zmike>
no, no, I'll get you a drink for managing all these releases
<dcbaker>
Lol
ngcortes has joined #dri-devel
cef has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
lynxeye has quit [Quit: Leaving.]
mszyprow_ has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
gouchi has joined #dri-devel
Kayden has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
rkanwal has quit [Quit: rkanwal]
mceier has quit [Quit: leaving]
mceier has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #dri-devel
slattann1 has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
slattann has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jenatali>
I assume there's no way to slightly extend Marge's timeout, right?
<jenatali>
MRs with a container rebuild take just too long, but also are blocking other MRs from being run while it's sitting waiting for the timeout... I wish I could just manually override the timeout to give an extra like 20 minutes
<anholt>
I think I'd feel good about that, if we also cut default timeouts on test jobs to ~35 minutes (10ish minute job, run twice in case of HW, plus some slop) from 1 hour. which we should do anyway
ybogdano is now known as Guest2085
ybogdano has joined #dri-devel
<jenatali>
Yeah, that seems pretty reasonable to me
Guest2085 has quit [Read error: Connection reset by peer]
<jenatali>
This latest round of Windows CI script cleanup probably actually gets us damn close to being able to do a container rebuild + build + test in ~1 hour
<jenatali>
Which is insane considering that's a VS install + LLVM build + piglit build + CTS build
<anholt>
linux is about the same, just kernel instead of llvm.
<anholt>
there's some wip by collabora to cache chunks of the container build in minio so when you're iterating on kernel uprev or whatever, you don't have to rebuild deqp over and over
viciouss[m] has joined #dri-devel
<jenatali>
Yeah the latest Windows refactor that Marge is working on right now splits the container build in 3 which should help with iterating on pieces of it
<jenatali>
Thought I guess if you needed a VS uprev that still wouldn't help