<olivial>
I guess it's possible to observe the error and retry with a different format, but would be annoying to distinguish this from other EGL_BAD_MATCH cases
gnuiyl has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
frieder has joined #dri-devel
tzimmermann has joined #dri-devel
Nasina has joined #dri-devel
apinheiro has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
jsa1 has joined #dri-devel
tarceri has joined #dri-devel
AndrewR has joined #dri-devel
<AndrewR>
Lynne, after some patching cinelerra-gg now can use Vulkan decoding for hevc on rx550/radv! Sadly,vulkan h264 decode crash early (on timeline thumbnail generation), may be our ffmpeg 7.0 to blame. It works as binary/cli, but I guess because cingg uses threading A LOT and this hit harder ..
<AndrewR>
Laughable thing - I benched vaapi, vdpau, vulkan hwaccels and Vulkan was faster, then was vdpau (!) and then was vaapi ...
<AndrewR>
so far vdpau survived all files I throw at it, vaapi crashes sometimes on some yt-dlp downloaded files.
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
djbw has joined #dri-devel
<MrCooper>
alyssa: why can't the .packit.yaml/.spec files live downstream?
<daniels>
olivial: heh, are you seeing that in the wild?
<olivial>
daniels: yeah, it prevents gfxbench from running under wayland on the rock5 vendor image lol
<olivial>
glfw tries to use B5G5R5A1_UNORM with the opaque flag
iokill has joined #dri-devel
Company has quit [Quit: Leaving]
<daniels>
olivial: ... ?!
<daniels>
huh
<daniels>
yeah, ok, looks like I used --gfx egl
<olivial>
oh, hmm, I can try that
<daniels>
that at least wfm with the debos image (well, a derivative of) + weston on rock5b
<olivial>
I was running it under xwayland until recently, and then patched out EGL_EXT_present_opaque to avoid the bug
fab has joined #dri-devel
<olivial>
I'm rather confused why it's preferring the 5-bit-per-channel format when it's available...
lynxeye has joined #dri-devel
acryo_ has quit [Remote host closed the connection]
<olivial>
daniels: so I get an entirely different problem with --gfx egl: "WLGraphicsWindow: width and height must be greater than zero (0, 0)"
<olivial>
haven't debugged it yet
<daniels>
olivial: heh, don’t worry, I can fix that after breakfast - thought I had already but apparently not! itmt fullscreen should work?
<olivial>
same thing for --fullscreen=1
kts has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
kts has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
<daniels>
olivial: oh no, that one's easy, you just have to pass --width and --height
<daniels>
the replayer is ... not amazing. I looked at fixing it but decided to do anything else with my life.
<olivial>
hahaha reasonable
rasterman has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
alane_ has joined #dri-devel
alane has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
pcercuei has joined #dri-devel
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 4.6.2]
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
haaninjo has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
guludo has joined #dri-devel
nerdopolis has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
bbrezillon has quit [Ping timeout: 480 seconds]
jfalempe has quit [Ping timeout: 480 seconds]
dolphin has quit [Quit: Leaving]
tomba is now known as Guest15349
jsa1 has quit [Ping timeout: 480 seconds]
itoral has quit [Quit: Leaving]
feaneron has quit [Ping timeout: 480 seconds]
alane has joined #dri-devel
alane_ has quit [Ping timeout: 480 seconds]
<alyssa>
Company: there are lots of asahi gaming users who would happy to run mesa nightly's, I just can't expect them to build their own packages because it's seriously nontrivial with FEX
<alyssa>
(you need 3 builds of mesa - arm64, x86_64, and i386 - and then some magic to bundle it together)
<alyssa>
MrCooper: they might be able to, I'm not 100% sure on how this all fits together yet
feaneron has joined #dri-devel
jsa1 has joined #dri-devel
<mlankhorst>
airlied: I've ported your memcg patch series on xe too, I'm going to try some testing. :)
<linkmauve>
alyssa, FEX doesn’t call into the native driver?
<alyssa>
linkmauve: not by default :(
<alyssa>
for linux fex, you need "thunks" to use the native driver, and thunks are currently broken on fedora for reasons I don't remember
<alyssa>
for windows fex, this Just Works, but we can't ship windows fex yet for a pile of reasons
nerdopolis has quit [Ping timeout: 480 seconds]
<alyssa>
(for windows games "linux fex" emulates an x86 build of wine, whereas "windows fex" is itself run under an arm64 build of wine)
<linkmauve>
Every time I’ve wanted to test FEX I failed to build it, maybe I should try again now that I have a quite performant rk3588. :)
<jannau>
can we get rid of x86 drivers if we fix the thunks? I thought there were unsupported corner cases
<linkmauve>
ARMv8.2 should make things much better than the eternal Cortex-A53 and A57 I had before.
<alyssa>
jannau: we can't get rid of them because of the corners, but I'm not worried about regressing said corners
<alyssa>
if we had "working thunks for everything except corners" + "nightly arm64" + "regular every-3-month-or-whatever x86", I'd be happy
<alyssa>
I think
neobrain[m] has quit []
cborah has quit []
neobrain[m] has joined #dri-devel
neobrain_ is now known as neobrain
<neobrain>
alyssa: jannau: The only corner I'm aware of is steamwebhelper, which sadly isn't exactly unimportant... otherwise you could drop x86 drivers indeed :(
<linkmauve>
So since I don’t plan on using Steam ever, I can avoid building an amd64 version of Mesa?
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
<mlankhorst>
Also last call for features for drm-misc-next, going to send out a pull request later today
epoch101 has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
mehdi-djait3397165695212282475 has quit []
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
asrivats_ has joined #dri-devel
alane_ has joined #dri-devel
alane has quit [Ping timeout: 480 seconds]
<neobrain>
linkmauve: in principle yes, though some debugging might be needed if you plan to use 32-bit windows apps via dxvk, since that hasn't received much testing
<linkmauve>
So far I’ve been using wined3d for i686 games on actual amd64, and only DXVK for one amd64 game.
<neobrain>
wined3d goes through libgl, right? That should work fine with 32-bit apps then
<linkmauve>
Yeah.
asrivats_ has quit [Ping timeout: 480 seconds]
asrivats_ has joined #dri-devel
<imre>
abhinav__: there's been different problems related to lttpr transparent mode, ime it's unreliable in general, the Standard changed to call for setting non-transparent mode for 8b10b. The SCR's title was "DPTX and LTTPR Spec Update for 8B10B".
<linkmauve>
neobrain, alyssa, do you have a backup of the PKGBUILD of FEX-Emu? It seems it got removed from AUR.
pixelcluster_ has joined #dri-devel
mripard has joined #dri-devel
pixelcluster has quit [Ping timeout: 480 seconds]
<neobrain>
none on my end. afaik they removed it because FEX does not run on x86 🤔
<Company>
eric_engestrom: yeah, that's why I said you need to integrate into some larger thing (like gnome nightly) that ships platform + apps
<Company>
iirc the main reason they don't want to ship Mesa git (we argued that in their issue tracker ~a year ago) was the lack of contact person that would ensure issues got resolved quickly
<daniels>
eric_engestrom: I tried to get freedesktop-sdk to move under fd.o but they were never really interested and tbh it's not like we really have a functional xdg org or platform definition anyway, so I'm not really sure what we'd gain
bolson has joined #dri-devel
<Company>
it came up because GTK main needed a bunch of fixes that were only in mesa git for a while
<alyssa>
i had no idea freedesktop flatpak wasn't fd.o, oof
<eric_engestrom>
daniels: yeah I know, and none of us would even care enough to try to get a legal definition and enforce it anyway
<daniels>
it's primarily Codethink/BuildStream/GNOME people
<eric_engestrom>
but it kinda bothers me anyway ^^
epoch101_ has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Quit: Konversation terminated!]
<linkmauve>
Is there a machine-readable list of all DRM ioctls and their arguments somewhere in the kernel?
<ukleinek>
..ooOO(It's in the source files. They are machine-readable using gcc :-)
<linkmauve>
^^'
<ukleinek>
linkmauve: FTR: Don't take that answer as "There is no such list", I don't know.
epoch101 has joined #dri-devel
davispuh has joined #dri-devel
<MrCooper>
linkmauve: the UAPI headers in include/uapi/drm/ ?
fomys_ has joined #dri-devel
<HdkR>
linkmauve: FEX's tools read the uapi headers and a bit of manual glue logic to know which ioctls to care about.
<HdkR>
Since some legacy ioctls don't describe correctly what data structures they use or RW direction.
paulk has quit [Ping timeout: 480 seconds]
epoch101_ has joined #dri-devel
<linkmauve>
What I want is to update strace to handle everything DRM does, because it hasn’t been updated in eons.
<linkmauve>
There is a patch floating around which hasn’t been updated against modern strace, but only for i915 IIRC.
epoch101 has quit [Ping timeout: 480 seconds]
paulk-ter has joined #dri-devel
coldfeet has joined #dri-devel
kts has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
rasterman has quit [Quit: Gettin' stinky!]
<zmike>
austriancoder: any update ?
<austriancoder>
zmike: my day job workday is almost over and my etnaviv hacking time starts after that - so no update yet, but my day has some hours left :)
<mlankhorst>
I'm curious, shouldn't it be both VRAM and sysmem mapped memory count as GPU, and how is swapout handled?
kzd has quit [Ping timeout: 480 seconds]
<airlied>
mlankhorst: no VRAM is to be accounted with dmem not memcg
<airlied>
yeah I have to consider next step how swapout works, first step is just to account allocations at least
Nasina has quit [Remote host closed the connection]
jsa1 has quit [Ping timeout: 480 seconds]
<mlankhorst>
airlied: Yeah, but you might not be able to evict in some cases then..
apinheiro has quit [Quit: Leaving]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
<mlankhorst>
Oh well I'll send a pull request early tomorrow and then rebase, if anything it should be easier. :)
<airlied>
mlankhorst: evicting is also not in the immediate scope, because it's really hard to work out the semantics
<airlied>
we just don't account evictions for now, but the problem I'm facing is on an integrated platform where there is no discrete
nerdopolis has joined #dri-devel
Nasina has joined #dri-devel
guludo has quit [Quit: WeeChat 4.6.1]
Nasina has quit [Ping timeout: 480 seconds]
calico_ has quit [Remote host closed the connection]
calico_ has joined #dri-devel
<airlied>
mlankhorst: I think I'll have to think through swap a bit more, discussion on the list had made me reconsider moving the accounting back into the ttm_tt layer
haaninjo has quit [Quit: Ex-Chat]
Nasina has joined #dri-devel
kzd has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
djbw has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
djbw has joined #dri-devel
tonyk has quit [Ping timeout: 480 seconds]
mairacanal has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
asrivats__ has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
asrivats_ has quit [Read error: Connection reset by peer]
<soreau>
I'm wondering why glsl mix() is not working here. I have gl_FragColor = vec4(mix(tex1.rgb, tex2.rgb, progress), 1.0); and it only shows one texture. If I replace 1.0 with progress, that works, so I know it's getting the correct 'progress' uniform value. If I change 'progress' to 0.5 in the mix function, it does not show both textures. However rendering either one or the other texture without mix works too, so I know the textures are valid pixels
<soreau>
. What might cause mix() to fail in this way?
<soreau>
It doesn't require blending to be enabled as far as I understand
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
djbw_ has joined #dri-devel
djbw has quit [Ping timeout: 480 seconds]
<soreau>
and it works if I replace tex1 and tex2 with vec3's so I apparently it's mixing the same textures somehow..