<gawin>
have there been changes to zstd handling recently? 32bit build seems busted on arch
<gawin>
fails at /usr/sbin/ld: cannot find /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib32/libzstd.so: No such file or directory
<gawin>
(it was working for me a week ago with outdated tree)
sarahwalker has joined #dri-devel
<linkmauve>
gawin, dumb question, but do you have lib32-zstd installed?
<gawin>
I do
swalker_ has joined #dri-devel
<linkmauve>
gawin, do you perhaps mean /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../lib32/libzstd.so ?
swalker_ is now known as Guest11539
<zzag>
do you need special permissions to allocate buffers when using a render node provided by vgem?
soreau has quit [Ping timeout: 480 seconds]
<zzag>
I get "KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied" when trying to allocate buffers using gbm
sarahwalker has quit [Ping timeout: 480 seconds]
<gawin>
yeah, seems missing, maybe it's on gcc's side. I don't see updating any libzstd package in logs recently and was using this recently.
<MrCooper>
gawin: if this is about Mesa (or another project using meson), maybe try something like 'meson configure --clearcache <build directory> || meson setup <build directory> --reconfigure || meson setup <build directory> --wipe'
<linkmauve>
gawin, sounds like the build system didn’t get updated after an update of your system, try wiping— yeah what MrCooper is saying.
<MrCooper>
zzag: dumb BOs being a KMS thing, I wouldn't expect render nodes to support them
<emersion>
zzag: you need primary nodes
<zzag>
yeah, it seems to work
<zzag>
but that's not exactly what I want
<zzag>
I'd like to have some way to allocate buffers where I can render to
<emersion>
dumb buffers are for software rendering only
<gawin>
seems going, thanks, meson lesson learned: slapping --reconfigure can be not enough.
soreau has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<zzag>
emersion: How does mesa handle such things? Does it open the primary node? I'd like to run some tests that need OpenGL on a machine without physical GPUs, so software rendering seems the only viable option..
aleasto- has quit []
<zzag>
oh, given surfaceless_probe_device(), it appears like mesa searches for DRM_NODE_PRIMARY when using software rendering
dcz has quit [Ping timeout: 480 seconds]
aleasto has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
Cyrinux9 has quit [Remote host closed the connection]
kxkamil has quit []
kxkamil has joined #dri-devel
devilhorns has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
Cyrinux9 has joined #dri-devel
khfeng has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
bmodem has joined #dri-devel
JohnnyonFlame has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
Guest11539 has quit [Remote host closed the connection]
bluetail42 has quit [Remote host closed the connection]
bluetail42 has joined #dri-devel
Company has joined #dri-devel
bluetail42 has quit [Remote host closed the connection]
bluetail42 has joined #dri-devel
bluetail42 has quit [Remote host closed the connection]
bluetail42 has joined #dri-devel
avoidr has joined #dri-devel
itoral has quit [Quit: Leaving]
mbrost has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mbrost_ has joined #dri-devel
apinheiro has quit [Quit: Leaving]
sarahwalker has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
mbrost has quit [Read error: Connection reset by peer]
<danvet>
mairacanal, tbh I'd include the entire explainer with all the links in the commit message
<danvet>
also maybe explain a bit more what the i915 issue is: in the legacy case (where we don't get the modifier from userspace) the i915 fb_create hook computes the right modifier, which isn't necessarily linear, and so if we check before that point we might get wrong answers
<danvet>
with that a-b: me
<mairacanal>
thanks! i'll improve the commit message
Haaninjo has joined #dri-devel
kzd has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Targetball[m] has joined #dri-devel
fab has left #dri-devel [#dri-devel]
<gfxstrand>
jenatali: At this point, I'm fine with abandoning it.
<gfxstrand>
jenatali: At one point, there was some notion that it might become a proper layer. At this point, I no longer think that will ever happen. Embrace the runtime.
pochu has quit [Ping timeout: 480 seconds]
<jenatali>
gfxstrand: Ok cool. I've kept the headers clean for now but have been more cavalier accepting implementation details
<jenatali>
This series is getting... large, for a very minor payoff at the end
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
co1umbarius has joined #dri-devel
Dr_Who has quit [Read error: Connection reset by peer]
<DemiMarie>
How does OpenCL 2.0 compare to Vulkan compute?
columbarius has quit [Ping timeout: 480 seconds]
khfeng has quit [Ping timeout: 480 seconds]
<danvet>
tzimmermann, on the defio overflow, I just replied that we could just put a WARN_ON(total_size > helper->fb-height * helper->fb->pitches[0]); in the damage calc path
<danvet>
just to make sure we don't miss this crucial connection again
<danvet>
thoughts?
<tzimmermann>
makes sense
<danvet>
but I also don't want to really bikeshed this any further, imo also fine to merge what'ver you're happy with as-is
devilhorns has quit [Quit: Leaving]
<danvet>
feel a bit sorry for dragging sui around so much :-/
Duke`` has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<tzimmermann>
let's add the WARN_ON and get it merged
<danvet>
tzimmermann, either way, can you pls reply to sui and ack the change to so it's clear?
<danvet>
ack
gawin has quit [Ping timeout: 480 seconds]
<gfxstrand>
jenatali: :'(
<tzimmermann>
ok
alyssa has left #dri-devel [#dri-devel]
<jenatali>
gfxstrand: Hopefully I'll have it done enough for a (draft) MR today, so you can see what I'm thinking and let me know if I went overboard
<gfxstrand>
Ok
<gfxstrand>
sounds good
avoidr has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
avoidr has joined #dri-devel
frieder has quit [Remote host closed the connection]
stuarts has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
tursulin has quit [Ping timeout: 480 seconds]
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
<zmike>
eric_engestrom: is there syntax yet for the picker script to do version-specific backports
<zmike>
I have a lot of patches that should only be backported to 23.1
stuarts has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
gawin has joined #dri-devel
gawin has quit []
konstantin_ has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
rasterman has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<eric_engestrom>
but with dcbaker we had two ideas of how to make a "backport to release branch X.Y" tag; we should get back to that and land something that's more intuitive than the `cc:` syntax
<eric_engestrom>
zmike: by "always" I mean that it predates our use of gitlab, which feels like it's been forever by now :)
<dcbaker>
eric_engestrom: At this point I don't remember what the two suggestions were and I don't really care, because the CC: syntax is bad
<dcbaker>
if you want I can implement the Stable: X.Y tag
<zmike>
maybe that's what I was 🤔 of
<dcbaker>
or I'll review something from you
<eric_engestrom>
this tag was how we nominated things back in the "emailing patchings to a mailing-list" days
<dcbaker>
I do have some changes I need to send out for the pick script anyway
<eric_engestrom>
dcbaker: agreed; iirc the two of us each had an MR with a suggestion, but I don't remember more, and I think we should just land whatever looks like it won't be too much of a hassle to update later, but it's not like this process changes often so it probably doesn't matter really
<eric_engestrom>
(don't have time to look at this today though)
<dcbaker>
I think I closed mine and yours is opened still and I was supposed to review it :/
<jenatali>
Not convinced yet that it's worth it :)
<eric_engestrom>
dcbaker: ah right, it was the question of whether we want to allow multiple lines `Backport-to: 23.0` + `Backport-to: 23.1` vs combining them into a single line `Backport-to: 23.0 23.1`; I still prefer the former, but I'll see if we can support both or if that doubles the code
<eric_engestrom>
anyway, definitely not for today :)
<dcbaker>
Sounds fair ;)
<dcbaker>
err s/;)/:)s
<dcbaker>
I prefer the two on one line, since that makes fewer lines of metadata in the commit message, but at this point getting rid of CC is my main request :)