Akari has quit [Quit: segmentation fault (core dumped)]
edman007 has joined #dri-devel
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #dri-devel
<edman007>
Hey, question, I'm not sure if this is a mesa bug or a me/ffmpeg bug... vaQueryImageFormats() returns a list of VAAPI image formats, however, vaGetImageFormats() doesn't work with all of them (I have a radeonsi video card), is that expected behavior? is there some way I can progromatically tell what formats will actually work?
<edman007>
specifically, mesa 22.3.0 lists 'radeonsi/vcn: enable jpeg decode of yuv444 and yuv400' as a change, and when trying to use yuv444 (presumably because I'm passing it to a SW jpeg encoder and that's the best format) ffmpeg fails to download the image
<edman007>
before 22.3.0 yuv444 was not listed as a supported format
<edman007>
correction, it's VA_FOURCC_Y800 that's causing the problem for me
<edman007>
but seems to be related to some change in 22.3.0
<lina>
fun: apparently a Wayland protocol change to handle natural scrolling properly was proposed *6* years ago, got one round of review... and then just ended up in limbo.
Akari has quit [Quit: segmentation fault (core dumped)]
kts has joined #dri-devel
junaid has joined #dri-devel
fab has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
kzd has quit [Quit: kzd]
kzd has joined #dri-devel
heat has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
rasterman has joined #dri-devel
Company has quit [Quit: Leaving]
danvet has joined #dri-devel
kzd has quit [Quit: kzd]
heat has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
heat has joined #dri-devel
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
vliaskov_ has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
xroumegue has joined #dri-devel
pcercuei has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
ice9 has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<daniels>
hmm, looks like it just fell through the cracks and v2 didn’t get applied
<daniels>
mail ftl
<daniels>
lina: MRs welcome!
<Lynne>
it feels like every time you search a field in the vulkan spec you come across a large enough limitation to prevent you from using it
<Lynne>
and then you say "okay, fine, here, I'll do it and it'll be awful", and it sort of is, but you decide to build upon your hack, back to step 1
fab has quit [Quit: fab]
fab has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
fab_ has joined #dri-devel
fab_ is now known as Guest1328
Guest1328 has quit []
<linkmauve>
jenatali, do you build a libGLESv2 that Windows programs can use nowadays?
fab has quit [Ping timeout: 480 seconds]
<linkmauve>
Or is it recommended that GLES programs use GL_ARB_ES2_compatibility in opengl32.dll instead?
<HdkR>
ooo, good idea. Finally ES on Windows
<MrCooper>
CounterPillow: if mpv works fine with VRR, make an MR to drop it from the denylist?
<CounterPillow>
already done
Haaninjo has joined #dri-devel
gouchi has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
JohnnyonFlame has joined #dri-devel
<jenatali>
linkmauve: We can, but apps have to bundle it, there's no system GLESv2.dll, but apps can use Mesa as an alternative to ANGLE
Haaninjo has quit [Quit: Ex-Chat]
apinheiro has joined #dri-devel
<linkmauve>
jenatali, what is the process for a given app to bundle it?
<linkmauve>
Wouldn’t it make sense to ship said GLESv2.dll with the system instead?
<jenatali>
Even if we did, it'd only be with new versions of Win11 meaning apps couldn't rely on it being there. Since it's OSS why not bundle it anyway at that point?
<jenatali>
You just have to build or download it, link against the .lib files, and then ship the .DLL files with your app
<linkmauve>
And assume there to be a d3d12 driver on the host right?
<linkmauve>
This is about 0ad btw.
<jenatali>
Yeah, which is all but guaranteed these days
<jenatali>
Ah was about to ask, why the interest
<linkmauve>
They still target super old Windows versions, the kind unsupported for decades, so it might not be viable just yet.
<linkmauve>
But any decade now!
<jenatali>
Heh
<jenatali>
Do they use ES? I'd assume they use desktop GL
<linkmauve>
Nowadays they can use either.
<jenatali>
Is there a reason to prefer ES?
<linkmauve>
They recently dropped their fixed pipeline GL 1.x, but still support ARB shaders. :D
gouchi has quit [Remote host closed the connection]
<jenatali>
... wow
<linkmauve>
And since a few days, also Vulkan.
<jenatali>
Yeah I saw those headlines
vliaskov_ has joined #dri-devel
<jenatali>
Anyways, libGLESv2.dll support in Mesa on Windows has been there since before I started working with it, but I added libEGL.dll support a while back
<linkmauve>
Oh, I didn’t know!
vliaskov_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
sarnex has quit [Quit: Quit]
freemint has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
sarnex has joined #dri-devel
freemint has joined #dri-devel
junaid has joined #dri-devel
JohnnyonFlame has joined #dri-devel
kzd has joined #dri-devel
gouchi has joined #dri-devel
kts has quit [Quit: Leaving]
junaid has quit [Ping timeout: 480 seconds]
thaytan has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
junaid has joined #dri-devel
Company has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
srslypascal is now known as Guest1352
srslypascal has joined #dri-devel
srslypascal is now known as Guest1354
srslypascal has joined #dri-devel
srslypascal is now known as Guest1355
srslypascal has joined #dri-devel
Guest1352 has quit [Ping timeout: 480 seconds]
Guest1354 has quit [Ping timeout: 480 seconds]
freemint has quit [Remote host closed the connection]
freemint has joined #dri-devel
Guest1355 has quit [Ping timeout: 480 seconds]
freemint has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
fxkamd has quit []
fpuellen has joined #dri-devel
fpuellen has quit []
fxkamd has joined #dri-devel
fxkamd has quit []
Leopold has quit [Remote host closed the connection]
<HdkR>
I just learned about malloc perturb a couple days ago, very neat
Duke`` has quit [Ping timeout: 480 seconds]
<HdkR>
Sadly jemalloc doesn't support it :(
Danct12 has joined #dri-devel
dviola has quit [Quit: WeeChat 3.7.1]
dviola has joined #dri-devel
<LaserEyess>
question about HDMI 2.1, I'm well aware of the current issues with implementing it, but does amdgpu advertise HDMI 2.1 features in any way to monitors/TVs?
freemint has joined #dri-devel
<LaserEyess>
because right now, I'm using an HDMI TV to display 10bit 4k120, with VRR enabled
<LaserEyess>
and, well, how am I doing that? VRR is confirmed working via the TV's HUD, and 10bit is confirmed via drm format
<HdkR>
HDMI VRR doesn't need HDMI 2.1 to be exposed. It shows up as an additional EDID block that works on 2.0
<HdkR>
I have an HDMI 2.0 television with VRR supported as an example. Playstation 5 refuses to use VRR on it because it doesn't support 2.1 :P
<LaserEyess>
I thought explicit support was needed from the TV for AMD's freesync-on-2.0 (assuming that's what this is)
<LaserEyess>
maybe mine has that, dunno
<HdkR>
As for 4k120 10bit...DSC maybe?
<LaserEyess>
chroma subsampling, as amdgpu likes to do...
<HdkR>
I don't think you can hit that with 420 encoding according to wikipedia
<LaserEyess>
does HDMI 2.0 have DSC even?
<HdkR>
Not part of spec anyway
<HdkR>
It's either DSC or hitting HDMI 2.1 speeds. Would need to check your logs how that is working :)
<LaserEyess>
well, I'm not complaining I guess, I just hope this doesn't "regress" at some point
<HdkR>
Well it's running at 4k120, as for how it is getting there, dunno
Leopold has quit []
Leopold has joined #dri-devel
<LaserEyess>
luck
apinheiro has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
My TV does 4k120 over HDMI too, and I checked with some test pictures that it is using chroma subsampling to achieve that. Can't say I notice it in normal usage though
<zamundaaa[m]>
Fyi the color depth being 10 bit on the buffer does not mean it's actually transmitting that over the wire. It's only a maximum
<HdkR>
yea, 8-bit over the wire works with subsample
<HdkR>
I think you only get that information in the kernel logs though?
<HdkR>
Or I just don't know where to find it I guess :)
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
<alyssa>
madvise is really hurting performance, oy vey
<alyssa>
like 58fps -> 68fps from ripping out the madvise calls in mesa...
<alyssa>
I have been told not to do that
<alyssa>
but the numbers are compelling, yikes.
<alyssa>
drawoverhead test I was looking at doubled
<HdkR>
a bunch of DONT_NEED?
<alyssa>
(those fps are in dolphin)
<alyssa>
HdkR: there are two issues
<alyssa>
well
<alyssa>
three issues!
<alyssa>
1. lots of madvise ioctls, which makes the BO cache a lot more expensive than it needs to be
<alyssa>
2. due to a kernel bug (I don't know if this was fixed upstream...), we can't DONT_NEED a mapped BO, so we need to munmap() in the BO cache put and then mmap() again in the BO cache get, which means 2x the syscalls as madvise normally needs
<alyssa>
3. the constant munmap/mmap means we're thrashing the page tables terribly and spend piles of CPU time in the kernel faulting in pages
<HdkR>
Probably also expending the zero'd physical page pool faster than the kernel can rebuild it :P
iive has quit [Quit: They came for me...]
<alyssa>
all of this is for the happy path when the shrinker isn't actually used
<alyssa>
when the shrinker IS needed, you're in for a world of pain and users have reported bug where everything nominally works but the shrinker was so terrible they thought it was broken
<alyssa>
(and also we've had piles of shrinker bugs but that's a different issue ..)
<alyssa>
and jekstrand commented that madvise() isn't possible with vulkan anyway
<alyssa>
makes me wonder if users would be better off with a courteous BO cache than with the blunt GL hammer that is madv
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<HdkR>
Still curious if the tradeoff comes from applications that orphan buffers with glBufferData versus them doing their own subrange buffer management
<LaserEyess>
zamundaaa[m]: if you're using AMD, it's likely the long standing bug where it will default to YUV420 if that's available with HDMI
<LaserEyess>
so yeah I guess I can't really confirm that 4k120 444 is possible
<TMM>
I have a weird problem which involves amdgpu but I'm not entirely sure what to make of it and where to even file a bug. The problem is as follows: When I run a rocm workload (stable diffusion) on my 6950XT that has GDM running on X11 the card resets (green screen) and I see "*ERROR* Error waiting for DMUB idle" in the kernel log, then it tries to do a reset which fails because it can't pause GDM and then the box reboots. I can run that same workload on my 6900XT
<TMM>
in the same box without an issue in this configuration. When I switch GDM to use Wayland the problem disappears. When I login to a wayland session there is no problem either. When I login to an X11 gnome session... ALSO NO PROBLEM. It appears to be only GDM and only on X11.
freemint has quit [Ping timeout: 480 seconds]
<TMM>
I feel like probably this should be reported but where? Is this an X bug? GDM? amdgpu? mesa? rocm?
<TMM>
Also in no other configuration do I even get a GPU reset
<TMM>
It works... fine
<TMM>
It seems I don't even get a problem with GDM running in X11 when it engages DPMS (or whatever the modern equivalent is) that turns off the screen