<anholt>
alyssa: feels like your blend color you're passing as a uniform should be clamped outside the shader?
<alyssa>
anholt: that doesn't solve the problem for SNORM
<alyssa>
SNORM format, constant colour of -0.5 (which is in bounds for SNORM)
<alyssa>
and then the blend factor is ONE_MINUS_CONSTANT = 1 - (-0.5) = 1.5 which is out of bounds and needs to be clamped to 1.
<anholt>
whee. ok.
<alyssa>
For UNORM it would suffice to clamp in the driver
<alyssa>
right now lower_blend has two actual users, the mali and agx gl drivers
<alyssa>
mali is specializing blend shader to the blend constant (big yikes but arm does the same thing and it hasn't blown up in our face yet..>)
<alyssa>
so will constant fold out
<alyssa>
and agx uses nir_opt_preamble so the fsat will happen in the preamble shader and be basically free, except for eating some extra uniform slots
<alyssa>
I guess it's worse for panvk since preambles aren't free on mali
<alyssa>
(but also, more driver overhead/complexity to do the clamp there since it's format dependant, and also I doubt anything cares nothing is fsat bound.)
<alyssa>
dr. ekstrand, or how i learned to stop worrying and love my shitty SIMD VLIW hardware
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
yuq825 has joined #dri-devel
jdavies has joined #dri-devel
jdavies is now known as Guest1787
<alyssa>
let me know if there's review I can tat with
Danct12 has joined #dri-devel
eukara has quit []
Guest1787 has quit [Remote host closed the connection]
sh_zam has quit [Read error: Connection reset by peer]
sh_zam has joined #dri-devel
codingkoopa has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
codingkoopa has quit []
codingkoopa has joined #dri-devel
codingkoopa has quit []
codingkoopa has joined #dri-devel
junaid has joined #dri-devel
<Lynne>
huc fw?
<airlied>
some video decode/encoder fw blob
<airlied>
mostly uesd for lower power usage
<Lynne>
so, not commonly installed?
<airlied>
I think tigerlake+ it might be used, trying to work out where it happens on dg2 etc
<Lynne>
the mess spans even to binary blobs
<airlied>
might be easier to propose slice mode for h265 :-P
junaid_ has joined #dri-devel
<airlied>
I think av1 dec might be possible without huc, but it's a long thread to pull
<Lynne>
the vulkan way for lice decoding would be to have a semaphore signalled on each, with a final decode operation which waits on all, does deblocking and film grain, and signals the output frame semaphore
<Lynne>
*lice
<Lynne>
SLICE
<airlied>
oh so you'd put one slice per command buffer
<airlied>
not sure how the hw/fw would deal with that though
<airlied>
I think the hw would want all the slices in one command buffer
<airlied>
at least the intel slice mode, you just add more slice bits to the command buffer and the blastSlice bit gets set on the last one
<Lynne>
really? I thought it did scheduling on a per-slice basis
agd5f_ has joined #dri-devel
<airlied>
from the programming info I don't see it
<Lynne>
welp, it may be doing it on a firmware level then
<Lynne>
I don't mind the single command buffer approach either
<Lynne>
just as long as I don't have to copy the slice data...
<Lynne>
wish I could prefetch host-mapped data onto the GPU
<airlied>
I think having slice offsets would be fine into the bitstream
<airlied>
better having vaapi decode the slice headers than the vulkan driver doing it
agd5f has quit [Ping timeout: 480 seconds]
<Lynne>
you mean the short mode?
kzd has quit [Quit: kzd]
<airlied>
Lynne: short mode would work with current interface, but the only hw support for shortmode needs huc fw
<airlied>
the long mode hw works without huc fw, but we can't program that without the vulkan driver dceoding slice headers
<airlied>
and I went down that path for h264 and am quite certain it should be done anywhere else :-P
danvet has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<Lynne>
is the huc fc incompatible with other firmware?
<robclark>
Lynne: when it comes to video "lice" decoding might not be such a typo :-P
<airlied>
Lynne: no it should work fine once it's loaded I think
<airlied>
Lynne: also I think intel av1 decode might require a batch buffer per tile
* airlied
is slowly finding the useful comments in the sea of crpa
<airlied>
crap
<Lynne>
so the huc fw is some additional firmware that would need to get loaded alongside the regular fw?
<Lynne>
that wouldn't be so bad, it would take a while, but downstream would ship it
<airlied>
I think it's already shipped for tigerlake+
<airlied>
and probably for older just not eanbled
<airlied>
and on DG2 there is some other way of loading it, which I'm not sure I understand, need to play with my dg2 a bit more to even see if it claims hevc short
<airlied>
"Currently, each batch buffer can contain only 1 tile to be processed, it cannot contain more than 1
<airlied>
tile or the entire tile group of tiles"
<airlied>
there we are, this will make the AV1 vulkan interface need some more thought
<airlied>
you have to resend all the frame state before each tile
agd5f has joined #dri-devel
<Lynne>
batch buffer == command buffer?
<airlied>
yes
bgs has quit [Remote host closed the connection]
<Lynne>
oof
<Lynne>
so you'd need my theoretical slice decoding model
<Lynne>
or firmware intervention
<airlied>
I'm not sure if you'd use secondary command buffers here or not
<airlied>
hmm reconciling intel and amd on this should keep the TSG busy :-P
agd5f_ has quit [Ping timeout: 480 seconds]
<airlied>
though it might be possible to just do it wiuth a flag
<tzimmermann>
javierm, no. before i read it, what's the summary?
heat has joined #dri-devel
<javierm>
tzimmermann: tl; dr plymouth should be able to handle CONFIG_VT=n now since was ported to use libinput, we still need a panic handler a la drmlog
<javierm>
the latter is the missing piece
<tzimmermann>
i see.
<danvet>
javierm, also some unclarity about what the standard kmscon should look like
<danvet>
my google fu failed me on this cage/foot thing
<danvet>
congrats to whomever named that project
<tzimmermann>
it's pretty cool that someone actually tried it
<danvet>
yes
lynxeye has joined #dri-devel
<javierm>
yeah, I tried after plumbers but had issues with weston, can't remember now the details but could check my notes
<javierm>
danvet: cage is a display server and foot a terminal emulator
<tzimmermann>
javierm, danvet, for generic drmlog, we'd first need better support for vmap/vunmap in several drivers. some drivers don't implement those interfaces well
<javierm>
tzimmermann: yeah, but as long as it works on simpledrm, it may be enough?
<javierm>
because I would expect this to be an issue for early boot in general
<tzimmermann>
javierm, i think we want toshow the log with any driver?
<tzimmermann>
no?
<javierm>
tzimmermann: yes, but my point was that even with VT, if the is a panic and you are in a wayland session, you may not be able to switch to VT anymore
<javierm>
*there is a panic
<danvet>
javierm, I still can't google cage :-/
<javierm>
danvet: I shared the repos above ^
<javierm>
but yeah, cage and foot are really not good names for search ability
<tzimmermann>
javierm, that seems fix-worthy as well
<danvet>
yeah just saying
yogesh_mohan has quit [Ping timeout: 480 seconds]
<danvet>
ah I need to throw in "wayland" for the search to work
<javierm>
tzimmermann: absolutely. What I'm trying to say is that it may not be a requirement to disable VT in distros
<tzimmermann>
fair point
<javierm>
danvet: I expect distros would choose their own combination of wayland compositor, terminal and greeter
<javierm>
for example, I guess the Fedora workstation folks would like to use mutter, gdm and gnome-terminal
<javierm>
just to avoid maintaining two sets in the distro, etc
<danvet>
javierm, I figured the idea is to have something really minimal so better chances it works as emergency
<danvet>
like if your mutter is toast because of some library bug
<javierm>
tzimmermann, danvet: btw, jfalempe said that he would like to look at drmlog + a panic handler to use it once he has some time
yogesh_mohan has joined #dri-devel
<tzimmermann>
sure
<javierm>
danvet: yeah, with my kernel/DRM developer hat, I would certainly prefer that
<javierm>
but I would also understand the other point since for sure the maintanance of that minimal wayland compositor + terminal + greeter will be done by the desktop folks
<danvet>
javierm, wasn't there already a thread on dri-devel? I have vague memories at least
<javierm>
danvet: about drmlog you mean or this discussion of the minimal "VT" using KMS ?
<javierm>
the latter was discussed in plumbers but I don't remember a thread
<danvet>
tzimmermann, uh backmerge overdue?
<danvet>
I also need one because trivial conflict in merging the ivpu driver in MAINTAINERS
<danvet>
because we don't yet have the accel subsystem entry
<danvet>
javierm, nah the minimal kernel console
<danvet>
output only, i.e. a true kernel console not a vt console which also does input
yogesh_m1 has quit [Ping timeout: 480 seconds]
<javierm>
danvet: yes, Noralf proposed a drmcon at some point
<danvet>
tzimmermann, can you pls ping me when the backmerge is done so I can apply the ivpu driver?
<javierm>
anyway, I just wanted to share that reddit thread since saw it on mastodon a few days ago and thought it was interesting :)
ice9 has joined #dri-devel
<MrCooper>
javierm: gnome-terminal seems on the way out, gnome-console is the new hotness :)
yogesh_m1 has joined #dri-devel
<javierm>
MrCooper: I actually meant gnome-console, is just that I conflated the names :)
<javierm>
MrCooper: but you get the idea, pretty sure you folks won't be interested in maintaining a weston, foot, etc packages in Fedora
<javierm>
only to be run in the initrd to have a minimal user-space console
yogesh_mohan has quit [Ping timeout: 480 seconds]
Lucretia has quit [Ping timeout: 480 seconds]
<tzimmermann>
danvet, sorry, didn't follow the discussion. You need a backmerge into drm-misc-next?
jkrzyszt has joined #dri-devel
<danvet>
tzimmermann, yeah so I can get the accel stuff needed for ivpu merging
<tzimmermann>
ok, working on it
<danvet>
thsd
<danvet>
*thx
<eric_engestrom>
am I missing something, or that VT=n thing means that if there's a bug in mesa (preposterous!) your fallback is toast too?
<eric_engestrom>
I wouldn't feel confident doing that for myself, so I'm rather surprised this is being discussed as being done by distros to end users
<MrCooper>
there's no requirement for the fallback display server to use Mesa
<eric_engestrom>
sure, but if it's mutter then it has to, right?
<eric_engestrom>
maybe I'm not awake enough yet, but also: any wayland compositor will need mesa (or another impl) for clients (foot in this discussion) to work
<emersion>
eric_engestrom: a display server can use pixman instead of GL/Vulkan
<javierm>
eric_engestrom: what emersion said, I'm not that familiar with mutter to know if can use a pixman backend or not
<emersion>
foot uses software rendering and no complicated library, which makes it quite nice for this use-case
<javierm>
in any case, a gnome-vt or whatever may be preferable than shipping weston or wlroots, at least both gnome-shell and gnome-vt would be based in libmutter
<emersion>
:sadface:
pcercuei has joined #dri-devel
<javierm>
but this is just my guess, if all distros could share the same minimal console that would be great
<javierm>
a kde based distro may want to use kwin in all places, etc
<emersion>
i hope non-Fedora distros have a different take :)
<javierm>
emersion: btw, I'm not talking for Fedora, not even for the Fedora workstation folks :)
<javierm>
this is just my guess, because in general distros tend to not agree on many stuff
<javierm>
emersion: otherwise all distros would had just settled on rpm, which of course is much better :P
<emersion>
lol
<javierm>
jokes apart, maybe if there's an upstream "user-space vt" project then all distros could adopt
<javierm>
if their maintanance work would not be that big
yogesh_m1 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
jkrzyszt has quit [Remote host closed the connection]
yogesh_mohan has joined #dri-devel
<danvet>
yeah if the emergency compositor/vt stack is exactly the same as you're regular desktop it's not going to be of much use
<danvet>
kiosk mode or not is kinda orthogonal
pixelcluster has quit [Quit: Goodbye!]
pixelcluster has joined #dri-devel
<tzimmermann>
danvet, backmerge done
djbw has quit [Read error: Connection reset by peer]
<danvet>
tzimmermann, thx
<javierm>
danvet: it could be a difference cadence though, and keep the original version used during installation in the "rescue" entry initrd, just like we do for the kernel
<danvet>
hm yeah that might help
<javierm>
danvet: just playing devil's advocate to the idea that all distros could agree on a single graphical stack for early boot
<danvet>
javierm, yeah that's very unlikely
<danvet>
unless kmscon gets resurrected and gets some official blessing
<danvet>
probably in systemd-emergenycon or so
<javierm>
danvet: yeah, but AFAIU from what Lennart said, is that they dropped that idea because noticed that would need i18n, a display manager, etc and basically duplicating what was done by wayland compositors + terminals
<javierm>
but having systemd to depend on a particular wayland compositor and libvte or whatever could be a trojan horse to make distros agree on a graphical stack for early boot :)
<javierm>
at least systemd-based distros, which are the majority
jkrzyszt has joined #dri-devel
<danvet>
javierm, yeah maybe part of plymouth instead, since that has a chunk of the deps
<danvet>
and needs glyph printing for logging now anyway
yogesh_m1 has joined #dri-devel
<javierm>
danvet: right, that may work indeed
<danvet>
javierm, since if you're non-graphical distro then systemd emergency console on serial or virt serial still works
yogesh_mohan has quit [Ping timeout: 480 seconds]
<danvet>
but with graphical you probably have plymouth around or similar
<danvet>
so avoids the entire "systemd has now a gl renderer, it's complete bloat" discussion
<javierm>
danvet: yeah
ahajda has joined #dri-devel
jdavies has joined #dri-devel
jdavies is now known as Guest1825
paulk has joined #dri-devel
paulk-ter has quit [Read error: Connection reset by peer]
jdavies_ has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
paulk has quit [Quit: WeeChat 3.0]
paulk has joined #dri-devel
Guest1825 has quit [Ping timeout: 480 seconds]
paulk has quit []
yogesh_m1 has quit [Ping timeout: 480 seconds]
yogesh_m1 has joined #dri-devel
Company has joined #dri-devel
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
paulk has joined #dri-devel
jkrzyszt has joined #dri-devel
Didgy has joined #dri-devel
yogesh_mohan has joined #dri-devel
Lucretia has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
hikiko has joined #dri-devel
yogesh_m1 has joined #dri-devel
kts has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
ice9 has joined #dri-devel
frieder_ has joined #dri-devel
frieder_ has quit []
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
hikiko has quit []
phasta has quit [Ping timeout: 480 seconds]
vliaskov_ has joined #dri-devel
phasta has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<tursulin>
danvet, airlied, mripard, tzimmermann: wrt 693e4b42-3883-8a6a-5181-0357e4b88767@linux.intel.com - one new api export from drm plus one i915 fix which uses it - acks/suggestions on which route to take to merge it?
<tursulin>
or even s/it/both/
tango_ has quit [Quit: I'm never quite so stupid as when I'm being smart (Linus van Pel)]
tango_ has joined #dri-devel
yogesh_mohan has joined #dri-devel
<mripard>
tursulin: is it really a fix? it doesn't look like one to me
<tursulin>
mripard: 2nd patch is i915 fix which needs the 1st
yogesh_m1 has quit [Ping timeout: 480 seconds]
<mripard>
wouldn't it be easier to backport if it was the other way around?
<tursulin>
mripard: other way around?
yogesh_m1 has joined #dri-devel
<tursulin>
local implementation and move it out to common later?
yogesh_mohan has quit [Ping timeout: 480 seconds]
<mripard>
yeah
<mripard>
but looking more into your first patch, it's indeed not going to be easy
<mripard>
if you want to take it through drm-misc-fixes, fine by me
<tursulin>
hm what do you see as not easy in that option?
<tursulin>
to clarify, sending both via drm-misc-fixes is fine by you?
<mripard>
yes
<tursulin>
Cool, could you scoop them up from the ml and merge? They passed our CI and user has reported them working fine so I am reasonably confident its all good.
yogesh_mohan has joined #dri-devel
Didgy has quit [Quit: Connection closed for inactivity]
yogesh_m1 has quit [Ping timeout: 480 seconds]
pjakobsson has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
pochu has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
psykose has joined #dri-devel
<mripard>
tursulin: applied and pushed both
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts_ has quit []
<tursulin>
mripard: thanks!
<tursulin>
hm stable tag did not get captured or you dropped it?
<tursulin>
indeed patchwork seems to have ignored it.. okay, will ask for it to be follow up
<tursulin>
followed up
itoral has quit [Remote host closed the connection]
yogesh_m1 has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
greenjustin_ has joined #dri-devel
greenjustin has quit [Ping timeout: 480 seconds]
jfalempe has quit [Remote host closed the connection]
yogesh_m1 has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
yogesh_m1 has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
devilhorns has quit [Remote host closed the connection]
illwieckz has quit [Ping timeout: 480 seconds]
ds` has quit [Quit: ...]
ds` has joined #dri-devel
kzd has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
<bbrezillon>
danvet: not sure you're the right person to ask, but I've been trying to implement a VM_BIND-like interface for pancsf, and I have a few questions
illwieckz has joined #dri-devel
Haaninjo has joined #dri-devel
ice99 has joined #dri-devel
ice9 has quit [Read error: Connection reset by peer]
<bbrezillon>
first thing to note is that, unlike Xe, the page table setup is all happening on the CPU, and I'm not directly in control of the pte allocations, since it's hidden behind the io_pgtable framework (io-pgtable-arm.c implem in my case). That means I can't easily reserve memory to guarantee the map/unmap operation will succeed.
yogesh_m1 has quit [Ping timeout: 480 seconds]
<bbrezillon>
(I'm trying to avoid the extra XE_VM_BIND_FLAG_ASYNC complexity)
yogesh_m1 has joined #dri-devel
<bbrezillon>
I mean, I can always flag the VM as inconsistent and fail all future jobs bound to this VM when such errors happen. On the Vulkan side, that would probably lead to a DEVICE_LOST error, which would force a VM recreation, but I'm not sure that's acceptable.
<bbrezillon>
jekstrand: in case you have any tips on that ^
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<dolphin>
bbrezillon: are you having a separate set of PTEs for the GPU, still?
<bbrezillon>
the second question is more an implementation detail. I see the Xe driver has its own implementation to deal with VMAs. I've been using drm_mm, but I guess there's a good reason for not using it (too heavy, probably). Mind detailing those reasons?
<dolphin>
if the application can fully control the PTEs, and they shoot themselves in the foot, shouldn't be a problem
<bbrezillon>
dolphin: yes
<bbrezillon>
by separate set of PTEs, you mean it's not shared with the CPU, right? We have a page table per GPU VM, and any map/unmap operation can only touch VM instantiated through a specific DRM fd
<dolphin>
yeah
<bbrezillon>
the thing is, there are situation where the user didn't do anything wrong, it's just that the kernel implem updating the page table can't allocate memory to map/unmap those pages (unmap can trigger 2MB PTEs into 4K ones, so mem allocation failures can happen there too)
<bbrezillon>
*2MB PTEs split into 4K ones
<dolphin>
right, if your PTEs are in system memory, then there's no way to predict future errors
<danvet>
bbrezillon, yeah that means you need to do pte setup as part of the execbuf ioctl, before the point of no return in drm_sched_job_submit
<danvet>
or _arm()
<danvet>
(I didn't check that detail again)
<danvet>
but also since you have integrated, that shouldn't be a big deal
<danvet>
discrete has to do pipelined pte because otherwise you can't pipeline moves, and with vram that's big time suck
<danvet>
bbrezillon, also jekstrand knows these things generally too
<danvet>
oh also in the vm_bind ioctl itself the point of no return is probably not the sched_submit for you (since you don't do anything pipelined on the gpu I guess)
<danvet>
but just the ioctl
<bbrezillon>
'pte setup in the execbuf ioctl' => hm, how would that would with async vm_bind ops (where ops depend on other fences being signaled, potentially moving things around in the page table)
<danvet>
so you probably also have no need for an out fence
<danvet>
bbrezillon, yeah you don't have much async vm_bind
<danvet>
since no gpu pipelining
<danvet>
also you still need the execbuf path in case the shrinker or something nuked your working set
<bbrezillon>
by async, I mean it still needs to wait for the deps
heat_ has joined #dri-devel
<danvet>
in full generality at least, I'm not sure how full featured your panfrost is
<danvet>
bbrezillon, you shouldn't need to wait for any deps
<bbrezillon>
(didn't hook up the shrinker yet)
<danvet>
or at least I thought we ditched that part outright since mesa vk really doesn't need it
<danvet>
(on intel side lvl0 has opinions, but personally I'm leaning a bit towards that they're wrong, since all we do is trade a kernel thread for a userspace thread)
<danvet>
bbrezillon, drm_mm feels a bit a mismatch
heat has quit [Ping timeout: 480 seconds]
<bbrezillon>
how do you implement vkQueueSparseBinding()? Waiting for deps in a userspace thread?
<danvet>
I do think a drm_vma or drm_vm would be nice, since the real tricky thing here is the locking
<danvet>
bbrezillon, set the magic mesa vk bit to get a userspace queue
<danvet>
for that you need to ask jekstrand
<bbrezillon>
ok
<danvet>
once you have that you really only need the out_syncobj on dgpu so that you can benefit from a bit deeper pipelining on the gpu side of thigns
<danvet>
that was at least the idea
<bbrezillon>
so no VM_BIND ioctl needed, just synchronous VM_MAP/UNMAP ones
<danvet>
well that's vm_bind/unbind really in your case
<danvet>
or was meant to be
<danvet>
I'm maybe a bit out of the loop
<danvet>
also I think jekstrand made some noises about yet another silly corner case and maybe we again need the kernel thread
<danvet>
in that case I think a drm_vma.c which extract these common pieces into a helper would be really good
<danvet>
since too many ways to get it wrong, and at least with the mesa queue helpers there really should be just one standard way to do this across drivers
<danvet>
and no need for per-driver implementation with slightly different semantics
<danvet>
since then you'd just need to absorb these mismatches again on the mesa side, which makes no sense at all
<danvet>
(aside from more fundamental stuff like dgpu and their gpu move pipelining, which isn't really a thing on integrated in many cases)
<bbrezillon>
well, when I said MAP/UNMAP that was just a way to differentiate from the xe/i915 VM_BIND ioctl, which is async by nature
<jekstrand>
DavidHeidelberg[m]: No, I've not looked at it at all
<bbrezillon>
re drm_vma.c => that'd be great to have
<bbrezillon>
FYI, I've been using drm_mm because I have a flag that allows auto-VA assignment (in the 0x800000000000-0xffffffffffff VA range), but that's probably not needed if we let userspace control the VA space (I guess mesa's util_vma is here to automate that a bit)
linkmauve has left #dri-devel [Error from remote client]
Jeremy_Rand_Talos has joined #dri-devel
<danvet>
bbrezillon, yeah imo for new uapi just let userspace deal with the entire layout
<danvet>
it's really not hard to have a va allocator
<danvet>
wrt vm_bind being async, I'm still hoping that it's as non-async as we can get away with
<bbrezillon>
danvet: let me check if I got this right. drm_{vma,vm}.{c,h}, and generic VM_{CREATE,DESTROY,BIND,UNBIND} ioctls
<danvet>
because memory fences queues in the kernel are just a funny idea
<danvet>
as in should probably cgroup account that stuff somehow at least :-)
<danvet>
bbrezillon, I think jekstrand mentioned to also go full generic ioctl
<danvet>
I'm not sure whether that's a step too far, we might be in extensions overkill land with that
<danvet>
but maybe default implementations and stuff like that
<danvet>
so driver parses it's own ioctl struct and does any handling of special cases
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<danvet>
and then you just stuff that into the helper and done
<danvet>
with a few driver callbacks or something like that
Jeremy_Rand_Talos has joined #dri-devel
<bbrezillon>
sounds good
<bbrezillon>
yeah, you'd need callbacks for the page table ops
<danvet>
we've gone 100% driver specific in rendering, and I think we should make sure to not overcorrect here
<danvet>
because dri1 tried to do that, and it was a dumpster fire
<danvet>
and I think consensus from the cross platform teams is still that fully generic memory management isn't great (like on windows), endless amounts of driver bypass/extensions needed
<danvet>
I think agd5f_ has a solid take on this too (or at least I remember from some discussions way way back)
<danvet>
bbrezillon, but if we can get the big data structures and the locking/async sorted, then I think that's a huge win in at least semantic commonality
<danvet>
kinda like the sched stuff really isn't much, but it's /just/ enough to make reading random drivers easier
<danvet>
especially on the tricky bits like cross engine/sched reset impact
<bbrezillon>
is that really sorted out? :P
<bbrezillon>
before I go and try to extract drm_{vm,vma} bits out of the xe driver, is this something someone in the intel team is planning to work on/working on already?
<bbrezillon>
danvet: ^
<danvet>
I'm no longer on the xe team, so maybe ask on #xe ...
<danvet>
it was on a vague notion of an idea way back
<jekstrand>
bbrezillon: RE: userspace threads. Vulkan working group discussions started yet again about this and I think we're going to nuke vkCmdWaitEvents on host signals as an actual command buffer blocking operation. That would mean userspace threads are fine. There are tests that are still problematic, though. I don't remember where that discussion is at off-hand.
<jekstrand>
Sadly, I keep going back-and-forth on that. :(
<jekstrand>
danvet, bbrezillon: Big fan of doing something in common code. I didn't use drm_mm in Xe mostly because I didn't know about it and/or didn't think of using it for that. I was under the impression that it was mostly for allocating virtual addresses (which we don't need) rather than managing them.
<dj-death>
are you allowed to have 2 descriptions of the same binding in glsl but slightly different :
<dj-death>
like 2 variables somewhat similar but not quite
<bbrezillon>
jekstrand: well, it can do both, but it comes at a cost (keeping track of holes to allow fast VA allocation)
<danvet>
jekstrand, I'm always succeeding in purging the details from my brain, but why exactly is this something the kernel can do which userspace cannot?
<bbrezillon>
the drm_mm struct is definitely bigger than what we need for a purely userspace-based VA allocator
MrCooper has quit [Quit: Leaving]
<danvet>
like the only one I remember is making a dma_fence container thing out of a memory fence
<danvet>
and neitehr the kernel nor userspace really can do that
<danvet>
(and yes it hangs around in code, it's awkward)
<jekstrand>
dj-death: Yes
<dj-death>
jekstrand: arg...
<jekstrand>
dj-death: And, yeah, ANV might get that wrong. :-(
<danvet>
bbrezillon, yeah my take is to just have an absolute minimal drm_vma and drm_vm struct with emphasis on locking
MrCooper has joined #dri-devel
<danvet>
which drmm_mm explicitly leaves to users
<dj-death>
yeah I mean it's only reason the max length for storage image descriptor is 128 bytes ;)
<danvet>
so you could use drmm_mm internally, but it's not really a fit
<jekstrand>
dj-death: For SKL+, we can work around it pretty easily, though. I've just not typed the 3 patches.
gawin has joined #dri-devel
<jekstrand>
danvet: Vulkan has a future fence. ish. I'm trying to kill it at every opportunity.
<dj-death>
jekstrand: I though you did use the lowered surface in some cases
<danvet>
yeah I have vague memories of a shadow :-P
<bbrezillon>
danvet: I'm perfectly fine with drm_vma being a brand new object, it's just that I started with an hybrid VA allocation model, and drm_mm was convenient for that
<danvet>
yeah for hybrid drm_mm is convenient
<danvet>
maybe we should just use it internally and let drivers open-code if they want hybrid
<jekstrand>
dj-death: On SKL+, if you do a typed read from a surface with a format that doesn't support reads, you get R8, R16, R32, or RG32 data as appropriate.
<javierm>
tzimmermann: weird, commit 622113b9f11f ("drm/ssd130x: Replace simple display helpers with the atomic helpers") broke the ssd13x-spi driver but no ssd13x-i2c (where I tested when originally posting that)
<danvet>
maybe for some transitional stuff, but otoh I'm not sure anyone needs that
<jekstrand>
dj-death: On BDW and earlier, it'll hang. SKL falls back to a nice raw read for you.
<danvet>
xe is new and I haven't seen amdgpu really need much for their kernel-picked address mode either
<javierm>
tzimmermann: the changei s in the core drivers/gpu/drm/solomon/ssd130x.c driver, shared by the I2C and SPI drivers... and it just uses a regmap. I wonder what could make the difference
<dj-death>
jekstrand: okay, well BDW is another driver :)
<tzimmermann>
javierm, one sec
<jekstrand>
dj-death: Right now, though, the lowering code tries to be more clever with that about formats so when it dies the format conversion, it might assume RGBA8_UINT or something because it's less code in the shader.
<jekstrand>
dj-death: Yes. :)
<jekstrand>
The lowering code, however, is common.
<jekstrand>
danvet, bbrezillon: I see no reason why kernel VA picking and VMA management need to be the same thing.
<jekstrand>
You can always strap a VA picker on the front like we're effectively doing by putting it in userspace.
<danvet>
yeah worst case we have a drm_mm on the side or something :-)
<jekstrand>
If keeping that data adds cost to every driver that uses the common thing, I say torch it.
<jekstrand>
Yeah, that's what I meant
<bbrezillon>
danvet: oh, I'm definitely not trying to convince you to use drm_mm, if there's common bits to deal with VA allocation in mesa, I'd gladly use it
<danvet>
I don't worry about the memory usage, but just the potential fun if we let drivers come up with "interesting" hybrid models
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
<danvet>
it's a can of worms
<danvet>
so some strong guidance of the helpers to not do that sounds like a good idea
<bbrezillon>
and for kernel allocations, I guess I can use drm_mm and reserve the high VA range
bl4ckb0ne has joined #dri-devel
emersion has joined #dri-devel
<danvet>
bbrezillon, yeah for the kernel address space or whatever you can just whack a drm_mm on top of it
<danvet>
if you dont have a separate vm for kernel stuff (funny gpu design tbh) then the kernel/userspace gpu vm split becomes uapi anyway
<tzimmermann>
javierm, backlight and SSD130X_DISPLAY_ON moved from crtc to encoder
<danvet>
so maintaining a drm_mm just for the kernel portion should be fine
<tzimmermann>
could this be related?
<bbrezillon>
danvet: nope, no dedicated VM for kernel stuff on mali
<javierm>
tzimmermann: hmm, don't think so since otherwise the I2C panel would also be affected
<jekstrand>
What do you mean by "interesting hybrid models"? Some kernel-assigned and some userspace-assigned?
ybogdano has joined #dri-devel
<jekstrand>
Yeah, let's very much not do that.
<javierm>
tzimmermann: it's very strange. I guess will need to dig deeper on what's going on
<jekstrand>
Which is to say that I think Asahi and IMG both need that but we can handle it by userspace giving the kernel a range on boot or the kernel having a device query which is "here are my ranges, don't touch them."
<bbrezillon>
there's one for the FW, but you still have to map kernel allocated BOs to the user VM (like ring buffers, since the whole thing is designed with userspace scheduling in mind)
<jekstrand>
Not a range on boot. On device creation.
<jekstrand>
Before any VMs are created.
<jekstrand>
Or as part of VM creation.
<jekstrand>
bbrezillon: Ok, then we need userspace to give the kernel a range somehow.
<bbrezillon>
yep, and I assumed the regular user/kernel split we have for CPU
<jekstrand>
Oh, top bit set/not?
<bbrezillon>
yep
<bbrezillon>
that's assuming the GPU can supports 48-bit VA
<jekstrand>
Yeah, that's a reasonable convention assuming both are 48-bit VA.
<bbrezillon>
but I honestly hope all new GPUs do
* jekstrand
looks at the stupid 36-bit Intel GPU.
<tzimmermann>
javierm, i don't see much of a difference
<bbrezillon>
jekstrand: let me rephrase that, all new Mali GPUs do :D
<javierm>
tzimmermann: yeah, me neither. Is strange really
<jekstrand>
bbrezillon: Yeah, and Mali isn't likely to have to deal with more than 48 CPU-side any time soon.
<bbrezillon>
they expose the VA range through a feature reg, so in theory, I guess that's still configurable
<jekstrand>
My biggest concern with doing it all by convention is if it's going to cause problems with SVM down the line.
<javierm>
tzimmermann: but no worries, just in case it could ring a bell to you. I just noticed because booted a rpi4 that had a SPI panel connected but will take a look this weekend or smt
<bbrezillon>
jekstrand: but SVM is still subject to the regular kernel/userspace VA split, isn't it?
<jekstrand>
On anything that can be plugged into a PCIe slot, you have to deal with 56-bit (I think) on some of the bigger Xeons.
<jekstrand>
bbrezillon: Yes, but ^^
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
<bbrezillon>
(not my concern then :P)
<jekstrand>
bbrezillon: Also, if the kernel convention ever changes (seems pretty unlikely), that would break everything.
<jekstrand>
Is that considered immutable uAPI by now?
<bbrezillon>
I think that would break a lot of things anyway
<jekstrand>
Yeah
<jekstrand>
In that case, it's probably a fine choice for Mali.
<jekstrand>
Asahi and IMG I think are more restricted.
<bbrezillon>
but, let's say we want to make it configurable, it shouldn't be such a big deal
<jekstrand>
But, still, they can hand in some reserved VA ranges on VM creation and call it a day.
<bbrezillon>
as long as the kernel is left a reasonable amond of VA space
<bbrezillon>
> But, still, they can hand in some reserved VA ranges on VM creation and call it a day
<bbrezillon>
exactly
<bbrezillon>
I don't really mind doing that for mali as well
<bbrezillon>
it's just a matter of passing extra args to the VM_CREATE ioctl
ice99 has quit []
ice9 has joined #dri-devel
<bbrezillon>
danvet, jekstrand: on to my next question now. Is the dma_resv attached to the VM needed if don't support async bind/unbinding?
ice9 has quit [Quit: Leaving]
mbrost has joined #dri-devel
pallavim__ has joined #dri-devel
junaid has joined #dri-devel
<bbrezillon>
and I'm also not sure I understand why we need to add the job out_fence to external BOs (xe_vm_fence_all_extobjs()). I thought we wanted to be have explicit fencing everywhere, and when interacting with actors relying on implicit fencing, use the DMA_BUF_IOCTL_{IMPORT,EXPORT}_SYNC_FILE ioctls.
<danvet>
bbrezillon, there's 4 fences in the dma_resv, 2 for the kernel and 2 for implicit sync
<danvet>
the 2 for the kernel are needed for the shrinker to know what's up and stuff like that
<danvet>
so without shrinker you don't need it
<danvet>
but if you want eventually a shrinker, you need that and also the per-vm dma_resv trick for good fastpath
<danvet>
that 2+2 thing was the point behind könig's huge refactoring for dma_resv fence slots
dviola has joined #dri-devel
yogesh_mohan has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
yogesh_m1 has quit [Ping timeout: 480 seconds]
<gawin>
kernel guys: is there a deadline for legacy gpu drivers? I'm relatively close to get my AGP platform working (so I could check if drivers are in usable state).
yogesh_mohan has quit [Ping timeout: 480 seconds]
yogesh_mohan has joined #dri-devel
bgs has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Duke`` has joined #dri-devel
yogesh_m1 has joined #dri-devel
djbw has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
sravn has quit [Ping timeout: 480 seconds]
yogesh_mohan has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
<q66>
the legacy gpu drivers have long been useless anyway
phasta has quit [Quit: Leaving]
<q66>
they are dri1 drivers, which means modesetting is done by the xorg ddx
<q66>
the xorg ddx is therefore going to work even without the kernel driver (but you won't get acceleration, but for that you'd also need the mesa counterpart which was dropped in mesa 7.7 ages ago and current mesa can't even load the .so's)
<bbrezillon>
danvet: hm, ok. I need to dig further to understand how the xe shrinker works, and what it'd look like in pancsf
frieder has quit [Remote host closed the connection]
<soreau>
I was able to run wayfire on legacy r300 driver on RV350 some months ago before the legacy drivers were spilt, haven't tried with amber branch yet though
<soreau>
almost typed 'lagacy', ha
<gawin>
q66: this sounds right, once I was trying to get 3d driver for voodoo running, but without success
yogesh_m1 has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<MrCooper>
soreau: r300 is a Gallium driver, still alive and well
<soreau>
MrCooper: oh, I'm confused then
yogesh_mohan has quit [Ping timeout: 480 seconds]
illwieckz has quit [Ping timeout: 480 seconds]
yogesh_mohan has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
<dalurka>
q66: but they have sentimental value :)
tzimmermann has quit [Quit: Leaving]
<jekstrand>
bbrezillon: Part of the point of the dma_resv in the VM is also so that VM-tied BOs (most of them) don't need to be individually locked and fences extracted when you go to exec. You can just lock the VM dma_resv, grab its fences, and get 95% of your needed synchronization in one go.
alyssa has joined #dri-devel
<alyssa>
more to the point, "legacy drivers" is less about the age of the hardware and more the maintainence / modernity of the code
illwieckz has joined #dri-devel
<alyssa>
as far as I'm concerned, Lima is a modern driver
<alyssa>
It's Gallium, it's NIR, it does everything expected of a modern driver, it's just as modern as the latest 2022 shiny
<alyssa>
Sort of irrelevant that it's from 2008
<jekstrand>
Well, one day it'd be nice to require integers...
<alyssa>
grumble
<alyssa>
for better or worse Lima is shipping on new hw
<alyssa>
somehiw
<jekstrand>
It's free. That's how.
<alyssa>
;-D
<dottedmag>
oh, the company behind Mali is from Norway. This explains the codenames.
<dottedmag>
also, indirectly age of hardware matters: no new hw -> no users / no sponsors -> no maintenance
<q66>
gawin: i investigated running r128 on powerpc, so yeah, similar boat
<q66>
in a way
yogesh_m1 has joined #dri-devel
<q66>
though on powerpc the ddx does not actually deal with modesetting as it's used together with fbdev kernel driver (because on non-x86 you don't have vbe, which the ddx relies on otherwise)
<q66>
it's expected that the display is already set up by fbdev
<q66>
you can use this path on x86 too if you explicitly activate it
yogesh_mohan has quit [Ping timeout: 480 seconds]
<q66>
alyssa: doesn't that also preclude some old hardware by definition though
<q66>
wouldn't a gallium driver require a gpu that is capable at least of some degree of programmable shader stuff
<q66>
which would mean at least opengl 2.0 capability
<MrCooper>
indeed it does, which ~20 years old HW such as R300 satisfies
<q66>
yeah but r128 or voodoo would not
<q66>
they are fixed function hardware
heat_ has quit [Ping timeout: 480 seconds]
<q66>
r300 is radeon 9500+ iirc? so that's about the minimum
<gawin>
maybe r200/nv20 could be also used, but without something similar to gallium nine for d3d8 it wouldn't make much sense
<gawin>
(d3d8 also has shaders)
<q66>
r200 will support pixel shaders but not fragment shaders
yogesh_mohan has joined #dri-devel
<q66>
i think you need both
<MrCooper>
R200 had more or less fully functional vertex shaders only, no pixel shaders
<karolherbst>
use nv20 for what?
<gawin>
d3d8, but that's it
<karolherbst>
heh
<MrCooper>
that'd be Gallium eight then? :P
<karolherbst>
given that the nv20 driver was classic ...
<q66>
r200 is quite broken nowadays in practice too
<karolherbst>
yeah.. and even nv30 doesn't really work
<q66>
but then so is r300 to a large degree
<karolherbst>
I suspect everything before having _sane_ shaders doesn't really work :)
yogesh_m1 has quit [Ping timeout: 480 seconds]
<karolherbst>
for nv that would be pre nv50
<q66>
nv40 sorta works
<karolherbst>
mhhh
<q66>
unless you have a big endian system
<q66>
then it sorta works but worse
<karolherbst>
I mean.. we have been fixing a few bugs
<karolherbst>
but yeah.. probably good enough for xfce
<q66>
almost not
<q66>
I'd expect nv50 to be busted to almost the same degree but can't actually say
<q66>
i only have an nv40, in a powermac g5
<karolherbst>
nv50 actually works
<karolherbst>
compared to nv30 that is
yogesh_m1 has joined #dri-devel
<q66>
and I only ever have it do anything when booting the machine so that it actually boots (because the firmware expects an openfirmware-compatible gpu to be present)
<q66>
once kernel comes up it switches to r5 235 in another pcie slot
yogesh_mohan has quit [Ping timeout: 480 seconds]
alyssa has left #dri-devel [#dri-devel]
srslypascal is now known as Guest1861
srslypascal has joined #dri-devel
Leopold has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
Guest1861 has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
illwieckz has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
kts has quit [Quit: Leaving]
yogesh_mohan has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
yogesh_m1 has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
yogesh_mohan has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
agd5f_ has quit []
agd5f has joined #dri-devel
<agd5f>
gawin, I think the "sahders" on r200 supported like 8 instructions. Not really programmable per se
<airlied>
bbrezillon, danvet, jekstrand : please read the mailing list
<airlied>
generic gpuva mgr code posted a few days ago and is already being discussed
<airlied>
as part of the nouveau work
<agd5f>
danvet, bbrezillon yeah, windows guys are always complaining about vidmem (MS memory manager). We do pretty ridiculous things in the driver and hardware to deal with it
<danvet>
airlied, oops I'm behind a bit :-)
yogesh_m1 has joined #dri-devel
<airlied>
danvet: it uses drm mm bit first req was to move away
<jekstrand>
airlied: right. I should go read that
yogesh_mohan has quit [Ping timeout: 480 seconds]
illwieckz_ has joined #dri-devel
<jekstrand>
dcbaker: Got syn to pull in. Had to tweak your meson wrappers a bit, though.
heat_ has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Read error: Connection reset by peer]
oneforall2 has joined #dri-devel
Leopold___ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
yogesh_mohan has joined #dri-devel
<jenatali>
Uh... VK CTS seems to be ignoring the quadOperationsInAllStages bit?
yogesh_m1 has quit [Ping timeout: 480 seconds]
<jekstrand>
That's possible
<jenatali>
Now do I turn off quads, or do I turn off subgroups in VS/GS?
yogesh_mohan has quit [Remote host closed the connection]
yogesh_mohan has joined #dri-devel
<zmike>
turn off pc
<DavidHeidelberg[m]>
zmike:
<DavidHeidelberg[m]>
next piglit uprev is few minutes
yogesh_m1 has joined #dri-devel
<zmike>
hooray
<DavidHeidelberg[m]>
zmike: what change do you want? Also you may drop the change you do from Marge
<zmike>
the piglit MR I just landed
<DavidHeidelberg[m]>
ok, I'll uprev the piglit by one commit more
yogesh_mohan has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
I dropped your Mesa MR, I'll sent it with upreved piglit together.
<zmike>
k
<zmike>
ty
<DavidHeidelberg[m]>
np
gawin has quit [Ping timeout: 480 seconds]
yogesh_mohan has joined #dri-devel
Duke`` has quit []
yogesh_m1 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
yogesh_m1 has joined #dri-devel
<DemiMarie>
What does Intel PXP actually do, and is it useful for anything besides DRM?
yogesh_m1 has quit [Remote host closed the connection]
yogesh_m1 has joined #dri-devel
illwieckz_ has quit [Ping timeout: 480 seconds]
wastelander has joined #dri-devel
Kayden has quit [Quit: to lunch and office for a bit]
wastelander has quit []
yogesh_mohan has joined #dri-devel
ybogdano has joined #dri-devel
ybogdano has quit []
gouchi has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
illwieckz has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
yogesh_m1 has joined #dri-devel
sravn has joined #dri-devel
<DavidHeidelberg[m]>
Fishing for ACKs. It's ci-fairy uprev, wget -> curl migration and piglit uprev. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20788 So it's "huge MR", on other hand it tries to solve failures at HTTP 500 and similar errors, so it "should" improve reliability of CI these days.
mbrost has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
yogesh_mohan has joined #dri-devel
* jekstrand
now has a proc macro!
<jekstrand>
dcbaker: ^^
<DavidHeidelberg[m]>
I'm pushing to Marge, if anyone has serious objections speak now or keep silent until next uprev :P
mvlad has quit [Remote host closed the connection]
<dcbaker>
jekstrand: not surprised that you needed tweaks
bgs has quit [Remote host closed the connection]
jdavies_ has quit [Remote host closed the connection]
jkrzyszt has quit [Remote host closed the connection]
gawin has quit [Quit: Konversation terminated!]
ybogdano has quit [Ping timeout: 480 seconds]
illwieckz has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
freemint has joined #dri-devel
flto has quit [Quit: Leaving]
Ntemis has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
flto has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
yogesh_m1 has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
Ntemis has quit [Read error: Connection reset by peer]
frankbinns1 has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
gouchi has quit [Remote host closed the connection]