JohnnyonFlame has quit [Read error: Connection reset by peer]
<airlied>
zzoon[m]: yup thanks for reminder! just crawling out of 3 weeks backlog, but will put near the front of the list :-)
dviola has quit []
<airlied>
zzoon[m]: great work, so the intel devices also have the huc firmware, and I think there is some support for having the firmware do the slice decoding
<airlied>
I do wonder if we should try and add slice decode support to vulkan to avoid having to parse slice headers in the driver
<zzoon[m]>
Yeah that's what I tried to find but hcp is by defualt and I couldn't manage to see that it works by huc.
<zzoon[m]>
airlied: I mean, media-driver and vaapi-driver works with HCP by default and I tried to modify it to use huc but failed.
<zzoon[m]>
for hevc decoding.
<airlied>
zzoon[m]: do you know if you ever got huc to work at all? it at least needs a kernel parameter I think on gen9
<zzoon[m]>
Ah..didn't know about the kernel parameter..
<airlied>
I'm fine with using hevc and just doing the slice header, it would be nice to have the vulkan api support slices though
<zzoon[m]>
that's good to know...I should've noticed about that.. slice parsing was a pain.
<airlied>
I wrote h264 slice parsing before, it wasn't fun, then I discovered the short header path
JohnnyonFlame has joined #dri-devel
yuq825 has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
aravind has joined #dri-devel
Kayden has joined #dri-devel
sauce has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
cheako has joined #dri-devel
dcz_ has joined #dri-devel
illwieckz has joined #dri-devel
Danct12 has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
dcz has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
itoral has joined #dri-devel
bmodem has joined #dri-devel
danvet has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
mvlad has joined #dri-devel
frieder has joined #dri-devel
fab has quit [Quit: fab]
Duke`` has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
tzimmermann has joined #dri-devel
jkrzyszt has joined #dri-devel
pochu has quit [Quit: leaving]
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
fab has joined #dri-devel
<MrCooper>
karolherbst: nice
tursulin has joined #dri-devel
rasterman has joined #dri-devel
thellstrom has joined #dri-devel
garrison has quit []
i-garrison has joined #dri-devel
aravind has joined #dri-devel
pcercuei has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
lynxeye has joined #dri-devel
pochu has joined #dri-devel
dtmrzgl has quit []
apinheiro has joined #dri-devel
dtmrzgl has joined #dri-devel
kj has joined #dri-devel
sgruszka has joined #dri-devel
xypron has quit [Quit: xypron]
xypron has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
godvino has joined #dri-devel
devilhorns has joined #dri-devel
sgruszka has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
jaganteki has joined #dri-devel
sgruszka has joined #dri-devel
sgruszka_ has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: reboot]
jaganteki has quit [Remote host closed the connection]
<Lynne>
what are pipeline image barriers considered in vulkan? compute ops? graphic ops?
<Lynne>
I ask, because assuming that you set up a simple command buffer with an image barrier and a compute dispatch, does a VkSemaphoreSubmitInfo with a compute + compute wait/signal stages also wrap the image barrier?
<pixelcluster>
it would cover the image barrier even without the submit because of submission order
<Lynne>
isn't the whole point of VkSemaphoreSubmitInfo that it allows you to wait on semaphores during the stage you need to wait on them, rather than before execution can begin?
<pixelcluster>
well that functionality was already in the 1.0 VkSubmitInfo with pWaitDstStageMask
<pixelcluster>
but that is a bit besides the point of barriers
<pixelcluster>
if you only need to synchronize within a queue, you only need barriers and no semaphores, even across different submits to that queue
<ishitatsuyuki>
right
<ishitatsuyuki>
the granular sync stuff is more like events
<ishitatsuyuki>
semaphores are for cross-queue sync
_xav_ has quit [Ping timeout: 480 seconds]
<Lynne>
semaphores are part of the library API, so I can't change them
<Lynne>
users can use the images in whatever queue they want, and I have to be able to deal with it
<Lynne>
so is a pipeline barrier included with compute+compute, or do I have to use all_commands_bit in the wait VkSemaphoreSubmitInfo and compute in the signal VkSemaphoreSubmitInfo?
_xav_ has joined #dri-devel
<pixelcluster>
semaphore signal with compute and semaphore wait with compute should work similar to a compute-compute pipeline barrier (except cross-queue and stuff) afaik
<pixelcluster>
(except cross queue = except it also works cross-queue)
<Lynne>
right, that makes sense, but still doesn't answer my question in case it is cross-queue - could the pipeline barrier get executed before the previous submission on a queue finishes
godvino has quit [Read error: Connection reset by peer]
godvino has joined #dri-devel
<pixelcluster>
I would say that depends on the dst stages of the barrier (or the commands after it), i.e. if the pipeline barrier's dst stage has compute in it, the barrier would be guaranteed to finish before the semaphore is signaled
<pixelcluster>
actually the "additionally include all commands that occur earlier in submission order" is kinda weird, but I think if you put compute in the dstStageMask you're safe either way
<pixelcluster>
it is weird because you could read it as if the "all commands that occur earlier in submission order" really means all commands, not just limited by the stageMask, but that doesn't make sense because then the stageMask would be meaningless so I don't think that is actually meant here
<pixelcluster>
hmm I guess it makes sense if you read it as "all commands that occur earlier [than the submitted batch] in submission order"
sgruszka_ has quit [Ping timeout: 480 seconds]
<Lynne>
yeah, that sounds a bit in the gray area of the spec, so I'll pick all_commands for the wait stage, thanks
Guest11440 has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
godvino has quit [Quit: WeeChat 3.6]
djbw has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
wooosaiii has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Danct12 has quit [Quit: WeeChat 3.8]
lynxeye has joined #dri-devel
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
thellstrom has quit [Quit: thellstrom]
fxkamd has joined #dri-devel
JohnnyonFlame has joined #dri-devel
dsrt^ has quit [Remote host closed the connection]
<jfalempe>
tzimmermann, I have working poc to use DMA to copy the framebuffer to VRAM for mgag200. it's not measurably faster, but it will free up some CPU.
<jfalempe>
I'm currently using a small 32k buffer with dma_map_single() for DMA transfert, but it would be better to use directly the drm_shadow_plane_state->data for DMA.
<jfalempe>
But I don't find how to do that without copying the data to a dma-capable buffer.
<tzimmermann>
jfalempe, gem shmem is not made for this, i think
<tzimmermann>
TBH i'd prefer to avoid such optimizations
<tzimmermann>
it's a lot of complexity for little gain
<tzimmermann>
i know that it's the fun stuff to work on. but in terms of maintainence it's pure overhead
<jfalempe>
it's not that complex, but I was a bit disappointed it's not faster ;)
<tzimmermann>
i can see two things that might benefit mgag200: irqs and cursors
<jfalempe>
irq is next on the list, but you need to use DMA to have the softrap irq.
<tzimmermann>
i once made a pathcset for irq-driven pageflips. it's somewhere on dri-devel. pick it up, if you want to.
<jfalempe>
ah, thanks, I will look into this.
<tzimmermann>
there's no vblank irq, but the patchset used the vsync instead. other drivers do that as well
<tzimmermann>
the other thing is the HW cursor: matrox only supports 16-color cursors. but that might be enough for most compositors. the key here is compositor support, which is missing
<jfalempe>
you can use bitblit to have 32bit cursor
<jfalempe>
it is supposed to handle transparency, but I tested only with opaque color.
<tzimmermann>
that's better done in userspace. the driver shouldn't do compositing.
<tzimmermann>
but with the 16-color hardware plane, it would make a difference
<tzimmermann>
IDK if that is really practical to support in userspace
fxkamd has quit []
fxkamd has joined #dri-devel
<jfalempe>
I mean bitblt is a g200 drawing instruction, so it can be used to draw the cursor, the drawback is you have to save what is under the cursor to restore it after it moves.
<tzimmermann>
jfalempe, exactly. that's better left to userspace.
<tzimmermann>
rule-of-thumb for DRM is: if you can't do it in hardware, you do it in userspace
<tzimmermann>
and rumor has it, that bitblit isn't that much better, compared to optimized userspace with advanded CPU instructions (SSE, etc)
<tzimmermann>
i never measured this, though
<jfalempe>
but bitblit avoid copying data from cpu to vram, which is the slowest thing.
<jfalempe>
if your cursor image is in VRAM it's much faster than copying the damaged region.
<tzimmermann>
i can't really argue against that, but i tend to believe daniel's comments on 2d acceleration: https://blog.ffwll.ch/2018/08/no-2d-in-drm.html and using blitting adds asynchronous operations, which requires additonal complexity; plus you'd have to track updates in the driver
<tzimmermann>
it's not worth the effort. that's what i meant with 'it's a maintenance overhead'
<tzimmermann>
for other cool HW hacking: mga hardware support zooming. IDK if that's possible, but it might be useable by userspace. Gnome has accessibility features that zoom the display
kzd has joined #dri-devel
Haaninjo has joined #dri-devel
<tzimmermann>
and IIRC mga HW supports overlay planes for video output
fab has quit [Quit: fab]
yuq825 has left #dri-devel [#dri-devel]
<jfalempe>
yes, but I'm not sure what we can do with that.
<tzimmermann>
there's also irq support on ast HW, but it's not well documented. maybe that's interesting
sarahwalker has joined #dri-devel
bmodem has joined #dri-devel
fxkamd has quit []
Leopold_ has quit []
Leopold_ has joined #dri-devel
mbrost has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
dcz has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
devilhorns has quit []
Thymo_ has quit [Ping timeout: 480 seconds]
kxkamil has joined #dri-devel
dcz has joined #dri-devel
stuarts has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
Zopolis4_ has quit []
tzimmermann has quit [Quit: Leaving]
fab has joined #dri-devel
Thymo has joined #dri-devel
Kayden has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
gawin has joined #dri-devel
dcz has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
<jenatali>
gfxstrand: For that WSI caching change, it seems like the right thing to do is to add a wsi_instance object to contain per-winsys caches. Do you agree?
stuarts has quit [Remote host closed the connection]
smiles_1111 has joined #dri-devel
smilessh has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
smiles_1111 has quit [Ping timeout: 480 seconds]
<gfxstrand>
jenatali: Ugh... yeah, probably.
<gfxstrand>
jenatali: Or we could just make it global call_once
<gfxstrand>
But that's been so fraught
<jenatali>
If I could add an array of winsys instances to the vk_instance that are on-demand initialized, that wouldn't be too bad
<jenatali>
But cleanup still means touching every driver, so nevermind
<jenatali>
Guess I'll start adding it
cmarcelo has quit [Quit: leaving]
cmarcelo has joined #dri-devel
heat has joined #dri-devel
dcz has joined #dri-devel
Cyrinux9 has quit []
Cyrinux9 has joined #dri-devel
Leopold___ has joined #dri-devel
gio has quit [Quit: WeeChat 3.7.1]
Leopold_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
gio has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
<jenatali>
gfxstrand: It looks like vulkan/wsi wasn't supposed to take a dependency on vulkan/runtime, based in the fact that everything is Vk* types instead of vk_* types. However that abstraction seems to have leaked. Is it worth trying to maintain/restore it or should I abandon it?
kxkamil has quit []
bmodem has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
mbrost has joined #dri-devel
heat has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
Venemo has quit [Remote host closed the connection]
glehmann has quit [Remote host closed the connection]
glehmann has joined #dri-devel
Venemo has joined #dri-devel
mvlad has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
mbrost has joined #dri-devel
bgs has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
kzd has quit [Quit: kzd]
JohnnyonF has joined #dri-devel
fab has quit [Quit: fab]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
dcz has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
heat has joined #dri-devel
stuarts has joined #dri-devel
iive has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
RSpliet has quit [Quit: Bye bye man, bye bye]
pcercuei has quit [Quit: dodo]
digetx is now known as Guest11493
digetx has joined #dri-devel
kzd has joined #dri-devel
RSpliet has joined #dri-devel
Guest11493 has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Read error: Connection reset by peer]