Guest2980 has quit [Read error: Connection reset by peer]
<rg3igalia>
np!
kzd has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
kts has joined #dri-devel
kasper93 has joined #dri-devel
dsimic is now known as Guest2983
dsimic has joined #dri-devel
Guest2983 has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
MrCooper_ has joined #dri-devel
alih has joined #dri-devel
MrCooper is now known as Guest2984
MrCooper_ is now known as MrCooper
yyds has joined #dri-devel
Guest2984 has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
testaccount has joined #dri-devel
testaccount has quit []
<shadeslayer>
Hi
<shadeslayer>
I'm starting to implement bfloat16 support in mesa for opencl, and I wanted some input on the NIR side of things, I was wondering if it would be better to introduce a new bf16 nir type, or just add a encoding field to the vtn_type and then emit the relevant conversion ops by passing the src/dst encoding parameters to nir_type_conversion_op
<shadeslayer>
that way we can reuse nir_type_float16 for bf16
fab has joined #dri-devel
jenatali has joined #dri-devel
mbrost has joined #dri-devel
<karolherbst>
shadeslayer: inherently NIR is a typeless IR, so for alu instructions the instruction itself defines the type. I don't know what operation are all defined over bfloat16, but maybe it's good enough to just add bf* nir opcodes where needed?
testaccount has joined #dri-devel
<cwabbott>
on intel and AMD, do GPU resets reset the GPU timestamp?
<cwabbott>
I'm trying to figure out whether I need to make the timestamp stable across reset/DEVICE_LOST for VK_KHR_calibrated_timestamps
testaccount has quit []
<cwabbott>
I would assume it doesn't have to be, because you would only ever notice the discontinuity when reading the device timestamp on the CPU and the non-monotonic value you'd get wouldn't be useful for anything
testaccount has joined #dri-devel
yyds has quit [Remote host closed the connection]
testaccount has quit []
testaccount has joined #dri-devel
jsa has joined #dri-devel
Lucretia has quit [Remote host closed the connection]
testaccount has quit []
<cmarcelo>
shadeslayer: we want have it represented in glsl_type, so encoding field won't be needed. for NIR I tend to agree with what karol suggested.
<cmarcelo>
karolherbst: that said, we might want to expand the NIR inferred type enum to include those as well.
<karolherbst>
yeah.. probably
<karolherbst>
could be it's own bit_size
<karolherbst>
though nir_alu_type is already cursed enough tbh
<cmarcelo>
karolherbst: in LNL we have a BFLOAT16 and a BFLOAT8
<karolherbst>
somebody might also get the idea adding 4 bit floats...
<karolherbst>
could have `nir_type_bfloat = 256`
<karolherbst>
but uhhh
<karolherbst>
that might require some bitfields to get expanded to 16 bits
<karolherbst>
not sure if it's ever stored anywhere
<karolherbst>
mhh or bfloat is 130 or so
mbrost_ has joined #dri-devel
Lucretia has joined #dri-devel
testaccount has joined #dri-devel
testaccount has quit []
mbrost has quit [Ping timeout: 480 seconds]
testaccount has joined #dri-devel
<cmarcelo>
karolherbst: what you mean by 130?
<karolherbst>
the enums value
<cmarcelo>
which enum?
<karolherbst>
nir_alu_type
testaccount has quit []
<cmarcelo>
I'm not much worried about the encoding in alu_type, we can fix/expand things if needed.
<JEEB>
so what was the correct venue to report issues with DRM modules such as `vmw_gfx`? I noticed their rewrite under the moniker of fixing something that was merged in 6.10.4 broke graphics for me, and now I've done enough analysis that I know that the issue is due to the DRM client requesting A8R8G8B8 and the scanout surface being X8R8G8B8, and there being a strict check that thus fails.
avolmat has joined #dri-devel
Lucretia has quit []
<DemiMarie>
How bad is forcing the use of rusticl and blocking the use of preemptable queues on AMD GPUs?
<karolherbst>
rusticl should probably use preemptable queues or whatever rocm is doing
<karolherbst>
it's just a bit annoying to do afaik
<DemiMarie>
The problem is that preemptable queues seem to cause AMD firmware crashes, and I have to assume those are exploitable.
Lucretia has joined #dri-devel
<karolherbst>
fun
<DemiMarie>
TinyGrad resorted to disabling preemption to work around the issue.
ellyq has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
mbrost has joined #dri-devel
ellyq__ has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
ellyq_ has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
ellyq_ has joined #dri-devel
feaneron has joined #dri-devel
ellyq___ has joined #dri-devel
ellyq has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
ellyq has joined #dri-devel
ellyq__ has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
ellyq_ has quit [Ping timeout: 480 seconds]
ellyq_ has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
ellyq___ has quit [Ping timeout: 480 seconds]
ellyq has quit [Ping timeout: 480 seconds]
docmax has quit [Remote host closed the connection]
coldfeet has joined #dri-devel
docmax has joined #dri-devel
avolmat has quit [Remote host closed the connection]
ellyq has joined #dri-devel
lyudess has quit []
Lyude has joined #dri-devel
ellyq_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
agd5f_ has quit []
agd5f has joined #dri-devel
<DemiMarie>
When doing media processing with a GPU, how much parsing happens in the GPU firmware? I'm trying to assess the risk.
<agd5f>
DemiMarie, The problem was that some of the user queue parameters weren't properly validated (e.g., if you specified a bogus GPU address for one of the user queue parameters, the hardware would segfault). That has since been fixed in the driver.
<DemiMarie>
agd5f: I see. Was the fix backported to stable?
<agd5f>
not yet
LeviYun has quit [Ping timeout: 480 seconds]
pzanoni has quit [Remote host closed the connection]
pzanoni has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<Ermine>
Something is wrong with eglgears_wayland client decorations. When you hover over it, gears stop rotating, and in general it's sluggish and sometimes one can't even move the window
<DemiMarie>
Thanks for the fix agd5f.
mbrost has joined #dri-devel
glennk has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
<soreau>
Ermine: where did you happen upon the source?
<Ermine>
sorry, I don't understand what you mean
<llyyr>
Ermine: it seems very broken on the tagged release in general
<tjmercier>
Hi Folks, https://cgit.freedesktop.org/drm/drm-misc/ is giving me 504s, and git fetches from anongit.freedesktop.org/drm/drm-misc are also failing for me. Looks like a server is down; anyone here have powers to fix?
<airlied>
tjmercier: drm-misc is no longer hosted there btw
avolmat has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
Lucretia has joined #dri-devel
Guest2964 has quit [Remote host closed the connection]
iive has joined #dri-devel
soreau has quit [Ping timeout: 480 seconds]
soreau has joined #dri-devel
LeviYun has joined #dri-devel
vliaskov__ has quit [Read error: Connection reset by peer]
vliaskov has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
apinheiro has quit [Quit: Leaving]
edolnx has joined #dri-devel
LeviYun has joined #dri-devel
edolnx_ has quit [Ping timeout: 480 seconds]
phire_ has joined #dri-devel
phire is now known as Guest3014
phire_ is now known as phire
Haaninjo has quit [Quit: Ex-Chat]
Guest3014 has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
rossy has quit [Read error: Network is unreachable]
rossy has joined #dri-devel
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
LeviYun has joined #dri-devel
balrog has joined #dri-devel
halves has quit [Quit: Ping timeout (120 seconds)]
cascardo has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
cascardo has joined #dri-devel
balrog_ has quit [Read error: Connection reset by peer]
halves has joined #dri-devel
agd5f has quit [Remote host closed the connection]
guludo has quit [Quit: WeeChat 4.3.6]
anujp has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
halves has quit [Quit: Ping timeout (120 seconds)]
halves has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
anarsoul has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
danylo has quit [Quit: Ping timeout (120 seconds)]
danylo has joined #dri-devel
<DemiMarie>
How bad is it to send the results of hardware decoding back to the CPU instead of keeping them in a dmabuf? Is it sufficiently bad that Qubes OS just needs good cross-VM dmabuf support?
anujp has joined #dri-devel
danylo has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
Company has joined #dri-devel
danylo has joined #dri-devel
LeviYun has joined #dri-devel
karolherbst_ has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
karolherbst_ has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
snoonet has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Lucretia has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
Depends on how much headroom you have. On low end laptops, definitely can make it feel more laggy under load. On desktops, nobody cares even if you used all SW decoding