ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
paulk-bis has joined #dri-devel
paulk has quit [Read error: Connection reset by peer]
penguin42 has quit [Remote host closed the connection]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<robclark>
alyssa: I think I have some a2xx device *somewhere* but probably not something that can run upstream kernel.. or get working in any reasonable amount of time even if I had a reasonable amount of time.. lumag has some imx5 things with a2xx working.. and possible flto does as well.. I suppose I can look at things and suggest things but wouldn't be too easy for hands on debugging
<lumag>
robclark, alyssa: yep, I have a200 running on imx53, but I'm just diving into mesa part of it.
flto has quit [Ping timeout: 480 seconds]
<gfxstrand>
Does anyone know: Do the pixmark tests use ARB programs?
<gfxstrand>
Never mind. I can't be bothered. I'll just put a CI patch on top of the MR.
Company has joined #dri-devel
<lumag>
robclark, alyssa So, I can test the patchset, but it will probably take a long time for me to write it.
<lumag>
(I likely won't have time for that til next Weekend).
benjaminl has quit [Ping timeout: 480 seconds]
<alyssa>
karolherbst: by "direct translate", I mean writing the simple patch to translate load_reg and store_reg intrinsics to moves
<alyssa>
which for codegen should be just as good as what you do now
<alyssa>
robclark: alright
<alyssa>
I guess I can do write the a2xx patches with my eyes closed and my hands behind my back
<alyssa>
and lumag can test and you can review and probably be good enough
<lumag>
good
bbrezill1 has joined #dri-devel
flto has joined #dri-devel
idr has quit [Quit: Leaving]
<robclark>
alyssa: let's try that.. I'll try to help you with eyeballs (and hopefully flto can do since he did a2xx nir conversion) and lumag can help with testing (at least until we can get some a2xx CI.. hopefully)
bbrezillon has quit [Ping timeout: 480 seconds]
<alyssa>
:+1:
Rayyan is now known as Guest5721
Rayyan has joined #dri-devel
vyivel has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
jani_ has joined #dri-devel
skinkie_ has joined #dri-devel
debian has joined #dri-devel
jani has quit [Read error: Connection reset by peer]
debian is now known as Guest5727
skinkie has quit [Ping timeout: 480 seconds]
Guest5721 has quit [Ping timeout: 480 seconds]
pepp has quit [Ping timeout: 480 seconds]
Prf_Jakob has quit [Ping timeout: 480 seconds]
Prf_Jakob has joined #dri-devel
marex has quit [Remote host closed the connection]
marex has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
<Company>
is there a way to poll() a GLsync or vkFence?
<airlied>
you can export a vk fence to an fd, VK_KHR_external_fence_fd not sure how it works with poll
<Company>
interesting
benjaminl has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
sghuge has quit [synthon.oftc.net weber.oftc.net]
sdutt has quit [synthon.oftc.net weber.oftc.net]
Dr_Who has quit [synthon.oftc.net weber.oftc.net]
alanc has quit [synthon.oftc.net weber.oftc.net]
Mangix has quit [synthon.oftc.net weber.oftc.net]
nchery has quit [synthon.oftc.net weber.oftc.net]
alyssa has quit [synthon.oftc.net weber.oftc.net]
Peuc has quit [synthon.oftc.net weber.oftc.net]
cphealy has quit [synthon.oftc.net weber.oftc.net]
gildekel has quit [synthon.oftc.net weber.oftc.net]
Kayden has quit [synthon.oftc.net weber.oftc.net]
jhli has quit [synthon.oftc.net weber.oftc.net]
quantum5 has quit [synthon.oftc.net weber.oftc.net]
lstrano has quit [synthon.oftc.net weber.oftc.net]
greaser|q has quit [synthon.oftc.net weber.oftc.net]
bcheng has quit [synthon.oftc.net weber.oftc.net]
andrey-konovalov has quit [synthon.oftc.net weber.oftc.net]
anujp has quit [synthon.oftc.net weber.oftc.net]
swivel has quit [synthon.oftc.net weber.oftc.net]
sauce has quit [synthon.oftc.net weber.oftc.net]
jessica_24 has quit [synthon.oftc.net weber.oftc.net]
rohiiyer02 has quit [synthon.oftc.net weber.oftc.net]
hays has quit [synthon.oftc.net weber.oftc.net]
Ryback_ has quit [synthon.oftc.net weber.oftc.net]
aknautiy has quit [synthon.oftc.net weber.oftc.net]
SolarAquarion has quit [synthon.oftc.net weber.oftc.net]
cheako has quit [synthon.oftc.net weber.oftc.net]
kisak has quit [synthon.oftc.net weber.oftc.net]
vicky has quit [synthon.oftc.net weber.oftc.net]
rossy has quit [synthon.oftc.net weber.oftc.net]
jimjams has quit [synthon.oftc.net weber.oftc.net]
ccaione has quit [synthon.oftc.net weber.oftc.net]
rib has quit [synthon.oftc.net weber.oftc.net]
lileo has quit [synthon.oftc.net weber.oftc.net]
benettig has quit [synthon.oftc.net weber.oftc.net]
ddavenport_ has quit [synthon.oftc.net weber.oftc.net]
haasn has quit [synthon.oftc.net weber.oftc.net]
norris has quit [synthon.oftc.net weber.oftc.net]
tfiga has quit [synthon.oftc.net weber.oftc.net]
angular_mike______ has quit [synthon.oftc.net weber.oftc.net]
jhugo has quit [synthon.oftc.net weber.oftc.net]
kerneltoast has quit [synthon.oftc.net weber.oftc.net]
CosmicPenguin has quit [synthon.oftc.net weber.oftc.net]
olv has quit [synthon.oftc.net weber.oftc.net]
linusw has quit [synthon.oftc.net weber.oftc.net]
khilman has quit [synthon.oftc.net weber.oftc.net]
_alice has quit [synthon.oftc.net weber.oftc.net]
mdnavare has quit [synthon.oftc.net weber.oftc.net]
robher has quit [synthon.oftc.net weber.oftc.net]
hashar has quit [synthon.oftc.net weber.oftc.net]
ogabbay has quit [synthon.oftc.net weber.oftc.net]
linyaa has quit [synthon.oftc.net weber.oftc.net]
rcn-ee___ has quit [synthon.oftc.net weber.oftc.net]
jstultz has quit [synthon.oftc.net weber.oftc.net]
zx2c4 has quit [synthon.oftc.net weber.oftc.net]
rg3igalia has quit [synthon.oftc.net weber.oftc.net]
mslusarz has quit [synthon.oftc.net weber.oftc.net]
markco has quit [synthon.oftc.net weber.oftc.net]
appusony____ has quit [synthon.oftc.net weber.oftc.net]
hwentlan_ has quit [synthon.oftc.net weber.oftc.net]
seanpaul_ has quit [synthon.oftc.net weber.oftc.net]
lvrp16 has quit [synthon.oftc.net weber.oftc.net]
TimurTabi has quit [synthon.oftc.net weber.oftc.net]
graphitemaster has quit [synthon.oftc.net weber.oftc.net]
SanchayanMaity has quit [synthon.oftc.net weber.oftc.net]
steev has quit [synthon.oftc.net weber.oftc.net]
arnd has quit [synthon.oftc.net weber.oftc.net]
NishanthMenon has quit [synthon.oftc.net weber.oftc.net]
kathleen_ has quit [synthon.oftc.net weber.oftc.net]
austriancoder has quit [synthon.oftc.net weber.oftc.net]
daniels has quit [synthon.oftc.net weber.oftc.net]
dianders has quit [synthon.oftc.net weber.oftc.net]
glisse has quit [synthon.oftc.net weber.oftc.net]
cwabbott has quit [synthon.oftc.net weber.oftc.net]
dschuermann has quit [synthon.oftc.net weber.oftc.net]
tchar has quit [synthon.oftc.net weber.oftc.net]
eric_engestrom has quit [synthon.oftc.net weber.oftc.net]
vgpu-arthur has quit [synthon.oftc.net weber.oftc.net]
narmstrong has quit [synthon.oftc.net weber.oftc.net]
rcombs has quit [synthon.oftc.net weber.oftc.net]
Frogging101 has quit [synthon.oftc.net weber.oftc.net]
rodrigovivi has quit [synthon.oftc.net weber.oftc.net]
aravind has quit [Ping timeout: 480 seconds]
smiles_ has quit [Remote host closed the connection]
smiles_ has joined #dri-devel
sghuge has joined #dri-devel
sdutt has joined #dri-devel
alanc has joined #dri-devel
Dr_Who has joined #dri-devel
Mangix has joined #dri-devel
nchery has joined #dri-devel
alyssa has joined #dri-devel
Peuc has joined #dri-devel
NishanthMenon has joined #dri-devel
cphealy has joined #dri-devel
gildekel has joined #dri-devel
Kayden has joined #dri-devel
jhli has joined #dri-devel
quantum5 has joined #dri-devel
vicky has joined #dri-devel
Ryback_ has joined #dri-devel
lstrano has joined #dri-devel
lvrp16 has joined #dri-devel
greaser|q has joined #dri-devel
khilman has joined #dri-devel
bcheng has joined #dri-devel
andrey-konovalov has joined #dri-devel
anujp has joined #dri-devel
swivel has joined #dri-devel
sauce has joined #dri-devel
jessica_24 has joined #dri-devel
rohiiyer02 has joined #dri-devel
aknautiy has joined #dri-devel
hays has joined #dri-devel
SolarAquarion has joined #dri-devel
cheako has joined #dri-devel
kisak has joined #dri-devel
haasn has joined #dri-devel
rcombs has joined #dri-devel
norris has joined #dri-devel
narmstrong has joined #dri-devel
markco has joined #dri-devel
dschuermann has joined #dri-devel
tchar has joined #dri-devel
SanchayanMaity has joined #dri-devel
linusw has joined #dri-devel
cwabbott has joined #dri-devel
hwentlan_ has joined #dri-devel
mslusarz has joined #dri-devel
glisse has joined #dri-devel
mdnavare has joined #dri-devel
linyaa has joined #dri-devel
appusony____ has joined #dri-devel
TimurTabi has joined #dri-devel
Frogging101 has joined #dri-devel
graphitemaster has joined #dri-devel
arnd has joined #dri-devel
angular_mike______ has joined #dri-devel
ogabbay has joined #dri-devel
lileo has joined #dri-devel
olv has joined #dri-devel
hashar has joined #dri-devel
kerneltoast has joined #dri-devel
rcn-ee___ has joined #dri-devel
dianders has joined #dri-devel
tfiga has joined #dri-devel
rib has joined #dri-devel
daniels has joined #dri-devel
vgpu-arthur has joined #dri-devel
jstultz has joined #dri-devel
austriancoder has joined #dri-devel
_alice has joined #dri-devel
jhugo has joined #dri-devel
rodrigovivi has joined #dri-devel
ccaione has joined #dri-devel
robher has joined #dri-devel
zx2c4 has joined #dri-devel
jimjams has joined #dri-devel
benettig has joined #dri-devel
ddavenport_ has joined #dri-devel
eric_engestrom has joined #dri-devel
rg3igalia has joined #dri-devel
kathleen_ has joined #dri-devel
steev has joined #dri-devel
seanpaul_ has joined #dri-devel
CosmicPenguin has joined #dri-devel
rossy has joined #dri-devel
krushia has quit [Ping timeout: 480 seconds]
flto has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<Company>
so, for anyone following my "I wonder why my shiny new GTK vulkan renderer is so much slower than the GL renderer" adventure from a few days ago, I have 2 updates:
<Company>
1. it turns out on my discrete AMD, the results are quite different and it's holding up pretty well
<Company>
It's also doing 2000fps (vs 2800 for GL) instead of the 200fps (vs 650) on my Intel
<Company>
It's also using 100% CPU instead of 50%, because the AMD is so freaking fast that I'm actually CPU bound (and so is the GL renderer)
<Company>
while on Intel I am GPU bound
<airlied>
Company: do you thread anything btw
<airlied>
?
<Company>
the GL renderer is not, and is slower than the Vulkan renderer if I turn off gallium's threads
<Company>
airlied: no
<airlied>
so threading vulkan is probably one way to get towards GL
<airlied>
esp if you are CPU bound
<Company>
there's a bunch of limitations inside GTK I need to fix first
<Company>
mostly related to interaction with Wayland/X11
<Company>
(and I feel I need to understand Vulkan/GL better to know how to do threading properly)
<Company>
aaanyway, I just had a 2nd breakthrough
<Company>
I replaced the solid color drawing that we do in lots of blaces with a vkCmdClearAttachments()
<Company>
and my Vulkan fps went from 220 to 360
<Company>
so yeah, turns out that matters
<Company>
when we're in fact GPU bound
<Company>
I suspect if I get that optimized into into the clear color for the BeginRenderPass, there's a bunch more fps in there
smiles_ has quit [Ping timeout: 480 seconds]
<Company>
if I comment out the vkCmdClearAttachments, I get 530fps
<airlied>
oh yeah using a render pass clear would probably help
Duke`` has joined #dri-devel
<Company>
I just wasn't aware I can double my fps that way
<Company>
so we seem to not be bound by shader complexity, but the amount of pixels we write
<Company>
actually no
<Company>
the amount of pixels is the same
<Company>
so why is ClearAttachments() faster than Draw() if the shader complexity doesn't matter
<Company>
is that using the blit engine instead of the shader engine or something?
<Company>
because now I wonder if - especially for larger embedded videos - replacing texture draws with vkCmdBlitImage is worth the effort
<airlied>
it all depends on the drivers
<airlied>
but if you are doing a blit, using blit image should get the optimal path
<Company>
yeah, guess I can only figure it out by trying
<Company>
the problem is that those blits happen halfway through the renderpass and there's no vkCmdBlitAttachments()
<airlied>
on radv you should hit fast clear paths on both clear image and subpass
<airlied>
but i'm a bit rusty on the details
<Company>
radv is not my primary concern, because that's usually a fast discrete GPU
<Company>
my concern is internal gpus (read: Intel) and ultimately mobile
<Sachiel>
intel will fast clear too, if the conditions are met
<airlied>
mobile you definitely want render passes
<Company>
the thing I'd ultimately want is (a) me being more of an expert on GPUs and (b) RPi and Librem users being happy, because those are the ones that use GTK
<Company>
and I'd like them to not stay on GTK3 and having to use Cairo
oneforall2 has quit [Remote host closed the connection]
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
oneforall2 has joined #dri-devel
sima has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
junaid has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<Company>
I think medium-term the best thing I can do is split the render region by opaque subregions and render each individually
junaid has quit [Remote host closed the connection]
<Company>
ie split the shadow from the window contents, because then the window contents are opaque and solid, so I can use the clear color there
<Company>
and then again do the same with the content area and the headerbar
<Company>
so that the content area doesn't do the clear with the window color, but with the content area's color
<Company>
alternatively, if that works, I could split into tiles that much the tiling of the GPU and go from there
<Company>
but no clue how tiling GPUs work
<Company>
but I read somewhere that webrender does that
YuGiOhJCJ has joined #dri-devel
fxkamd has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
tzimmermann has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
<MrCooper>
Company: maybe GTK should use Wayland sub-surfaces for drop shadows? E.g. can't really use 10 bpc surface formats otherwise
<Company>
ugh
<MrCooper>
:)
<Company>
that has multiple issues, starting with the complexity of doing it, ending with how to do it for rounded corners
<Company>
input handling etc
rgallaispou has joined #dri-devel
<Company>
it's much easier to just do multiple renderpasses
<Company>
until I emit command buffers that are too big so that that starts impacting performance
<Company>
I don't think I've encountered that yet
pcercuei has joined #dri-devel
<Company>
batching individual vkCmdDraw() calls into multi-instance calls didn't make a difference at least
<emersion>
render passes won't help with the fact that 10bpc formats don't have a proper alpha channel
<Company>
that's true
<emersion>
so, drop shadows can't be painted on a 10bpc buffer, no matter what
<Company>
though I don't think GTK wants to use 10bpc formats anyway
<emersion>
no color management?
<Company>
the goal is float16 for that
<emersion>
right
<emersion>
that'd make things easier, although consume more memory and bandwidth
<Company>
I don't think that will matter much
<emersion>
i haven't really tested how bad is fp16 compared to 10bpc
<Company>
because we need the float16 internally anyway for compositing
<Company>
well, no idea actually, I didn't try either
<Company>
but current GTK already switches to float16
<Company>
and nobody has complained yet
<Company>
if you load a 16bit png
<Company>
well, nobody is not quite true
<Company>
there was an AMD bug and when people scrolled their app list in gnome settings suddenly their screen got corrupted
<Company>
because one or two appsaccidentally had 16bit icons
<Company>
and GTK hapily switched to make those beautiful
fab has joined #dri-devel
<MrCooper>
beautifully downsampled to 8 bpc in the end :)
jkrzyszt has joined #dri-devel
<Company>
it was good to know that compositors (or at least mutter) handled it fine
<linkmauve>
Hi, I build Mesa with -Dglx=disabled, which produces no libGL.so, but the symbols are still available when loaded through EGL, is there a way to completely disable GL support to leave only GLESv2?
fab has quit [Ping timeout: 480 seconds]
<HdkR>
linkmauve: -Dopengl=false in meson?
rasterman has joined #dri-devel
frieder has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
epony has joined #dri-devel
<pq>
sima, dottedmag, I would expect DIRTY_FB to be very useful with USB (literally USB and not USB-C DP mode) and paravirtualized display drivers.
leo60228- has quit []
<emersion>
pq, are you thinking of FB_DAMAGE_CLIPS maybe?
leo60228 has joined #dri-devel
<pq>
emersion, maybe I am, I need to check what DIRTYFB was then
<pq>
is DIRTYFB not the legacy UAPI version of FB_DAMAGE_CLIPS?
<emersion>
drm_atomic_helper_dirtyfb() seems to implement DIRTYFB via FB_DAMAGE_CLIPS
<javierm>
pq: yes, DRM_IOCTL_MODE_DIRTYFB is the legacy one
<emersion>
however, i don't think (?) atomic supports front-buffer rendering?
<pq>
I
<pq>
I'm not thinking about front-buffer rendering at all.
<emersion>
right, but daniel said DIRTYFB was used for front-buffer rendering
<pq>
I thought you could mark damage with flip in the legacy UAPI too, but maybe you can't?
<pq>
drm_mode_fb_dirty_cmd does contain fb_id, so it seems like it could work
crabbedhaloablut has quit [Ping timeout: 480 seconds]
<javierm>
pq: you can but there are some corner cases that don't work. For example, you can't combine DRM_IOCTL_MODE_DIRTYFB with DRM_MODE_PAGE_FLIP_ASYNC
<emersion>
it seems like drm_atomic_helper_dirtyfb() performs an atomic commit with only FB_DAMAGE_CLIP filled
<pq>
emersion, sounds broken, does it not take the fb_id into account?
<emersion>
it uses the fb_id only to find the right plane
<pq>
and if the fb_id is not on any plane right now?
crabbedhaloablut has joined #dri-devel
<emersion>
it commits nothing
<emersion>
rather, commits with no change
<pq>
I am thinking of: plane has FB1; DIRTYFB FB2; PageFlip plane to FB2
<emersion>
right, that sounds like a no-op with that helper
<pq>
unless PageFlip to atomic converter looks at the FB damage rects?
<emersion>
with that helper, the DIRTYFB region is lost
<emersion>
if no plane is using the FB
<sima>
pq, dirtyfb is _only_ for the frontbuffer rendering flush, nothing else
swalker_ has joined #dri-devel
<sima>
if you page flip you want the FB_DAMAGE one to minimize upload
<pq>
emersion, that would explain why javierm did not get it to work.
<sima>
for usb/spi/i2c panels/outputs but also for integrated dsi panels that have selective upload
swalker_ is now known as Guest5753
<emersion>
okay, that makes sense
<sima>
plus also all the virtual displays tend to benefit too (since they need to copy)
<emersion>
sima, so does atomic support front-buffer rendering?
<sima>
internally dirtyfb is implemented for atomic drivers as a pageflip of the frontbuffer using the damage prop
<sima>
emersion, sure
<pq>
sima, even with legacy UAPI? How do you use FB_DAMAGE_CLIP with legacy?
<emersion>
and the way to do it is via a commit which updates FB_DAMAGE_CLIPS and nothing else?
<sima>
you could essentially emulate dirtyfb with a atomic flip with same fb_id but damage rect (without damage rect it's an implied full damage) and whatever else you want to change
<emersion>
sima, but without damage rect, my atomic commit is empty…
<sima>
pq, what kind of legacy do you mean? like legacy (non-atomic) driver, or using the legacy SETCRTC ioctl, or just the legacy DIRTYFB ioctl?
<sima>
emersion, hm it shouldn't be ...
<sima>
maybe you need to ask for an event to trigger the upload
<pq>
sima, using non-atomic UAPI with PageFlip
<linkmauve>
“10:00:21 HdkR> linkmauve: -Dopengl=false in meson?”, that disables all GL, GLESv1_CM, GLESv2, while I still want that third one.
<emersion>
maybe i can set the FB to the same ID as the previous one?
<sima>
pq, if you use both page flip and dirtyfb legacy ioctl you're very confused ...
<pq>
sima, I mean non-atomic userspace, not driver
<sima>
emersion, yeah you need to set something to include the crtc in the commit so that the event flag actually does something
<emersion>
right
<daniels>
pq: drmModeDirtyFB is literally that 'here's a dirty region for the same buffer' ioctl for legacy userspace
<sima>
pq, yeah still, pageflip is for background rendering and flipping
<pq>
sima, why would I be? I just want the flip to have damage rects. So how would I use FB_DAMAGE_CLIPS?
<sima>
dirtyfb is for frontbuffer rendering, single buffer
<sima>
if you mix them, your compositor is confused
<emersion>
tbh would've been nice to have a "plz send page-flip event" CRTC prop
<emersion>
instead of a global flag
<sima>
pq, you can't flip with damage rects with legacy ioctl, you can only use atomic for that
<pq>
sima, I'm not talking about a compositor but a random old KMS app.
frankbinns has joined #dri-devel
<daniels>
pq: you can't attach a damage rect to a different-buffer flip with legacy userspace
<sima>
legacy pageflip ioctl is always implied full damage
<daniels>
I think there's some kind of new API that fixes this, not sure tho
<sima>
and since legacy isn't atomic you can't change both the fb_id and damage prop together
<sima>
daniels, atomic
ahajda has joined #dri-devel
<pq>
sima, ok, so non-atomic flipping + USB display = sadness, got it.
<sima>
it's for atomically changing more than one prop :-)
<sima>
pq, yup
<pq>
daniels, why is the dirty_cmd carrying fb_id then?
<sima>
pq, because uapi design lols
<pq>
:-P
<daniels>
sima: oh is that what it's called!
<sima>
it really should be the crtc, but we screwed up (I think because Xorg)
<emersion>
daniels, you should really take some KMS lessons
<sima>
pq, so the kernel actually has to do some really stupid stuff to figure out the right crtc, which means we need to take more locks than the atomic ioctl equivalent
<sima>
which is why you should atomic ioctl even if you do frontbuffer rendering (if available)
<sima>
because that's less stupid uapi
<pq>
looks like I'm not the only one mislead by how that old UAPI looks like
<sima>
pq, yeah maybe some docs would be good for this one ...
<sima>
pq, looking at drm_atomic_helper_dirtyfb we try to be clever and unlock the locks we don't need again
<sima>
but we still have to iterate over all planes and temporarily lock them because the fb_id is just the wrong parameter for damage rect upload
<pq>
sorry for the noise :-)
Guest5753 has quit [Ping timeout: 480 seconds]
<sima>
pq, so yeah summary: fb_id in dirtyfb is only used to find the crtc for this frontbuffer (all of the crtc if you clone like Xorg does), it's a no-op for a backbuffer
<sima>
and then it does a damage_clip prop set on that plane/crtc combo
<sima>
oh s/crtc/plane really, but dirtyfb goes back when crtc implied primary plane so some old drivers only flushed the primary plane and nothing else
<emersion>
sima, if i involve a CRTC in a page-flip commit without updating any plane, the driver assumes all planes have full damage?
<emersion>
or do i need to involve the planes in the atomic commit for that?
<emersion>
by "involve", i mean including a no-op property change, e.g. CRTC_ID or FB_ID to the same value as the previous one
epony has quit [Remote host closed the connection]
<sima>
I'm trying to find the code, because I thought yes
<sima>
but it's been a few years ...
epony has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
<sima>
emersion, ok so the implied damage is only for the planes you're adding
<sima>
so if you do a pure crtc only commit, then nothing gets updated
<sima>
if you add a plane (even if it's just with the same fb_id) that plane gets an implied full damage
frankbinns has joined #dri-devel
<sima>
unless you set the damage prop, then it's limited to that
<sima>
other planes don't automatically get any implied damage so that the legacy ioctl (which are all incremental) dont result in unecessary uploads
<sima>
e.g. if you have an overlay that you update with the legacy setplane ioctl
i509vcb has quit [Quit: Connection closed for inactivity]
<sima>
don't want to update the entire fullscreen desktop frontbuffer too
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<sima>
or if you move/change the cursor
<sima>
emersion, if it's a modeset then the helpers by default add all planes, but that's really just convenience for drivers since most drivers want to fully disable/restore planes in that case
<sima>
(e.g. runtime pm tends to shred register state, and hw tends to get pissed if you shut down the crtc with planes still running)
<sima>
but that's really an implementation detail of "modesets tend to require full upload"
frankbinns has quit [Remote host closed the connection]
<sima>
note actual modeset from the driver pov, not just setting the ALLOW_MODESET flag, that does nothing wrt what the kernel actually commits to hw
frankbinns has joined #dri-devel
cmichael has joined #dri-devel
<pq>
sima, implied full damage; oh gosh, even more special cases to the "kernel ignores no-op changes" doc.
<pq>
it's starting to sound like the MODE_ID example in the doc is actually a special case, not the rule
<pq>
I'm starting to see the confusion some kernel driver devs have about setting an already set value in a commit
<pq>
maybe you should rewrite the doc about the no-op handling
<sima>
pq, hm ...
<pq>
I can't know all the details
<sima>
well the kernel tries to no-op out expensive stuff
<sima>
but the minimal update (especially when you ask for an event) is a page flip, which takes a vblank
<pq>
from you I just now understood that e.g. if a plane has blend mode X, and I submit an atomic commit that has nothing but sets the blend mode to X again, it will imply full damage.
<sima>
so for these there's kinda a lower bound of how much no-op optimizations you can do, since you still have the vblank delay anyway
<sima>
pq, hm
<sima>
pq, that's maybe not the intention, but maybe the effect
<pq>
yeeeah
<sima>
pq, yeah we'd need to handle that in the code, so that only if fb_id was touched we have the implied full damage maybe?
<sima>
since it's all shared code it's a handful of lines in two places only
<pq>
sounds better to tme
<eric_engestrom>
linkmauve: I think HdkR is right, `-D opengl=false -D gles1=disabled -D gles2=enabled` should give you what you want; doesn't it?
<sima>
and then document that touching fb_id means full implied damage
<sima>
pq, the problem is a bit implementation cost, since we need to make sure that really nothing else was touched
<sima>
like if you do change blend mode, we do need that full implied damage
<sima>
so ... seems a bit brittle to me from correctness pov
<pq>
right
<pq>
I'm still not sure if setting the same FB_ID again should imply full damage, but either way, the result is that userspace should always set FB_ID and FB_DAMAGE_CLIPS together to get an explicit result.
<sima>
otoh the intersection of "plane with blending modes" and "plane that cares about damage in that way" is zero
<sima>
pq, yeah that's best
<sima>
like if your userspace tracks damage, always set it
<sima>
otherwise the kernel needs to make some defensive assumptions
<pq>
right, but the blending mode was just a random example for any KMS property, not blending mode specifically - just something not FB_ID
<sima>
hm if the driver doesn't catch blend changes as full damage for dsi manual upload then it's buggy anyway
<sima>
so maybe this wouldn't be brittle
<sima>
atm we don't have a helper for damage for manual upload where checking everything else matters, no one refactored that out from drivers yet
<sima>
pq, so I think we could clarify this to "only fb_id results in implied full damage" if that's an ask from compositors
JohnnyonFlame has joined #dri-devel
nashpa has quit []
dliviu has joined #dri-devel
<Company>
so, final verdict of the last 5 hours of experiments: making sure that the window background is drawn with vkCmdClearAttachments() and even adding workarounds to draw the rounded parts with shaders (I now hate designers and in particular Apple again), gave me 350fps instead of 220fps on my GPU-bound Intel
<Company>
and my CPU-bound AMD desktop keeps its 1900 fps but the shader clock according to radeontop is now at 1.7GHz from 2.1Ghz before
<linkmauve>
Company, reminds me circa GTK 4.2 when I discovered how round shaders were the reason GTK was horribly slow on Lima.
<linkmauve>
And libadwaita uses them everywhere…
frankbinns has quit [Remote host closed the connection]
<sima>
emersion, feel like typing up some of the conclusions from this chat into uapi docs? I guess for dirtyfb and some pointers/links to the damage prop
<sima>
not sure how/whether to tie it into pq's atomic uapi doc ...
<sima>
maybe a note that currently we have a lot of implied damage and so compositors should always set the damage prop if they track it?
penguin42 has joined #dri-devel
<pq>
sima, as a Wayland compositor dev, I'm partial to favor Waylandish semantics: nothing implies any damage, but the FB in use can read at any time and on any part, so all of it must always have good contents. I understand that KMS needs some implied damage to keep old stuff working.
<pq>
*can be read
<sima>
"fb can be read at any time" we already have
<linkmauve>
eric_engestrom, HdkR, you were both right, it was the “ (all versions)” part which confused me in meson_options.txt.
<sima>
the other part I'm not exactly sure what you mean with "implies any damage"?
<pq>
sima, damage is a request to KMS to read. Without damage, KMS can assume that things did not change so there is no client-side reason to read and KMS can read only the minimum absolutely necessary.
<pq>
sima, it only makes sense outside of the continuous re-scanning of FB.
<sima>
yeah I mean all of this only makes sense if you don't have continuous rescanning
<eric_engestrom>
linkmauve: ah I see, indeed "Build support for OpenGL (all versions)" can be interpreted as also including GLES. I'm not sure how to phrase it better? "Desktop OpenGL (all versions)" maybe?
<sima>
pq, and yeah for backwards compat we have to assume for at least some cases that "no explicit damage" means "implied full damage"
<sima>
instead of what I guess wayland does, which is "no damage means no damage"
<sima>
pq, ^^ that correct?
frankbinns has joined #dri-devel
<pq>
correct
<linkmauve>
eric_engestrom, that would be better yes, but why does it mention versions here? AFAIK there is no mechanism to disable OpenGL versions at compile-time.
<linkmauve>
Only some environment variable to make the application believe it has a specific version, and possibly some driconf as well.
<pq>
I see that FB_DAMAGE_CLIPS already specs that the whole FB must have valid contents regardless, so that's taken care of too.
<eric_engestrom>
linkmauve: fair point, I don't recall building only part of desktop gl every being a thing; maybe it was worded like that because the two other options are "OpenGL ES 1.x" and "OpenGL ES 2.x and 3.x", so they wanted to be clear that for desktop gl the option covered all versions without this split?
<eric_engestrom>
maybe removing "(all versions)" is best
<pq>
eric_engestrom, while you're at it, could I ask to maybe improve the doc for "gallium off-screen rendering" as well? I would not have guessed it referred of OSmesa kind of things, and was puzzled why it was off when surfaceless platform was enabled.
<pq>
and yeah, I too have always assume that disabling "OpenGL (all versions)" would disable all GL ES too.
<linkmauve>
pq, in the past the wiki was used for that, but it isn’t necessarily up to date, and each driver has different page layouts making it kinda hard to figure them out.
<jannau>
I'm not aware of anything more concise
<emersion>
pq, do you have a specific vendor in mind?
<emersion>
ah, no, since it's about driver names
<emersion>
(AMD has a hardware info page, for instance)
<pq>
emersion, the most recent tangible question was "which driver would my Haswell need?"
<pq>
so I just built both crocus and iris, as I couldn't tell which, and only the documentation of the amber brach (which I do not want to use) told me what to use instead of i965
<pq>
that link to the Intel website is utterly unhelpful
<pq>
I could of course just build everything, check which one actually gets used, and then trim the build config
<kode54>
You need hasvk
<kode54>
Oh
<pq>
I was thinking of GL ES 2
<kode54>
Opengl
<kode54>
Don’t think they split Iris
<pq>
but yeah, I don't think the vulkan driver set is much clearer either
<pq>
ah, Arch docs to the rescue - again. It seems like Arch always has the docs for anything related to administrating a pet Linux box. :-)
<daniels>
pq: in short, hsw needs crocus
<pq>
I see, thanks.
flto has joined #dri-devel
epony has joined #dri-devel
vliaskov has quit [Read error: Connection reset by peer]
jkrzyszt has joined #dri-devel
<alyssa>
pq: doc patches welcome
<Company>
linkmauve: so I guess I want to get me some snapdragon minipc to get a mobile GPU - but Google says I probably shouldn't do that because installing Fedora on those things is more likely to fail than succeed?
<linkmauve>
I don’t know about Fedora, but I never had any issue running ArchLinuxARM on my Dragonboard 410c (which doesn’t do Vulkan).
<linkmauve>
Better ask turnip people for which hardware would be best for your usecase, for instance robclark.
<alyssa>
a6xx
<Company>
yeah, seems like it needs a6xx or a7xx GPUs, but I have exactly zero clue where to get some device with that
<robclark>
Company: yeah, defn recommend something a6xx.. there are some chromebooks which are inexpensive and have had upstream kernel support since the beginning.. or for something faster the thinkpad x13s is pretty nice (and my current daily driver).. you can get fedora running on either, but currently takes a bit of work (chromebooks because of the different boot flow.. the windows snapdragon laptops are a bit more normal in that
<robclark>
regard.. I'm using systemd-boot on the x13s). I think all the essentials landed in v6.5 merge window so possibly we'll see fedora installer support on the x13s soon.
<Company>
I ideally want something I can plug into a wall, install Fedora on, and connect via ssh whenever I want to test stuff
bmodem has joined #dri-devel
<robclark>
the aarch64 .raw.xz image is useful for "manually" installing on things which fedora .iso image doesn't support.. just create loop device and dd over the root/home partition
<linkmauve>
Although, if your target is Raspberry Pi and Linux phones, getting a high end Snapdragon might not be the best thing.
<Company>
robclark: those things are expensive
<linkmauve>
Have a look at the PinePhone Pro for instance, it will use panfrost/panvk and be a normal Linux phone.
<robclark>
yeah.. but also having 32GB of RAM and an nvme is nice
<robclark>
but for less expensive, chromebook is a good option
<Company>
I just want to test-drive GTK on it, so cheap is good
<kisak>
oh hey, mesa 23.2-branchpoint is scheduled for today.
<Company>
otoh, if it comes with all the hardware and the hardware works, that's nice, too
<javierm>
Company: I've the X2 Chromebook and mainline (and Fedora support) is pretty good. There are other fedora devs like eballetbo and pbrobinson that also use it so we can assit with the installation :)
<_jannau__>
how close is MS' windows dev kit 2023 to the thinkpad x13s?
<robclark>
_jannau__: it would really just need someone to put together devicetree for it.. it's come up a few times on #aarch64-laptops but not sure if anyone has made any progress yet.. pretty sure someone at least dumped the acpi tables
smiles_ has joined #dri-devel
<robclark>
but pretty much all of the actual driver work for x13s would apply equally for the dev kit
<Company>
that devkit is $200 new, so that's a lot less than all the laptops
<Company>
but I take it that that's not plug and play yet
<_jannau__>
where? I think it should be $600 but comes with 32GB ram and nvme as well
<Company>
I was looking at the ECS LIVA Mini Box QC710
<Company>
which Google claimed was 219 new when it was still sold
<Company>
the x2 chromebook should be a 7c, too, which is why I ended up at that mini box
<robclark>
not sure if anyone is looking at the 7c dev kit
<robclark>
there is someone looking at a 7c win laptop.. but I think that is still WIP
<alyssa>
_jannau__: eyeing greener pastures :~P
<javierm>
Company: if you want a QC machine, I would limit to either the X13s or X2 Chromebook
<alyssa>
?
<javierm>
Company: anything else is choose your own adventure with downstream forks and whatnot
<robclark>
(other 7c chromebooks should be easy too.. they are all pretty similar hw wise)
<Company>
I think I'll go with "try again in a few months"
<javierm>
robclark: right, I should had say 7c chromebooks rather than X2
<Company>
or convince RH to buy me something
<Company>
$200 is okay for something to play with $500+ is a bit much if all I do is compile GTK on it every 3 months
<javierm>
Company: if you just need an aarch64 machine with a well supported GPU, then you can just go with a cheaper board with Mali as other suggested
jfalempe has quit [Remote host closed the connection]
<javierm>
for example the rockpro64 that has a rk3399 SoC and is well supported in mainline and Fedora
<alyssa>
no Vulkan though
<javierm>
alyssa: right
<alyssa>
GL3.1 and GLES3.1, not conformant on anything
<alyssa>
s/anything/either/
<alyssa>
though GLES3.1 is "close"
<Company>
yeah, I ideally want something with Vulkan
<alyssa>
RK3399 remains my personal laptop (with the M1 for work).. soft spot in my heart
<Company>
because then I can experiment with the hardware
<alyssa>
Company: for arm64 + mature Vulkan, one of the recommended a6xx machines is the way to go I think
<javierm>
Company: another option is one of the boards with a TI SoC since there's a DRM and vulkan drivers in the works
jfalempe has joined #dri-devel
<alyssa>
also not mature though
<alyssa>
turnip is years ahead
<mripard>
RaspberryPi + an AMD GPU? :P
<Company>
mripard: I want a mobile gpu
<alyssa>
won't you have PCIe trouble too?
<mripard>
well, it will be "mobile"
sarahwalker has joined #dri-devel
<Company>
my idea was to have 3 kinds of gpus: discrete, integrated and tiling
<mripard>
alyssa: yeah PCIe is going to be limiting
<alyssa>
ok, still need to figure out who's going to convert broadcom and lima
<linkmauve>
alyssa, what needs converting?
<emersion>
Company: multi-GPU? :D
<emersion>
also split render/split is good to have
jkrzyszt has quit [Remote host closed the connection]
<emersion>
and display-only like displaylink
<emersion>
hm, not for GTK i suppose
<Company>
GTK cares a bit about switching GPUs
<Company>
that's why I bought my desktop CPU with an embedded GPU
<alyssa>
Company: you must be perfect for social gatherings,
<Company>
which I promptly deactivated in the bios
<alyssa>
for when people want to have Company over
<alyssa>
=P
<Company>
alyssa: that's where the nick comes from!
<alyssa>
=D
<alyssa>
I love fun nick stories ;D
<alyssa>
So it's not Company & Company? :=p
<Company>
was a co-op account, and when my regular nick wasn't available on battle.net anymore in 1999, I took this one
<alyssa>
=)
sarahwalker has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
<Company>
with lavapipe, my Vulkan renderer that does 350fps on Vulkan does 15.5fps
<Company>
also, no visual bugs that I can see
<emersion>
s/Vulkan/real hw/ i assume?
<Company>
that's nice because it means CI can soon run the Vulkan tests
<zamundaaa[m]>
Company: if you care about switching between GPUs, does that mean that GTK will also eventually gain support for surviving GPU resets?
<Company>
emersion: my Intel TigerLake
<emersion>
lavapipe is still Vulkan ;)
<Company>
yeah, there was a lot of "Vulkan" in that sentence
<Company>
zamundaaa[m]: GPU resets shouldn't be that much of a problem because you can switch GTK renderers at runtime
<Company>
zamundaaa[m]: but nobody looked at it, because people's GPUs don't typically reset
<emersion>
you should try amd :P
<Company>
the thing GTK can't and doesn't want to deal with is compositor resets
<linkmauve>
Or lima.
<zamundaaa[m]>
Company: they definitely do reset, it's (sadly) not that uncommon
<Company>
emersion: my desktop seems to still be working :p
<kchibisov>
it would be nice to handle gpu resets if only compositors wouldn't die along the resets...
* kchibisov
had to change amd gpu to intel due to amd having reset/hard reset every 4-8 hours.
<Company>
GTK's renderers should be fine with restarting, the only issue we have is that our GdkTexture objects have no way to recover
<Company>
and they're meant to be immutable
<zamundaaa[m]>
kchibisov: You just have to use the right compositor ;)
<Company>
but that's a special case for when we get external textures
<Company>
like GStreamer or spice
<kchibisov>
Do you mean kwin, zamundaaa[m] ? I want to test handling of GPU resets in my client.
<kchibisov>
In general I do wonder how should I test it, I was made aware of AMDGPU option to trigger reset, but my compositor dies with that.
hansg has joined #dri-devel
<Company>
kchibisov: how?
<kchibisov>
Company: how to trigger a reset?
<Company>
just so I know how to do it should I ever want to
<Company>
yeah
<zamundaaa[m]>
kchibisov: yes. KWin 5.27 is mostly robust against GPU resets (in real world terms it handles them fine), and git master shouldn't crash even in worst case situations
<kchibisov>
zamundaaa[m]: do you know a setup where I could test all of that? I have kwin only in qemu...
<DemiMarie>
<marcan> "the issue here was that X died..." <- Explicitly refuse to support Xorg. X11 desktops can run in full-screen rootful Xwayland.
<emersion>
sima: what happens when PAGE_FLIP_EVENT is used with PAGE_FLIP_ASYNC?
<emersion>
the event is delivered immediately?
<sima>
when the buffer is being scanned out, which is a bit hw dependent how quickly that happens
<sima>
I'm not exactly sure what happens to the timestamp/frame number you get
<zamundaaa[m]>
kchibisov: either install it on your system, or make a separate partition. Live boot may work too, if you restart KWin after installing Mesa from git
Company has quit [Remote host closed the connection]
<kchibisov>
I mean, I just don't want to pull it on my system ¯\_(ツ)_/¯. I hoped that it's sort of possible to do inside the qemu just fine.
<zamundaaa[m]>
If you can do GPU passthrough, that should work too
<kchibisov>
Do you happen to know whether it's possible to trigger reset on intel hardware?
<kchibisov>
I don't have amdgpu around anymore.
<sima>
emersion, honestly no sure what happens to these, but the event should go out as soon as the old buffer stops being scanned out
<zamundaaa[m]>
I don't know of one, no. Even running an app with a shader that hangs didn't do a full reset on Intel, it just killed the app that was hanging
* emersion
writes a patch with "When used with PAGE_FLIP_ASYNC, ¯\_(ツ)_/¯"
<kchibisov>
zamundaaa[m]: yeah, I've never had a reset on intel hardware, the worst I've seen it could glitch for a short while.
Company has joined #dri-devel
<sima>
emersion, yeah maybe best, and then cc amd/intel/nouveau/vc4 folks
<sima>
since those are the drivers that do something with it
<linkmauve>
Speaking of GPU resets, on my phone sometimes lima dies due to a timeout, and my compositor gets all confused and starts alternating the last frame and the half-rendered frame until I restart it; would implementing KHR_GL_robustness in lima be enough to let it know it lost the context, and would have to recreate it?
<linkmauve>
Or is it not even a context loss?
<Company>
yup, works
<linkmauve>
[drm:lima_sched_timedout_job] *ERROR* lima job timeout
<linkmauve>
lima 1c40000.gpu: pp task error 0 int_state=0 status=5
<linkmauve>
lima 1c40000.gpu: pp task error 1 int_state=0 status=5
<Company>
kinda evil that cat'ing a file resets stuff
<linkmauve>
↑ this is what I get in dmesg.
<sima>
emersion, if I'll guess you simply get the vblank timestamp and frame number for the previous vblank
<kchibisov>
linkmauve: oh, are you on pinephone?
<emersion>
yeah that's be my guess as well
<linkmauve>
Yes I am.
<kchibisov>
I think I have the same issue on it with lima..
<zamundaaa[m]>
linkmauve: that does look like a GPU reset to me. Note that afaik KWin is currently the only Wayland compositor that handles GPU resets at all
<MrCooper>
Company: it's a debugfs file (accessible to root only), any debugfs file can have any kind of side effects
pp123[m] has joined #dri-devel
<sima>
emersion, maybe an igt sheds some light? or MrCooper?
<linkmauve>
kchibisov, I’ll try to figure out why GL_ARB_robustness gets exposed in a GL context, but not GL_KHR_robustness in a GLES context.
<linkmauve>
But I’d like to find a way to reproduce that bug at will.
<sima>
iirc MrCooper implemented page_flip_async first, so whatever is in there is the uapi :-)
<Company>
MrCooper: still, i'd have expected echo 1 > file for something like it
<MrCooper>
emersion sima: I share your guesses for the values in the events; other than that, the events work exactly the same as without ASYNC
<kchibisov>
linkmauve: were you using catacomb?
<linkmauve>
zamundaaa[m], which extension do you use? Does it work on lima?
<linkmauve>
kchibisov, here is one instance where the crash happened right at the same time as the glitch.
<linkmauve>
kchibisov, catacomb isn’t using the GPU for this though I think, it’s using a plane.
<kchibisov>
yeah, it's all on the planes.
<kchibisov>
it just barely never composes itself, because every client is using dmabuf and on the phone you have at max 3 clients visible at once.
<jenatali>
Ugh, the addition of blake3 broke our arm64ec build, that's frustrating
<kchibisov>
And you have 3 planes on pinephone which you could really use for that.
rasterman has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
<zamundaaa[m]>
linkmauve: EGL_EXT_create_context_robustness for creating a robust context, and either GL_ARB_robustness or GL_EXT_robustness (whichever is available) to check for GPU resets
rasterman has joined #dri-devel
<zamundaaa[m]>
GL_KHR_robustness does not seem to be supported on lima
<linkmauve>
Neither of the three are. :/
schaeffer has quit [Quit: well, bye]
schaeffer has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
<zmike>
eric_engestrom / DavidHeidelberg[m]: another ci rules change I'd like to see is having gallivm changes only trigger llvmpipe/lavapipe-based jobs
rgallaispou has quit [Read error: Connection reset by peer]
paulk-bis has quit []
paulk has joined #dri-devel
simon-perretta-img__ has joined #dri-devel
rgallaispou has joined #dri-devel
epony has quit [Remote host closed the connection]
hansg has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
<eric_engestrom>
zmike: this looks non-trivial, writing it down for later
<zmike>
it's a real struggle to make any gallivm changes atm because it triggers every possible driver job
<zmike>
when it's already been proven that this isn't necessary
<eric_engestrom>
indeed
<zmike>
mesa/st uses draw module for some things, which uses gallivm, but llvmpipe jobs would fail anyway if any other driver would break from such changes
<eric_engestrom>
I think my refactor !24099 will make doing this kind of changes easier to do, if you want to help it land ;)
<eric_engestrom>
(I know it's big, but the first half is small easy to review commits, and the second half is moving code in blocks with no changes, so not too hard to review either)
linkmauve has left #dri-devel [#dri-devel]
hansg has joined #dri-devel
<alyssa>
robclark: I don't suppose there's a2xx drm-shim?
<robclark>
yes, same drm-shim as other gens should work..
<alyssa>
oh nice
<alyssa>
that makes things a lot easier!
<alyssa>
ok, I have shader-db going. this is some *weird* assembly.
<lumag>
alyssa, ack, will do that either today, or tomorrow.
linkmauve has joined #dri-devel
linkmauve has left #dri-devel [Error from remote client]
linkmauve has joined #dri-devel
<alyssa>
thanks!
rgallaispou has left #dri-devel [#dri-devel]
bmodem has joined #dri-devel
smiles_ has quit [Read error: No route to host]
smiles_ has joined #dri-devel
simon-perretta-img_ has quit []
simon-perretta-img__ has quit []
<enunes>
alyssa: hi, about the lima backend fixes for the nir register rework, is it expected to be a change as small as this last one? maybe I can do that if it's not a huge amount of work
fxkamd has joined #dri-devel
ahajda has joined #dri-devel
dmitz has joined #dri-devel
benjaminl has joined #dri-devel
<alyssa>
enunes: should be small yet
<alyssa>
s/yet/yeah/
<alyssa>
the lima/pp change will look like that a2xx change there
<alyssa>
lima/gp will be a bit different, since there you don't want to fold in the registers into instructions at all, you just want to translate load_reg/store_reg to GPIR instructions directly
<alyssa>
(possibly net negative LOC from the gpir change)
jagan_ has joined #dri-devel
<enunes>
alyssa: right, I can give it a shot, any hint on how to iterate and check that it is good? should I locally delete struct nir_register or nir_src or something and work until it works satisfying that?
<enunes>
or do you have a branch I should pull with the end goal removing everything we want to get rid of
smiles_ has quit [Remote host closed the connection]
<alyssa>
enunes: Everything you need for gpir landed upstream last night
<alyssa>
for ppir, I would start by changing which NIR passes you call (see the a2xx change as a model, ppir will be the same), and then everything will break because suddenly your compiler will see new intrinsics that weren't there before
<alyssa>
then rework your nir_src/nir_alu_src/nir_dest/nir_alu_dest -> ppir translation to call into nir_legacy instead so you can ignore the new intriniscs
<alyssa>
and likewise set abs/neg/sat based on the legacy_alu_src/dest and ignore fabs/fneg/fsat when nir_legacy tells you to
<penguin42>
oh, i915_get_query_result is funny; '*result = 512 * 1024 * 1024;' always that result, whatever :-)
junaid has quit [Ping timeout: 480 seconds]
itsmeluigi has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
itsmeluigi has quit [Remote host closed the connection]
benjamin1 has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
<DemiMarie>
emersion: from my PoV C is mostly useful for legacy reasons (compatibility with C APIs, wide platform support). If one wants a systems programming language with a good spec that is Ada, not C.
<DemiMarie>
What is the situation with Vulkan support on e.g. Panfrost?
<emersion>
DemiMarie: to each their own, i'm not biting again
<DemiMarie>
emersion: fair
ngcortes has joined #dri-devel
jagan_ has quit [Remote host closed the connection]
<alyssa>
enunes: if you can take of care of lima/gp at least, that one scares me ;)
iive has joined #dri-devel
hansg has quit [Quit: Leaving]
Haaninjo has joined #dri-devel
Company has quit [Quit: Leaving]
<DemiMarie>
I just saw the device memory TCP patchset. Feels like NetGPU all over again.
tursulin has quit [Ping timeout: 480 seconds]
Dr_Who has quit [Read error: Connection reset by peer]
<airlied>
alyssa: why did you think nir_builder_create was a good idea?
<airlied>
isn't it doing a stack copy of that object now always?
<airlied>
it's like a 40 byte copy vs an 8-byte, or does it always get inlined?
<jenatali>
Assuming the C compilers apply the same optimizations they do to C++ code, you get NRVO and it's constructed in place in the caller's frame
<airlied>
ah cool
<pcercuei>
It looks dangerous IMHO
<airlied>
I also assume at O0 it totally goes slow
<pcercuei>
Ah nevermind - I thought it was returning a pointer to a stack variable. I read the code wrong
Haaninjo has quit [Quit: Ex-Chat]
glehmann has quit [Quit: No Ping reply in 180 seconds.]
Venemo has quit [Remote host closed the connection]
glehmann has joined #dri-devel
Venemo has joined #dri-devel
<alyssa>
airlied: that was motivated by ergonomics, not performance
<alyssa>
but I wouldn't expect a performance change given it should be inlined
<alyssa>
I didn't benchmark it but it didn't occur to me it would make a difference
<airlied>
alyssa: tbh I think that is a personal ergonomic preference
<alyssa>
airlied: the real win is for nir_builder_at
<airlied>
for a long time C programmer trained to spot struct copies that reads wrong,
<alyssa>
if it's a problem we can turn it into a macro instead of a static inline
<airlied>
so is the opposite of ergonomic, it's downright uncomfortable
* alyssa
tilts head
<alyssa>
It's not supposed to even be doing anything.. it's just supposed to desugar to an initializer.
<airlied>
you learn the code patterns that look wrong over years, just because the compiler deals with it, doesn't mean you don't squirm everytime :)
<alyssa>
If not for C++, I would even suggest #define nir_builder_create(impl) (nir_builder){.impl = impl, .shader = impl->function->shader}
<alyssa>
(If that works in C++ we can go ahead and do that.)
<airlied>
it being inline makes all the difference, just don't see that immediately from reading uses of it
<alyssa>
ok..
<alyssa>
I don't know what to say. It didn't occur to me this would be a problematic change and I don't recall this coming up during review.
<jenatali>
alyssa: That'd work in C++20
<jenatali>
Assuming that .impl is before .shader in the struct because C++ implies ordering requirements
<alyssa>
jenatali: aren't we stuck at $OLD_VERSION
<jenatali>
We default to C++17
<jenatali>
I don't know that we strictly require it in common code though
<airlied>
well I think the thing is to be wary of large struct copies if returning structs from things, if that later was to become non-inline for some reason it wouldn't be fun, but otherwise carry on :-)
<alyssa>
I'm not really sure what you want me to say/do
<airlied>
nothing :-)
<alyssa>
okie dokie!
<airlied>
NRVO saves us all
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<alyssa>
jenatali: If the C++ versions allow, I *would* like that function to be re-expressed as a designated initializer return, but that's a different issue.
<alyssa>
but also I have actual work to do :~)
Duke`` has quit [Ping timeout: 480 seconds]
<jenatali>
Yeah, eventually we should start using C++20 for more designated initializers
<HdkR>
<3 designated initializers
sravn has quit [Ping timeout: 480 seconds]
<alyssa>
same
<HdkR>
Apparently clang has a bug where `-wmissing-field-initializers` doesn't work with missing designated initializers. womp womp
sima has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
carbonfiber has quit [Quit: Connection closed for inactivity]
pcercuei has quit [Quit: dodo]
itsmeluigi has joined #dri-devel
apinheiro has joined #dri-devel
pixelcluster_ has quit []
pixelcluster has joined #dri-devel
i509vcb has joined #dri-devel
mattrope has joined #dri-devel
apinheiro has quit [Quit: Leaving]
rasterman has quit [Quit: Gettin' stinky!]
gfxstrand has joined #dri-devel
sukrutb has quit []
itsmeluigi has quit [Remote host closed the connection]
epony has joined #dri-devel
shashanks_ has joined #dri-devel
shashanks__ has quit [Ping timeout: 480 seconds]
Rayyan has quit [Quit: Ping timeout (120 seconds)]
JoshuaAshton has quit [Quit: Gone froggin!]
calebccff has quit [Remote host closed the connection]
calebccff has joined #dri-devel
Rayyan has joined #dri-devel
Rayyan has joined #dri-devel
smiles_1111 has joined #dri-devel
Rayyan has quit []
Rayyan has joined #dri-devel
calebccff has quit []
calebccff has joined #dri-devel
FLHerne has quit [Quit: There's a real world out here!]