lstrano has quit [Remote host closed the connection]
lstrano has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
vliaskov has quit [Read error: Connection reset by peer]
<airlied>
karolherbst: oh I'm still inlining clc, I should figure that out
<karolherbst>
I have patches somewhere...
<karolherbst>
but yeah
<karolherbst>
if you give me a branch where llvmpipe supports functions, I can deal with that
<karolherbst>
thre are some passes which need fixing and other random stuff
<airlied>
my llvmpipe-cl-funcs is the hacky branch that "works"
<airlied>
I'll clean it up eventually
<karolherbst>
okay
* airlied
should be able to hack up not inlining, I'm pretty sure I wrote the original code :P
<airlied>
though I expect I have to move functions from nir shader to nir shader
<karolherbst>
yeah.... so in the perfect world we will have "library" cso rusticl could create for things like libclc and then backends just figure things out
ybogdano has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
cphealy has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
ybogdano has joined #dri-devel
cphealy has joined #dri-devel
cphealy has quit [Read error: No route to host]
cphealy has joined #dri-devel
cphealy_ has joined #dri-devel
cphealy has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
cphealy has joined #dri-devel
cphealy_ has quit [Read error: Connection reset by peer]
cphealy_ has joined #dri-devel
cphealy has quit [Read error: Connection reset by peer]
rmckeever_ has quit []
aravind has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: some hacks on the same branch to avoid inlining libclc functions up front
<airlied>
still horribly slow
<airlied>
oh if I just avoid clc function inline, it's slower but not by a huge amount
Danct12 has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
bmodem has joined #dri-devel
orbea has quit [Remote host closed the connection]
jrayhawk has quit [Quit: debugging performance issues in 1.4.3]
jrayhawk has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
mhenning has quit [Quit: mhenning]
itoral has joined #dri-devel
flibit has joined #dri-devel
bgs has joined #dri-devel
flibitijibibo has quit [Ping timeout: 480 seconds]
dcz_ has joined #dri-devel
kts has joined #dri-devel
srslypascal has quit [Quit: Leaving]
mszyprow_ has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has joined #dri-devel
srslypascal has joined #dri-devel
danvet has joined #dri-devel
garrison has quit []
i-garrison has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
<karolherbst>
yeah.. for clc we really have to check which functions to inline and which not
lemonzest has joined #dri-devel
i-garrison has quit [Read error: No route to host]
i-garrison has joined #dri-devel
krh_ is now known as krh
airlied_ has joined #dri-devel
vliaskov has joined #dri-devel
airlied has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
airlied_ has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
jekstrand has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
<MrCooper>
DavidHeidelberg[m]: unless it pins the versions of all toolchain/header/... packages, an alpine build job should not be part of the pre-merge pipeline (too high risk of breakage caused outside of an MR or Mesa in general), though it would be useful in the daily scheduled pipeline, to get a heads up for such breakage
airlied_ has joined #dri-devel
<tzimmermann>
javierm, have a minute?
<tzimmermann>
i've been working on the fbdev format selections, which sometimes fails.
airlied has quit [Ping timeout: 480 seconds]
<tzimmermann>
the fix is to avoid using the preferred depth entirely. drivers will have to submit the bpp argument (or a default of 32). and that's what fbdev uses
<tursulin>
daniels: hey there - do you have visibility into fdo mailman inboxes or smtp logs? I have discovered a weird problem where it looks some of my messages to dri-devel are not getting there.
<tzimmermann>
if video= is given, it does override defaults, but if the override doesn't work, fbdev falls back to the driver default unconditionally
<tzimmermann>
this appears to be working. and all that's needed for simpledrm/ofdrm is a conversion from <default format>-to-native
<tzimmermann>
javierm, ^
<daniels>
tursulin: sure, throw me some message IDs?
<javierm>
tzimmermann: I see. That makes sense
<javierm>
tzimmermann: what fbdev drm emulation do? print a warning? an info? when not being able to set to video=foo-16 and fallback to 32 ?
<tzimmermann>
ok. just wanted to hear your opinion
<tzimmermann>
maybe. or just fallback transparently.
<tursulin>
daniels: 20221019173254.3361334-1-tvrtko.ursulin@linux.intel.com is missing
<tzimmermann>
or maybe drm_dbg()
<tursulin>
(one example)
<javierm>
tzimmermann: Ok. I think that at least an info should be printed, just to let users know that their option isn't supported
<javierm>
nothing to do about it, but they can stop trying to do that and remove the video= param from their cmdline
<tzimmermann>
makes sense
<tursulin>
daniels: it hit the other recipients like intel-gfx and cgroups and in fact I use the same git-send-email to send it like my other patches which did appear on dri-devel
<tzimmermann>
6 or 7 drivers get the depth/bpp values wrong. i had to fix them. after that the fbdev fix is selfcontained
<javierm>
tzimmermann: awesome
<tzimmermann>
and the simpledrm/ofdrm changes can then go on top
<tzimmermann>
i'll probably send this out after the damage-worker patchset has been merged
<daniels>
tursulin: do you have anything newer? that's from Oct 19th, and the logs only go back to 22nd
<javierm>
tzimmermann: do you want someone to review your series that get rid of remove the damaga worker? Or I think danvet was looking at that already?
<danvet>
I was just about to get another coffee and get to that series ...
<tzimmermann>
danvet, :)
<tzimmermann>
javierm, did you look at the nomodeset-for-fbdev patches? specifically the first one, which moves the option to drivers/video?
<daniels>
tursulin: SMTP only received for intel-gfx@ for that Message-ID, we never got an inbound delivery for dri-devel@
<tzimmermann>
it's nothing spectacular, but i think you should be aware of what's happeing there
<javierm>
tzimmermann: let me take a look, I saw that Helge was giving feedback so I thought my input was not needed
<tursulin>
daniels: oh wow.. so I guess suspicion turns towards Intel stmp..
<tursulin>
daniels: thanks for looking into it!
<tursulin>
at least explains why I was getting so little feedback on that work..
gouchi has joined #dri-devel
airlied has joined #dri-devel
<tzimmermann>
yeah, i wanted to prepare another iteration today to address his comments
airlied_ has quit [Ping timeout: 480 seconds]
<daniels>
tursulin: haha, np
<javierm>
tzimmermann: Ok, let me take a look now then
tango_ has quit [Remote host closed the connection]
rasterman has joined #dri-devel
tango_ has joined #dri-devel
Lucretia has quit [Read error: Connection reset by peer]
Lucretia has joined #dri-devel
pcercuei has joined #dri-devel
<danvet>
emersion, pq, jessica_24 on the fill color thing I'm happy to be told that I'm wrong and people actually do use fill color for planes everywhere
<danvet>
just feels like something we should really check first, since afaik a bunch of drivers only have background fill and not plane fills
<danvet>
s/drivers/hw/
lygstate has quit [Remote host closed the connection]
swalker_ has joined #dri-devel
swalker_ is now known as Guest1167
srslypascal is now known as Guest1168
swalker__ has joined #dri-devel
srslypascal has joined #dri-devel
Guest1168 has quit [Ping timeout: 480 seconds]
<emersion>
danvet: plane fill would be useful for me, but if only one driver supports it maybe not worth it indeed
Guest1167 has quit [Ping timeout: 480 seconds]
<danvet>
yeah maybe more drivers need to chime in with "we can do it and want it"
<danvet>
pinchartl, melissawen mripard maybe?
<danvet>
or maybe I'm just totally wrong
heat has joined #dri-devel
kov has quit [Quit: Coyote finally caught me]
kov has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
mvlad has joined #dri-devel
Daanct12 has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
srslypascal is now known as Guest1177
srslypascal has joined #dri-devel
Guest1177 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
jkrzyszt has joined #dri-devel
<DavidHeidelberg[m]>
MrCooper: it's pinned to latest stable version, same as we do for Debian and Fedora
<lygstate>
Also this MR's last commit also fixed some issue found by this option
nchery has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
kts has joined #dri-devel
pochu has quit [Quit: leaving]
sysescool_ has joined #dri-devel
pochu has joined #dri-devel
sysescool__Linux has quit [Ping timeout: 480 seconds]
<emersion>
vsyrjala: gentle ping about immediate flip
kts has quit [Quit: Leaving]
jkrzyszt has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
itoral has quit [Remote host closed the connection]
<MrCooper>
DavidHeidelberg[m]: the Debian and Fedora images use a specific stable version, not the latest one (which might change automatically)
<DavidHeidelberg[m]>
MrCooper: I know :) For Alpine 3.16 is defined in MR
<DavidHeidelberg[m]>
so it's fixed against specific version. I agree that put "latest" would be a bit breaker :D
kts has joined #dri-devel
mbrost has joined #dri-devel
sysescool__Linux has joined #dri-devel
sysescool_ has quit [Remote host closed the connection]
devilhorns has quit []
tango_ is now known as Guest1193
tango_ has joined #dri-devel
Guest1193 has quit [Ping timeout: 480 seconds]
yuq825 has quit []
linkmauve has left #dri-devel [Error from remote client]
linkmauve has joined #dri-devel
sysescool_ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
sysescool__Linux has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
fxkamd has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
<linkmauve>
Hi, I’m trying to start Weston on zink on radv, but using seatd it fails to start with “radeonsi: driver missing” after successfully finding /usr/lib/dri/zink_dri.so, and launching it directly through waypipe it segfaults in wsi_swapchain_finish().
<linkmauve>
Is it expected to work already, or should I build radeonsi or iris instead?
<linkmauve>
I can rebuild in debug instead of release if that would help.
<linkmauve>
This is from waypipe.
<linkmauve>
All of chain->device, chain->dma_buf_semaphore, chain->wsi are NULL at the location of this segfault.
flibit has quit []
flibitijibibo has joined #dri-devel
<robclark>
tursulin: btw, what happened w/ gputop igt patches, are they languishing somewhere waiting for a r-b?
gawin has joined #dri-devel
<tursulin>
robclark: yep, I can resend if you want?
<robclark>
yes pls, CC me on 'em and I'll review
<robclark>
I'd kinda forgot about them and thought they landed already until I went looking for it yesterday evening ;-)
<tursulin>
will do
<robclark>
thx
<daniels>
linkmauve: zink works both on shm and as a weston host, so I'd be looking at why you get VK_ERROR_SURFACE_LOST_KHR, which from looking at the code can only be from WSI init failing; you'd want to either debug wsi_wl_display_init() or run with WAYLAND_DEBUG=client as usual
<MTCoster>
Does vk_common_cmdSetColorWriteMaskEXT intentionally mark CB_BLEND_EQUATIONS as dirty instead of CB_WRITE_MASKS or is that a bug?
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Leopold_ has quit []
mbrost has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<tursulin>
robclark: sent - although I'll need to do a pass myself given the time gap makes me feel a bit uncomfortable in what state I left it
<tursulin>
I *think* it was mostly clean and absent of any Valgrind issues which is a good start
<tursulin>
next week though
<robclark>
sounds good.. I'll take a look after breakfast
Company has joined #dri-devel
<linkmauve>
Hmm, I’ll debug weston later, in the meantime I’ve rebuild Mesa with radeonsi support but now when I run Genshin Impact on radv it crashes in about one minute (before which it renders just fine), while it runs fine for an extended period of time on and.
<linkmauve>
0258:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.
<linkmauve>
Got these two not very helpful lines from wine.
tzimmermann has quit [Quit: Leaving]
warpme____ has joined #dri-devel
<linkmauve>
What would be the way to debug radv here?
gio_ has quit []
gio has joined #dri-devel
fxkamd has quit []
srslypascal is now known as Guest1210
srslypascal has joined #dri-devel
mszyprow_ has joined #dri-devel
Lucretia has quit []
Guest1210 has quit [Ping timeout: 480 seconds]
Lucretia has joined #dri-devel
ced117 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
mszyprow_ has quit [Ping timeout: 480 seconds]
mszyprow_ has joined #dri-devel
yogesh_m1 has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
swalker__ has quit [Remote host closed the connection]
gawin has quit [Ping timeout: 480 seconds]
<pinchartl>
danvet: I'm not aware of hardware that support plane fill in drivers I maintain
<pinchartl>
the only use case I've heard of (replacing plain colour areas in the composed output with a plane to avoid scanning out consuming memory bandwidth) seems quite a corner case to me. I could underestimate its importance though
<javierm>
pinchartl: does even the msm hw support this? or the patches are only for the use case that you mentioned as well?
<javierm>
I should probably look at those patches to figure out
Akari has joined #dri-devel
kts has quit [Quit: Leaving]
jekstrand has joined #dri-devel
<robclark>
yes, at least some gens of msm support solid-fill.. older gens it was a property of the mixer (ie. it consumes a mixer stage but not an SSPP)
mdnavare has joined #dri-devel
gawin has joined #dri-devel
Major_Biscuit has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
mszyprow_ has quit [Ping timeout: 480 seconds]
rmckeever has joined #dri-devel
mhenning has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
nchery has joined #dri-devel
leezu has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
oneforall2 has quit [Read error: No route to host]
oneforall2 has joined #dri-devel
Jeremy_Rand_Talos_ has joined #dri-devel
<macromorgan>
linusw: Sorry, just sent the newest patch for the NewVision panel that you reviewed and I forgot to cc you. :-(
<macromorgan>
Thank you once again though. Now I just need to get the Samsung one done and I'm golden.
lynxeye has quit [Quit: Leaving.]
danvet has quit [Ping timeout: 480 seconds]
mszyprow_ has joined #dri-devel
jewins has joined #dri-devel
mvlad has quit [Remote host closed the connection]
bgs has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
dakr has quit [Read error: No route to host]
dakr has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: No route to host]
gawin has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
rasterman has quit [Quit: Gettin' stinky!]
mszyprow_ has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
yogesh_mohan has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
yogesh_m1 has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<justsid>
I got a question about resource ownership in Mesa. I'm trying to track down a leak of staging memory in Zink and I think my Zink resource never gets deleted because the wrapper buffer objects never gets its refs dropped to 0. Basically, when u_upload_alloc() is called, the callee gets a reference to the returned buffer object, which makes sense. However, I don't see where those references get dropped again. When the buffer is used
<justsid>
and bound as eg. a vertex buffer, the backend takes out another reference on the buffer and correctly releases that later on. But where do the other references get removed?
<justsid>
I see u_upload_alloc_buffer() starts with a ref and then drops it later on when it makes a new buffer. But I don't see where the references taken out by u_upload_alloc get de-refed (say when called through u_vbuf_upload_buffers)\
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
pcercuei has quit [Quit: dodo]
jekstrand is now known as Guest1242
jekstrand has joined #dri-devel
Guest1242 has quit [Ping timeout: 480 seconds]
<pinchartl>
javierm: I'm not sure
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<pinchartl>
I would have thought that analyzing the composer output to detect large rectangular areas with a plain colour would cost more than what you would save with the optimization. I suppose I'm wrong
<javierm>
pinchartl: yeah, my intuition was the same than yours