<clever>
what if you didnt actually change the mode of the 2d subsystem, but just what image is being rendered? could you just display the fbcon image again, at whatever resolution the hw is currently at?
<clever>
does that still need irq's on many gpu's?
<danvet>
clever, that's pretty much the idea, see the rfc from noralf that the patch links
<danvet>
or at least somewhere in that discussion
<danvet>
also it wouldn't be fbcon, it could also be a yuv overlay from your gfx compositor
<danvet>
so imo the only reliable emergency gpu output thing would be to have that hook to check whether emergency output is possible without anything having to change
<clever>
at least for the rpi hw, you just give it a list of images (xy, wh, pixel format(rgb or yuv), alpha), and the hw will composite all of that on the fly
<clever>
so adding any overlay, requires making a new list containing that overlay
<danvet>
(including trylocks and all that to make sure we're not trampling over a concurrent modeset, which can easily hang the box)
<clever>
at which point, its simpler to just omit the other layers, and render only the error msg
<danvet>
yeah if you're extremely sure, you could also change the plane setup in that emergency output hook
<danvet>
but that would be hw specific
<clever>
and the hw supports rgb/yuv seamlessly, even down to 8bpp rgb
<danvet>
on many hw trying to do anything like this is very risky
<danvet>
so best we can do is trylock to make sure we're not racing
<danvet>
and then print into the biggest plane that's currently visible
<clever>
for the rpi, you have a large (16kb) block of ram, that contains multiple descriptions of a single frame (all planes in that frame)
<danvet>
and hoping that plane is accessible to the cpu right now
<clever>
and a pageflip is just changing 1 register, to say which frame description to render
<clever>
tearing is just changing that 1 master register outside of vsync
<danvet>
yeah on some hw you can do it easily
<danvet>
assuming that holds for all hw is where current fbcon emergency printing fails epically
<clever>
if you dont care about tearing, you can ignore the vsync irq
<clever>
so that only leaves 1 minor issue
<clever>
if you corrupt the actively used frame description, the hw can deadlock, and need a reset
<danvet>
clever, the other problem is the memory/cpu mapping
<clever>
so you need to know what part of that 16kb of ram is unused
<danvet>
clever, yeah this only works if you preallocate the descriptor
<clever>
reserving space for 1 plane (that only costs 32 bytes) would allow you to ignore any locks on the allocator
<danvet>
and also you need to preallocate the memory and the cpu mapping
<danvet>
none of that is stuff you can set up from panic context
<clever>
yeah
<libv>
i remember this was the main selling point back in 2008?
<libv>
the second one being flicker free booting.
<clever>
for a higher cost (60 bytes), you can do hardware scaling of the plane
<clever>
so the pre-allocated image could be a lower resolution
<clever>
libv: there are some flicker issues in the rpi bootup still, i think most distro's hide that by just not initializing the hdmi until the kernel modules are loaded, which kinda sucks
<daniels>
clever: for better or worse, no other hardware really looks at all like the VideoCore
<clever>
what if the DRM driver had a panic capability flag?
<clever>
so it can advertise that it can swap planes in a sync manner?
<clever>
and then some reusable code can do that for all DRM drivers that allow it
<danvet>
clever, see the linked patches and disucssions
<clever>
maybe a dedicated callback to just display a single image and just not deal with locks
<danvet>
that's pretty much exactly the plan, except it hasn't landed yet
<bbrezillon>
we need to be super careful when adding new vk_common wrappers implementing Cmd hooks and patch all users of the generic cmd-dispatch logic to implement the 2nd version of the entrypoint, otherwise we'll get NULL derefs
<bbrezillon>
that's because device->dispatch_table.CmdXxx are all NULLs when we use the generic cmd-dispatch logic, and those NULL-entrypoints are automatically overloaded by the vk_common_CmdXxx implementation at device init time if there's such a wrapper
lemonzest has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
mlankhorst has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
fxkamd has joined #dri-devel
jewins has joined #dri-devel
<tomeu>
shadeslayer: unfortunately only for master atm, but we have wanted to do that for some time already
heat has joined #dri-devel
<shadeslayer>
Ah :(
<jekstrand>
bbrezillon: Hrm...
<karolherbst>
hudasuhdasudh jekstrand: I saw your thread on twitter and got reminded of our Arc problem :D don't know if you saw my comment here on IRC in regards to that
<karolherbst>
btw implementing the compiler stuff is super annoying
<karolherbst>
even with clc
<jekstrand>
karolherbst: I saw something. Also, I came up with a new idea over the week-end.
<karolherbst>
cool
<jekstrand>
karolherbst: :(
<karolherbst>
well... at least I support most of the API by now... but I had to wire up support for compiler args which is annoying... rust string handling especially with ffi in mind is really realy annoying
kem has quit [Ping timeout: 480 seconds]
<karolherbst>
but... I am currently implementing linking
<karolherbst>
but then I am not sure how to move forward from that... I think I want to create the nir early but...
<karolherbst>
clCreateKernel at the latest
<karolherbst>
jekstrand: but anyway, what's your idea?
Company has joined #dri-devel
<jekstrand>
karolherbst: I think I need to type it out rather than describe via IRC
<karolherbst>
ahh
mattrope has joined #dri-devel
<karolherbst>
the CL API is so annoying sometimes :/
kem has joined #dri-devel
sdutt has joined #dri-devel
mbrost has joined #dri-devel
<daniels>
karolherbst: ... sometimes?
<karolherbst>
daniels: it's all bad, but somtimes annoying as well. better? :P
<jekstrand>
bbrezillon: Yeah, we currently stuff in the trampolines only as part of vkGetInstanceProcAddr and so it's the very last thing in the chain.
<jekstrand>
Also, it never happens for device things.
<bbrezillon>
jekstrand: even with a patched vk_device_get_proc_addr(), the vk_common_ overload is still problematic
<bbrezillon>
jekstrand: one option would be to add vk_device_init_with_cmd_dispatch() variant that takes the primary dispatch table and only set the wrappers if the function is not implemented there, but that looks pretty close to what I was doing in vk_device_dispatch_table_from_cmd_tables(), so I'm not sure you'll like it :)
Akari has joined #dri-devel
Akari- has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
<jekstrand>
bbrezillon: Yeah... Let me give it a think.
<jekstrand>
bbrezillon: I'd not thought through all these interactions when I said "just use the same thing!"
Akari` has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
dwlsalmeida has left #dri-devel [#dri-devel]
dwlsalmeida has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
maxzor has joined #dri-devel
adjtm has quit [Quit: Leaving]
<dj-death>
I forgot what's the function removing unused SSA values in a shader...
<dj-death>
anybody remembers?
<pendingchaos>
nir_index_ssa_defs? nir_opt_dce?
<dj-death>
pendingchaos: thanks!
<dj-death>
was looking for the index one I think
<jekstrand>
dce is removing unused stuff
fxkamd has quit []
lemonzest has joined #dri-devel
iive has joined #dri-devel
pnowack has quit [Quit: pnowack]
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
frieder_ has quit [Remote host closed the connection]
pnowack has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
Duke`` has joined #dri-devel
nchery has joined #dri-devel
f11f12 has quit [Quit: Leaving]
<anholt>
dschuermann: I'd love it if we could land the parts of your opt_shrink_vectors other than the per-component DCE
<anholt>
Yeah. A few people looked at it, but I didn't get "please change this and then r-b" so I don't know what to do with it
aravind has joined #dri-devel
<dschuermann>
ok, I'll have a look tomorrow. I think it's a really nice addition
rgallaispou has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
kts has quit []
kts has joined #dri-devel
lkw has quit [Quit: leaving]
mbrost_ has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<zmike>
karolherbst: any chance I could request that you have the gallium state updates happen in the st_atom_list.h order?
<karolherbst>
zmike: huh? what do you mean?
<zmike>
like when you send the state updates to the driver
<zmike>
making them always happen in that order would be nice
<zmike>
if it's not a hassle
<karolherbst>
ohh you mean inside clover?
<zmike>
yeah
<karolherbst>
ahh
<zmike>
nbd either way, just thought I'd ask
<karolherbst>
clover doesn't really do much of state updates anyway, so I don't think it should be a problem, but the state updates stuff is a complete mess in clover anyway
<karolherbst>
zmike: what's the benefit btw?
<zmike>
at some point in the future I would like to have that standardized in all frontends so drivers can optimize for dispatching in sequence
<karolherbst>
ahh
<zmike>
distant future
idr has joined #dri-devel
sneil has quit [Quit: Leaving]
sneil has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
devilhorns has quit []
mszyprow has quit [Ping timeout: 480 seconds]
sadlerap1 has quit []
sadlerap has joined #dri-devel
LexSfX has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
kts has quit []
angerctl has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Namarrgon has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
gouchi has joined #dri-devel
<jekstrand>
bbrezillon: Ok, let me see if I can reason through all this dispatch nonsense.
* jekstrand
pulls the branch
Duke`` has joined #dri-devel
maxzor has joined #dri-devel
ngcortes has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
lynxeye has quit []
kts has quit [Ping timeout: 480 seconds]
ramaling_ has joined #dri-devel
ngcortes has quit [Quit: Leaving]
ngcortes has joined #dri-devel
eukara has joined #dri-devel
ramaling has quit [Ping timeout: 480 seconds]
Namarrgon has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
shankaru has quit [Quit: Leaving.]
cmarcelo has quit [Quit: Reconnecting]
cmarcelo has joined #dri-devel
pnowack has quit [Quit: pnowack]
cmarcelo has quit []
cmarcelo has joined #dri-devel
pnowack has joined #dri-devel
cmarcelo has quit []
pnowack has quit [Remote host closed the connection]
cmarcelo has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
pnowack has joined #dri-devel
f11f12 has joined #dri-devel
mbrost has joined #dri-devel
angerctl has joined #dri-devel
cphealy has quit [Remote host closed the connection]
cphealy has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
cphealy has quit []
cphealy has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
ngcortes has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
nchery has joined #dri-devel
nsneck has quit [Quit: bye]
nsneck has joined #dri-devel
f11f12 has quit [Quit: Leaving]
Haaninjo has quit [Quit: Ex-Chat]
gouchi has quit [Remote host closed the connection]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
mbrost has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
danvet has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
samueldr has quit [Server closed connection]
samueldr has joined #dri-devel
mhenning has joined #dri-devel
Ryback_ has quit [Server closed connection]
Ryback_ has joined #dri-devel
cworth has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
cworth has joined #dri-devel
mattrope has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]