<sima>
jani, because dim rebuild-tip failed on the topic/core-for-CI branch conflict
rasterman has joined #dri-devel
<sima>
I pushed my drm-misc-next fixup out for you since I have to do some interviewing right now ...
<sima>
uh wait, raw git push failed
<jani>
naughty naughty
<sima>
jani, ok should work now
<sima>
and I guess 61d9b3364a6ba276a972ae88f6cad5a8a31c3243 should be dropped?
<tzimmermann>
javierm, we do have such a workaround as in your patch in our trees at suse. it happens on the rpi as well
sgruszka has joined #dri-devel
<javierm>
tzimmermann: yeah, I guess that happens on any DT platform that does a EFI boot and the firmware/bootloader adds a EFI GOP handle for the Linux EFI stub to look at
<sima>
javierm, only question I have is whether sysfb could load before this of setup? but I guess at worst we have a bit more driver handover in that case ...
<sima>
maybe another one: should simple-framebuffer really be preferred over efi?
<javierm>
sima: 1) it can't happen before, because the OF initcall is arch_initcall_sync() while the sysfb initcall is subsys_initcall() (and we are talking with tzimmermann to move it later to device_initcall_sync())
<sima>
ah if that assumption is already baked in, then I guess it's good
<javierm>
sima: 2) AFAIU the DT is the real source of truth on an DT platform, only the EFI boot services are used, not the EFI runtime services on these platforms
<sima>
ah that might be good to put down as justification and maybe check with robher or someone who knows ...
<javierm>
sima: the only reason they use EFI to boot is to make the boot path more standard AFAIK. Am I correct here tzimmermann ?
<javierm>
sima: Ok
<javierm>
sima: I'll mention these two things in the commit message as well and post as an RFC then, Cc'ing robher and other stake holders
<jani>
sima: I'm taking care of core-for-CI
<sima>
jani, thx
jkrzyszt has joined #dri-devel
<jani>
sima: taking a while to build it after rebasing...
<sima>
jani, yeah I don't think we have a huge queue of people who want to push their patches on Monday morning :-)
urja has quit [Read error: Connection reset by peer]
urja has joined #dri-devel
dtmrzgl has quit []
<jani>
:)
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
Surkow|laptop has joined #dri-devel
dtmrzgl has joined #dri-devel
lynxeye has joined #dri-devel
<emersion>
enunes: did you have the chance to finish up your patches to drop wl_drm auth from v3d? or not yet?
<emersion>
just making sure i haven't missed anything
jfalempe has quit [Quit: Leaving]
<enunes>
emersion: not yet, I should go back to look into that today, hopefully what it needs is to figure out how to pass the into from the dmabuf feedback common layer
<enunes>
itoral ^
<emersion>
ah, let me know if you have questions regarding this
<emersion>
to their credit, i don't think i ever groked the divisor/remainder thing
<emersion>
and how generic it is for timestamps vs seqnos
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
vliaskov has joined #dri-devel
tayloralgo1[m] has quit []
mripard has joined #dri-devel
apinheiro has joined #dri-devel
cmichael has joined #dri-devel
frieder has joined #dri-devel
flynnjiang has quit [Quit: flynnjiang]
kallisti5[m] has quit []
ramacassis[m] has quit []
airlied has joined #dri-devel
adavy has quit [Ping timeout: 480 seconds]
ajhalaney[m] has quit []
anfanite396[m] has quit []
adavy has joined #dri-devel
<itoral>
enunes: I guess we would still have the same issue with allocating display buffers we currently have though, right?
<enunes>
itoral: I think it would work as it would receive the display device to allocate buffers when the scanout flag is set, and the gpu device when buffers are going to be composited anyway
<enunes>
I think we concluded that authentication is not actually needed to allocate dumb buffers in general so we could keep the dumb buffer allocation as the fallback for now
<itoral>
oh cool, if that is true then yeah, that would fix the issue
<itoral>
looking forward to seeing that, let me know if you need assistance :)
<itoral>
about allocating dumb buffers... I just checked and drm_mode_create_dumb_ioctl doesn't seem to require DRM_AUTH... was that changed though? I am pretty sure we needed that before
<emersion>
yeah i'm pretty confused by this as well
<emersion>
i tried to dig the git history but didn't find anything
<itoral>
uh... weird :-/
Armote[m] has quit []
Harvey[m] has quit []
frieder has quit [Ping timeout: 480 seconds]
<emersion>
oh, found it
<emersion>
had to go through quite a few refactoring commits
<emersion>
fb30edf5e4b4 ("drm: make buffer management work without DRM_MASTER")
<emersion>
the motivation for allowing CREATE_DUMB are… questionable
<itoral>
ah, good find, so I was not crazy after all :)
<emersion>
sima: hm so mripard is suggesting auto-creating a DMA heap by default in DRM core, and adding a func pointer to let drivers override this behavior
<emersion>
(correct me if i'm wrong mripard)
<emersion>
but i'm arguing we should really enable this on a per-driver basis, because each hw is different, and heaps should not be named by their purpose, but by their nature
<emersion>
do you have an opinion on this?
<emersion>
like, i don't think always creating a heap which behaves like dumb buffers is a proper solution
<emersion>
(and then there's the "should we have more function pointers, which make DRM core more of a midlayer" discussion, but let's leave that for later)
frieder has joined #dri-devel
<mripard>
note that I don't really care about the automatic part, but I do care about fixing all the affected drivers at once
<mripard>
if that's with a helper + a coccinelle script, that's fine by me
<emersion>
(i'm arguing that doing all at once is too much work, difficult to test, and not required)
<emersion>
(we have 26 kmsro drivers in Mesa)
<MrCooper>
emersion: it's not clear to me why the CRTC getting pulled into an atomic commit guarantees that a flip is programmed for a plane
<emersion>
MrCooper: you can see it that way: a FB_ID no-op update is no different from another prop no-op update
<emersion>
the driver doesn't get to know which prop has changed, only a list of affected planes/CRTCs/etc
<emersion>
sorry
<emersion>
doesn't get to know which prop was included in the atomic commit
camus1 has joined #dri-devel
<emersion>
the testing zamundaaa has done also confirms this
camus has quit [Read error: Connection reset by peer]
<sima>
not sure about context (some doc patch I can't find?) but it's just a crtc vblank event that the driver has to push through properly
<sima>
or the helpers get really unhappy
<pq>
sima, triggering a VRR new scanout cycle
<pq>
in hardware
<sima>
yeah just somehow getting the crtc state into the commit should be enough for that
<pq>
cool
<sima>
since that's all that's needed to require the crtc event machinery to go through a frame
<emersion>
yup
glennk has quit [Ping timeout: 480 seconds]
<sima>
hm ... might be that current drivers kinda slack and end up delaying the flip in the VRR case
<sima>
but I think for most hw that would need active consideration in the code
<MrCooper>
yeah, not seeing the connection between the event machinery and triggering scanout with VRR
<MrCooper>
anyway, it sounds like a flip is programmed for the plane if any state was set for it, which would cover it
<sima>
so kinda instead of immediate vrr flip you get the one that you'd get if you just do a crtc sequence ioctl wait
<sima>
which is maybe not what we want, because that atomic commit does hold up everything else :-/
<sima>
unlike the crtc sequence ioctl wait
<sima>
pq, emersion I guess you want this for frame pacing without hitting one of the implied full damage cases if you'd add a plane too?
<emersion>
the context is async atomic flip
<emersion>
but tbh the VRR case is same for both legacy and atomic, so i'm not very worried
<emersion>
IOW: enabling async on atomic can't introduce a new VRR-related bug that legacy didn't have
<sima>
yeah I was just checking how we handle target timestamp and noticed that we dont
<sima>
I thought we had patches so you could try and precisely schedule VRR frames
<MrCooper>
must have been a nice dream :)
<sima>
we don't even have the target sequence like legacy flip ...
glennk has joined #dri-devel
<MrCooper>
right, that might actually be nice to avoid flips getting needlessly delayed
<MrCooper>
e.g. with very long vblank
<sima>
I think documenting that any crtc flip (even if empty) should vrr flip asap would be good, and then perhaps fixing drivers if any are not getting this corner right
<sima>
scheduled timestamp would be one on top I think (for no-jitter media playback or something like that)
<emersion>
sima, what do you mean by "empty fli"?
<emersion>
empty flip*
<sima>
just the crtc, no plane
<sima>
or too obscure corner case to care?
<emersion>
nah, i think it's good to document that
<emersion>
it can be surprising for user-space, if we don't know about it
<emersion>
the exact rules for a CRTC to page-flip, that is
<MrCooper>
seems somewhat surprising that there would be a flip with no plane state in the commit
<emersion>
you could flip just to switch VRR on/off
<emersion>
without any other change
<emersion>
i'm sure there are more cases like this
<MrCooper>
then you can re-set the primary plane's FB_ID to the same value
<emersion>
we're talkiong about documenting current behavior here
fab has joined #dri-devel
<emersion>
you can not do it, but also, why not?
<MrCooper>
because a flip is conceptually a plane operation, not a CRTC one
<emersion>
for user-space that tries to only include what's actually changed in atomic commits, it would be a pain to handle
<emersion>
inconsistent at least
<emersion>
hm, i don't think a flip is a plane op
<emersion>
the final on-screen image is affected by more than just planes
<emersion>
GAMMA_LUT, for instance
<MrCooper>
so changing the FB_ID of an overlay plane isn't a flip?
<emersion>
i think we should definitely allow changing the CRTC GAMMA_LUT, without any planes, and that should trigger a page-flip
<pq>
Flip is to do with FB_ID, while a (screen, CRTC?) update is more, IMO. Everyone just talks about "flip" then they mean "update".
<emersion>
right, "flip" might not be the right world, but it's used in the PAGEFLIP_EVENT flag
<pq>
good point
<emersion>
you "flip" the CRTC from the previous state to the next state...
<pq>
traditioanally an update without FB_ID didn't make much sense
<pq>
Didn't "page flip" originally mean flipping individual pages to other pages from what the hardware was reading as an FB?
<pq>
since then we've re-purposed "page flip" to mean "buffer flip", and seems it's now generalizing into a "state flip"
<MrCooper>
maybe, would have to be last millennium though
aravind has joined #dri-devel
<MrCooper>
one reason why I'm being pedantic is that at least with AMD GPUs, I suspect triggering scanout with VRR requires actually programming a plane address register
<MrCooper>
i.e. the driver would need to program plane HW state for a CRTC-only commit
LinuxHackerman has quit []
<MrCooper>
pq: I started working on GPU drivers at the end of last millennium, and since then I haven't seen the term "page flipping" refer to anything other than programming a different buffer address
<MrCooper>
my mental image has been that of flipping a page in a book, as opposed to drawing something new onto the same page
<pq>
I've probably read some historical remarks.
<cwabbott>
hakzsam: is there any reason radv doesn't support descriptorBufferCaptureReplay?
yyds_ has quit [Remote host closed the connection]
<emersion>
it's made visible on the website, and then we can understand better what features are available where
<tzimmermann>
emersion, we've added that second connector with linux 6.6
<emersion>
right, that one was captured on 5.4
Daanct12 has quit [Quit: WeeChat 4.1.1]
<tzimmermann>
it represents the bmc's output.
<tzimmermann>
it fixes the bmc output on systems without connected vga cable
<tzimmermann>
we could do without that connector, but looks like the natural solution
<emersion>
hm
<emersion>
yea, it makes sense to me
<emersion>
the VGA monitor may have a completely different EDID and stuff
<tzimmermann>
emersion, IIRC the problem was that as soon as one unplugs the vga cable, the driver thinks that nothing is being displayed and has no idea what's going on. so it reports minimal capabilities. with the bmc connector we can always have an active output with high resolutions, etc
<tzimmermann>
jfalempe, i'm going to upload that data to simon's webpage. maybe that can be fixed in userspace
<emersion>
please do note that implementing cloned CRTCs in userspace is far from being trivial
<emersion>
can require quite a bit of restructuring and refactoring
<tzimmermann>
emersion, may i ask why?
<emersion>
because it breaks the "one connector == one swapchain" concept
<emersion>
a lot of userspace has a single object/struct for each connector+CRTC pair
airlied has quit [Ping timeout: 480 seconds]
<tzimmermann>
i see
<zamundaaa[m]>
There's also not a lot of use cases with consumer hardware where you need display cloning with the hw, so supporting them isn't a priority
<emersion>
on top of this, it's not a given that user-space will do "the right thing" by default
<tzimmermann>
we could handle this case in the driver. it just doesn't seem right either.
<emersion>
weston is the only compositor i know that supports cloned CRTCs, and i think it will only try that if told in the config file
<tzimmermann>
hearing that, i guess i better start working on a kernel solution quickly :)
<emersion>
i do agree that the user-space solution would be cleaner in theory
<emersion>
sadly that's not going to work with today's user-space
<emersion>
if we want to support both, we could have a DRM client cap "i support cloned displays"
<pq>
tzimmermann, FWIW, Weston implements this "shared CRTC" clone mode, if you happen to write your weston.ini that way.
<tzimmermann>
my other appraoch is to model this as drm bridge. it would not affect the user space
<tzimmermann>
so the tx-chip itself is a bridge and the bmc is a bridge, and the conenctor is a bridge conenctor, like this: enc -> tx -> bmc -> connector
<tzimmermann>
and the bmc bridge would return/detect something if the earlier bridges didn't
<pq>
is most userspace unable to understand that some connectors might not have any free CRTCs left? So it would light up one connector at least.
<emersion>
yeah, i'd expect current userspace to light up a single CRTC
pochu has quit [Quit: leaving]
rz has quit [Remote host closed the connection]
frieder has quit [Ping timeout: 480 seconds]
rz has joined #dri-devel
<jfalempe>
tzimmermann, thanks, (I had to go to a meeting, I'm back)
<LaserEyess>
08:14 < emersion> right, that one was captured on 5.4
<LaserEyess>
also used as a bmc driver, I was mostly curious what drm_info would show and how it would stack up against other drivers, never thought it would ever be relevant
frieder has joined #dri-devel
AntonKi8 has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
kts has joined #dri-devel
yuq825 has quit []
simon-perretta-img has quit [Ping timeout: 480 seconds]
mripard has quit [Quit: mripard]
mripard has joined #dri-devel
maxzor has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
mripard1 has quit []
kts has quit [Read error: Connection reset by peer]
<sima>
emersion, the problem with a "I support cloned modes" userspace flag is that cloning is the old way
<sima>
like xrandr can do it
<sima>
tzimmermann, pq ^^
<emersion>
hm, right…
<emersion>
if we wanted, we could have the cap default to 1
<emersion>
and let user-space degrade it to 0
<sima>
and there really isn't much reasonable we can do in the kernel, because "cloned but lower res" or "which one do you want at which res" is very much a policy/config thing
<emersion>
yeah, agreed it's not super great
airlied has joined #dri-devel
<sima>
like what we could do is maybe a really silly dbus service which does the clone setup for the dumb-as-brick compositor ...
<sima>
like hand it a leased drmfd with only the lower-res connector
<sima>
and when it enables that we enable the other output with the same reduced mode on the same crtc
<emersion>
all compositors are dumb-as-brick atm :)
<sima>
still horrendous, but avoids the "pass an Xorg.conf on the kernel cmdline"
frieder has joined #dri-devel
yyds has joined #dri-devel
<emersion>
would probably work with hacks
<sima>
yeah just about never turn off the crtc with atomic, because it'll fail due to the phantom connector
<emersion>
(hacks because it's not easy to figure out when a leased CRTC becomes enabled)
<emersion>
(and probably more issues)
<sima>
with legacy crtc it works, because for reasons that clears all connectors implicitly
<emersion>
ah yeah
<emersion>
fun
simon-perretta-img has joined #dri-devel
<sima>
emersion, inglorious polling, lots of it
<emersion>
:D
<sima>
tzimmermann, gnome falling over because it can't light up the 2nd connector is a more general bug though
<sima>
there's lots of cases where you have more connected outputs than crtc possible
Haaninjo has joined #dri-devel
<MrCooper>
yeah, a mutter issue should be filed about that if there isn't one yet
rgallaispou1 has quit [Read error: Connection reset by peer]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Haaninjo has quit [Remote host closed the connection]
fab has quit [Quit: fab]
Haaninjo has joined #dri-devel
pochu has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Haaninjo has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
macslayer has joined #dri-devel
yyds has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
<tzimmermann>
for the bug here, it would also be ok if gnome would simply ignore certain connectors
<tzimmermann>
the bmc is a virtual connector
<emersion>
that's what i'd expect current compositors to do -- the fact that GNOME just freaks out is definitely something that should be fixed as said earlier
<tzimmermann>
or could we export a preferred connector for each crtc?
<airlied>
tzimmermann: can you try removing any monitors.xml you might have and see if gnome copes
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
<tzimmermann>
airlied, there's no monitors.xml (in ~/.config)
frieder has quit [Remote host closed the connection]
heat_ has quit [Read error: Connection reset by peer]
<jenatali>
Oof. lower_io_to_temporaries is completely broken for the case where one var is loaded in multiple different ways
i-garrison has quit []
i-garrison has joined #dri-devel
apinheiro has quit [Quit: Leaving]
cmichael has quit [Quit: Leaving]
sgruszka has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
<gfxstrand>
dschuermann, mareko: Does the v_mul_legacy_f32 instruction always flush denorms? Does it have a flag for flushing denorms?
alanc has joined #dri-devel
<gfxstrand>
On NVIDIA, MUL.FMZ always flushes denorms so I'm wondering if we can just make that the required behavior of the NIR op and optimize accordingly.
pochu has quit [Quit: leaving]
<gfxstrand>
jenatali: Uh, what?!?
<jenatali>
gfxstrand: There's a GLSL 4.40 test that does input - interpolateAtCentroid(input). That generates NIR which does load_deref, load_interp_deref, and then compares the results. When lowering I/O to temps, both of those loads immediately store to the same temp var, so the interp result overwrites the base load
<gfxstrand>
Oh, yeah, you should really only use it for outputs, not inputs
<gfxstrand>
IDK why you'd use it for inputs
<jenatali>
Yeah we were just setting the nir flag and the GL frontend used that to apply it to inputs and outputs
<jenatali>
I don't really know why you'd use it for inputs either
<emersion>
sima: do you have thoughts on the dma heaps thing? or no time for this? or should i ping you some otehr time?
<jenatali>
Surprisingly, just removing the nir flag caused almost 0 regressions and fixed a test, so... guess I'm just gonna do that
<gfxstrand>
:)
<jenatali>
And that should clean up my last failures from GL4.4, hooray
<gfxstrand>
\o/
kzd has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
<emersion>
that's an interesting looking Message-Id :o
<sima>
emersion, I'm not seeing where mripard suggests some default stuff in that thread?
<emersion>
part of it is "we should make it generic"
<sima>
ah got confused by lore's thread display, I didn't see all the replies
<emersion>
and "Yeah, I agree here, it just seems easier to provide a global hook"
<emersion>
yeah, i "expanded flat", maybe wasn't the right thing to do
<sima>
so the problem is, for a lot of cases we flat out don't yet have existing dma-buf heap implementations
<sima>
like page allocator (compatible for gem shmem helpers) and cma heap exist iirc
<sima>
but virtio needs virtio buffers, vmwgfx needs vmwgfx buffers
<sima>
all the discrete need vram buffers
<sima>
and there's no dma-buf heap for these even
<sima>
so if the goal is to roll this out for everyone right away it means you get to look at around 100 drivers and write a handful of dma-buf heaps
<sima>
that's ... not going to happen
<sima>
so driver-by-driver like we do with every other feature, but broad enough consensus that it'll actually work for all of them, including the funny ones
<emersion>
sima, i believe mripard wants to expose a heap for all display drivers involved in a split/render SoC
<emersion>
to stop (ab)using dumb buffers in Mesa
<sima>
yeah, but don't try to get there with a default
<sima>
cause it's just wrong in a bunch of cases and so will just teach generic userspace that it cannot rely on that info
<emersion>
okay, sounds like we agree here
<sima>
I guess what you could try is include it as part of gem helpers
<emersion>
yeah
<emersion>
sima, do you have opinions for the naming of the heaps?
<sima>
so that when you use shmem helpers you automatically get a sysfs link to the system heap
<sima>
and cma helpers gives you the sysfs link to cma heap
<sima>
and everyone else is too special and gets nothing
<sima>
or maybe more motivation to switch to helpers :-)
<emersion>
i think something like "vc4_cma" would make more sense than "kms_cma" or "kms_scanout"
<sima>
why do you want to name the heaps?
<emersion>
heaps need to have a name
<emersion>
they show up in /dev/dma_heap/
<sima>
yeah but we have 2 default ones
<sima>
those should be enough ...
<emersion>
hm, i'm confused
<emersion>
the point of this RFC patch is to add a VC4 CMA heap
<sima>
why
simon-perretta-img has quit [Ping timeout: 480 seconds]
<emersion>
to… allocate scanout capable memory
<sima>
yeah but you just need contig memory
<sima>
the cma heap in drivers/dma-buf/heaps/cma_heap.c should be enough?
<emersion>
hm
<sima>
if drivers create random heaps then funny stuff is going to happen
<sima>
plus angry missives from dma-api maintainers I'm sure
glennk has quit [Ping timeout: 480 seconds]
<emersion>
i agree that centralized heaps created outside of DRM drivers are better
<sima>
like for vmwgfx I think a vmwgfx heap in the vmwgfx drivers is probably ok
<emersion>
but i didn't think that regular system CMA memory would do just fine?
<sima>
but already for virtio there's common infra so you can share virt buffers across display and camera and other things
<sima>
so probably want a virt_heap in the shared repo
<sima>
ttm I frankly haven't thought about too much yet
<emersion>
i need to read up more vc4 code i think
<sima>
emersion, so I think depending upon dt you can have more than one cma area
<sima>
and some of them are per-device
<sima>
and those aren't exposed yet in the cma-heap
<sima>
so if that's the case, we'd need to expose these driver heaps somehow
<emersion>
the CMA areas have different properties right?
<sima>
I think you can still have multiple devices using the same cma heap
<sima>
tbh I'm not sure how much this is the case in practice, but we definitely discussed the need for stuff where you have 2 cma heaps
<sima>
for some "my memory controller is fucked" reasons
<emersion>
like write-combined and stuff?
<emersion>
cacheable etc
<emersion>
USWC
<emersion>
note how unfamiliar with this stuff i am :P
<mareko>
jenatali: doing lower_io_to_temporaries for inputs may be required for variable indexing of inputs
<sima>
hm from a few quick git grep it looks like only special reserved memory regions for per-device have these private heaps
simon-perretta-img has joined #dri-devel
<jenatali>
mareko: yeah fair enough. DXIL doesn't need that though
<mareko>
jenatali: I do know that there are other problems with lower_io_to_temporaries, for example, if variables aren't sorted by location, the pass breaks
<jenatali>
Ooh that's fun...
iive has joined #dri-devel
<jenatali>
All the more reason to rely on it less
<sima>
emersion, ok I got confused, I have no idea when/how this is actually a device-private cma and when not in practice
<sima>
but for a given struct device we can check whether it's using the default cma or not, so could still implement this generically
<sima>
I think at least
<mareko>
gfxstrand: denorm flushing is controlled by a global enable bit for all FP32 instructions except min/max, radeonsi always flushes FP32 denorms
tobiasjakobi has quit []
greenjustin_ has joined #dri-devel
angerctl has joined #dri-devel
treeq[m] has quit []
lynxeye has quit [Quit: Leaving.]
Namarrgon has quit [Ping timeout: 480 seconds]
cbraga has joined #dri-devel
greenjustin_ has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
<emersion>
sima, what is the difference between dma_alloc_wc() (used by vc4 for dumb buffers) and cma_alloc() (used by the CMA DMA-heap)?
<sima>
about 200 layers of lasagna
<emersion>
yum
<sima>
so the dma_alloc are for devices, and are meant to fully abstract away details like where & how memory is allocated
<sima>
with the very neat idea that for the driver it doesn't matter whether it's contig memory
<sima>
or a pile of pages that gets remapped by an iommu to just look contig
<emersion>
hm, i see
<sima>
the reality tends to be seriously more disappointing in many cases, but that's aside
<sima>
the cma_alloc is the actual contig alloc function
<sima>
which the dma-api uses to implement the abstract magic
<emersion>
does cma_alloc give out WC memory?
<sima>
and which the dma-buf heaps uses to implement the same magic (because it'll call into dma_map apis to get the rest of the way to the same situation as directly calling dma_alloc)
<sima>
uh
maxzor has joined #dri-devel
<sima>
that's I think where you need the right heap and all that
tomeu has quit [Quit: Client limit exceeded: 20000]
<sima>
and arch specific nonsense
Aura has quit [Ping timeout: 480 seconds]
<emersion>
you mean we may need to add a cma_wc heap?
<sima>
emersion, given that both heaps seem to do explicit cache management I think you get wb
<sima>
and lots of flushing ...
<sima>
emersion, given how much of userspace consistently uses begin/end_cpu_access dma-buf ioctl, probably yes
<sima>
or you just forget cpu access for these
<emersion>
user-space is missing these?
airlied has quit [Ping timeout: 480 seconds]
<sima>
I think most doesn't bother and gets seriously surprised when they get a wb dma-buf and the resulting cache dirt :-)
<emersion>
i mean this is new uAPI kind-of so we don't need to be held back by old user-space
<sima>
quick grep says agx and iris gallium drivers and vulkan wsi helpers even bother to use DMA_BUF_SYNC
<sima>
emersion, ah I guess then you could try to fix the mesa drivers as they go boom
<emersion>
yeah
<sima>
shouldn't be needed for more than glReadPixels and similar things
<emersion>
yup
<sima>
might even be faster for that since you get full caching
<emersion>
so tl;dr is that the existing CMA DMA-heap should give us WC and we don't need another one?
<emersion>
hm i guess i'll just try and see with that existing heap
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
Ahuj has quit [Remote host closed the connection]
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
karolherbst has quit []
Guest6525 has quit []
karolherbst has joined #dri-devel
flom84 has joined #dri-devel
karolherbst has quit []
karolherbst has joined #dri-devel
Kayden has quit [Quit: -> JF]
Ahuj has joined #dri-devel
glennk has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
Tooniis[m] has quit []
vdavid003[m] has quit []
viciouss[m] has quit []
Ahuj has quit [Remote host closed the connection]
Ahuj has joined #dri-devel
danylo1 has quit []
Mis012[m] has quit []
fab has quit [Quit: fab]
gouchi has joined #dri-devel
heftig has quit [Quit: Client limit exceeded: 20000]
sivileri has joined #dri-devel
kusma has quit []
Ahuj has quit [Remote host closed the connection]
pankart[m] has quit []
q4a has quit []
vidal72[m] has quit []
cheako_ has quit []
cheako has joined #dri-devel
jhli_ has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
<javierm>
so a cma_wc makes sense if the current one wb
<javierm>
*is wb
sivileri has joined #dri-devel
crabbedhaloablut has quit []
gouchi has quit [Quit: Quitte]
Haaninjo has quit [Quit: Ex-Chat]
Aura has quit [Ping timeout: 480 seconds]
Mangix has quit [Read error: No route to host]
Mangix has joined #dri-devel
yang3__ has quit []
yang3 has joined #dri-devel
sivileri has quit []
sivileri_ has joined #dri-devel
<sivileri_>
Hello folks, my name is Sil. I've been working on video features for frontend/va and the gallium d3d12 driver
<sivileri_>
We're considering adding a new video frontend, a video encoder component that implements the Windows MFT (media foundation transform) interface on top of the gallium video pipe interface.
<sivileri_>
As part of that, we'd be looking to extend the pipe interface and other video frontends like VA with some new features, e.g. VUI coding, byte-based slice encoding, etc
<sivileri_>
Anybody have any opinions or thoughts on that? No timeframe for when we'd be looking to upstream, but is that something that upstream folks would like to see?
<emersion>
hi, are you working at Microsoft with the d3d12 folks? if not, you should probably get in touch with them
vliaskov has quit []
<jenatali>
Yes, Sil's on our team
<emersion>
is MFT somewhat similar to vaapi?
<emersion>
have you identified that kind of gallium changes that would be necesary?
<emersion>
the kind*
EricCurtin[m] has quit []
<sivileri_>
Yeah, MFT is like VA (maybe a bit higher level like not exposing reference frames, B frame reordering, etc to the app above)
<sivileri_>
So far, I identified only extensions necessary to the existing p_video_* files
jkqxz_ has quit []
jkqxz has joined #dri-devel
<emersion>
missing features?
<sivileri_>
exposing new H264/HEVC syntax like some missing VUI params, some missing SPS params
<sivileri_>
exposing slice coding specifying max bytes per slice instead of macroblocks, etc
<jkqxz>
What is the motivation for making an internal MFT interface rather than making a VAAPI (or Vulkan) MFT? MF is so high level that there isn't really much there.
<sivileri_>
(which btw would also be supportable by VA frontend)
<jkqxz>
The header stuff is all just packed headers in VA where you can do whatever you want.
<sivileri_>
The headers today are coded by the drivers (e.g radeonsi, d3d12) from the pipe structures, and the MF frontend would just consume those instead of re-coding/repacking the headers
<sivileri_>
The MFT/CodecAPI can sit on top of the pipe_video* interface directly without having to also map MFT/CodecAPI -> Vulkan/VAAPI -> pipe. And for VAAPI for example we'd need to pull in the libva runtime too
<sivileri_>
MF would control things like the GOP pattern, B frame submission reordering (display order vs encode order)
<sivileri_>
(MF frontend)
<sivileri_>
Can also manage things like intra-refresh tracking from -len, period args onto the intra-refresh pipe interface
<jkqxz>
Urgh. I hadn't realised that Mesa VA packed headers were implemented by parsing the supplied header and then trying to regenerate the things it knows about it on the other side. That's horrifying.
<jkqxz>
Yeah, standalone MF frontend makes more sense to avoid that brokenness then.
<Lynne>
also, vulkan doesn't support slice decoding yet
<Lynne>
while vaapi doesn't really support frame-level decoding (if that matters, the API supports it, but programs like ffmpeg do not, no idea about drivers, but guessing not)
AntonKi8 has quit [Read error: Connection reset by peer]