ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
amarsh04 has quit []
mszyprow has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
u-amarsh04 has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
lsntvt_ has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
vedm_ has joined #dri-devel
LeviYun has joined #dri-devel
vedm has quit [Ping timeout: 480 seconds]
zzyiwei has quit []
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
ity1 has joined #dri-devel
ity has quit [Remote host closed the connection]
<luc>
does anyone have any idea what those dri2_format_mappings in dri2_format_table (in dri_helpers.c:424) are based on? i wonder e.g. DRM_FORMAT_ARGB8888 maps to PIPE_FORMAT_BGRA8888_UNORM rather than PIPE_FORMAT_ARGB8888_UNORM
Company has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
feaneron has joined #dri-devel
soze has quit [Ping timeout: 480 seconds]
alane has quit []
alane has joined #dri-devel
Company has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Company has quit []
LeviYun has joined #dri-devel
sguddati has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
zzyiwei has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
sguddati has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
sguddati has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
soze has joined #dri-devel
soze has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
dsimic is now known as Guest11842
dsimic has joined #dri-devel
Guest11842 has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
zsoltiv__ has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
krushia has quit [Ping timeout: 480 seconds]
benjaminl has quit [Ping timeout: 480 seconds]
MrCooper__ has joined #dri-devel
OftenTimeConsuming has quit [Quit: OftenTimeConsuming]
OftenTimeConsuming has joined #dri-devel
OftenTimeConsuming has quit []
OftenTimeConsuming has joined #dri-devel
MrCooper_ has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
<llyyr>
luc: DRM_FORMAT describes the channel order while PIPE_FORMAT describes the memory layout
LeviYun has joined #dri-devel
dolphin has joined #dri-devel
<llyyr>
because of little endian, ARGB is stored as BGRA in memory. or that's my understanding of it is anyway
gnuiyl has quit [Remote host closed the connection]
gnuiyl has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
sally has quit [Read error: Connection reset by peer]
sally has joined #dri-devel
Duke`` has joined #dri-devel
konstantin_ has joined #dri-devel
konstantin is now known as Guest11845
konstantin_ is now known as konstantin
Guest11845 has quit [Read error: Connection reset by peer]
MrCooper_ has joined #dri-devel
fab has joined #dri-devel
MrCooper__ has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
glennk has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
kts has joined #dri-devel
<luc>
llyyr: According to dri2_format_table, does it mean that there is no such channel order like BGRA in practice？
parthiban has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
jsa1 has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
blaztinn has quit [Remote host closed the connection]
blaztinn has joined #dri-devel
u-amarsh04 has quit []
amarsh04 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
sima has joined #dri-devel
<pq>
llyyr, do you mean that DRM_FORMAT_* does not describe memory layout? How so?
tzimmermann has joined #dri-devel
fab has quit [Quit: fab]
soze has joined #dri-devel
<llyyr>
pq: the drm format describes the order of the components in a native type on a little endian system, not the exact byte order in the memory
<llyyr>
DRM_FORMAT_ARGB8888 is stored as B, G, R, A in memory. PIPE_FORMAT describes the memory order instead, so it needs to be reversed
<llyyr>
or well that's my understanding of it at least, I've seen quite a few comments talk about it in mesa codebase
sguddati has quit [Ping timeout: 480 seconds]
<pq>
llyyr, yes, DRM_FORMAT describes the meaning of bits in a word. Hard to describe non-8-bit formats otherwise. How is that not a memory layout though?
soze has quit [Ping timeout: 480 seconds]
<pq>
it's not "on a little-endian system" but the format itself is little-endian regardless of the system
<pq>
which means the byte-by-byte memory content of a format is the same on both little-endian and big-endian systems.
<llyyr>
yes, the PIPE_FORMAT describes the actual byte order in memory while DRM_FORMAT is bit placement inside a native type
warpme has joined #dri-devel
<llyyr>
from what I understand, the cpu endianess will only affect how the values are interpreted, so the PIPE_FORMAT needs to be reversed
<llyyr>
perhaps someone else could explain it better
fab has joined #dri-devel
<sima>
llyyr, drm_format is supposed to be always little endian, which means it really should describe a format irrespective of that
<sima>
reality is that too few people care about big endian, so it's just broken everywhere
vliaskov has joined #dri-devel
<pq>
llyyr, the "reversed" only works with 8/16/32-bpc formats, because otherwise re-ordering channels cannot express the difference between little- and big-endian words. E.g. 1010102 formats or RGB565 cannot be converted by channel re-ordering.
<sima>
yeah there's a separate endianess bit in DRM_FORMAT_
mehdi-djait3397165695212282475 has joined #dri-devel
<pq>
llyyr, GL "solved" the problem using both ways: GL_UNSIGNED_BYTE vs. GL_UNSIGNED_INT.
<pq>
DRM_FORMAT_* endianess ignoring the CPU endianess means that words need to be byte-swapped to CPU-endian before word-wide bit ops can be used to extract individual channels.
<pq>
jfalempe, and in the old days it tended to be broken, every component in the stack tended to just byte-swap until "it looked fine to me with this combination of sw&hw"? :-)
<pq>
+because
<luc>
sima: "reality is that too few people care about big endian, so it's just broken everywhere", is that why DRM_FORMAT_BGRA8888 is not listed in dri2_format_table (dri_helpers.c:424) in mesa codebase?
<jfalempe>
yes adding a byte swap is the lazy fix to make it work on big endian.
phasta has joined #dri-devel
varunrmallya has joined #dri-devel
<sima>
luc, no idea, but essentially what pq said that we just applied byte-swapping until it looked correct and called it done
<sima>
but yeah ADDFB2 and drm_format stuff is most likely just busted to no end on big endian
<sima>
we've tried to internally in the kernel at least map ADDFB correctly to DRM_FORMAT taking endianess into account
<sima>
but then the virtual drivers I think get it all wrong
<sima>
it's a mess
<sima>
jfalempe, yeah my take is that big endian will just die out eventually, and until then we can just apply more hacks to keep it afloat
<sima>
but all pragmatism aside, I think DRM_FORMAT should be endian independent like PIPE_FORMAT
<sima>
for a very weak version of "should" unfortunately
<sima>
and yeah realistically I guess for big endian you get bgrax8888 and that's it, everything else is too hard
<jfalempe>
But yeah, even with that some apps have still color issues. (like when browsing with firefox, some images are inverted, depending on the source format).
<MrCooper>
luc: the bigger issue in dri2_format_table is that DRM_FORMAT_*8888 are endianness-independent (as discussed above), whereas __DRI_IMAGE_FORMAT_*8888 & PIPE_FORMAT_*8888_UNORM are endianness-dependent, which means all 8888 entries in the table are wrong on big endian hosts
<sima>
jfalempe, I guess kmap_local is fully panic safe, including nmi and all that?
<sima>
otherwise I guess we'd need a kmap_try_nmi_safe or so, which bails out if it's not possible
<jfalempe>
sima: Yes, at least it claims to be ;)
<MrCooper>
luc: the users of this table should directly map between DRM_FORMAT_*8888 & PIPE_FORMAT_*8*8*8*8_UNORM (which are also endianness-independent) instead
<sima>
jfalempe, hm where did you find that?
<sima>
like without HIGHMEM they're obviously safe
<sima>
so in reality we really don't care much if they're not I guess
<jfalempe>
* Can be invoked from any context, including interrupts.
<sima>
jfalempe, interrupts isn't enough
<sima>
nmi is _very_ nasty
<sima>
jfalempe, only other comment I have is that augmenting the kerneldoc for drm_scanout_buffer.pages that it cannot be allocated from @get_scanout_buffer would be good
<sima>
to make it clear that drivers must prepare that array as part of their ->prepare_framebuffer callback as part of normal atomic flow
<sima>
jfalempe, for the kmap_local_page I guess we could #ifndef HIGHMEM that for now, to get this going
<sima>
since it's a bit an implementation detail
<sima>
but it's something I think we should chase with printk people
<sima>
and -rt folks in general, they know how this all works really well
<sima>
maybe in #linux-rt
<sima>
I think just failing if the mapping doesn't exist yet is ok
<jfalempe>
sima: ok, I can add the comment for page allocation. but usually the framebuffer is allocated, so it should have an array of pages somewhere.
<sima>
jfalempe, these details aside I think this looks good from design pov
<sima>
jfalempe, yeah but not all drivers have that, at least i915-gem didn't
<sima>
but I think drm shmem helpers and ttm both have that, so should be ok
<sima>
just feels like something worth documenting, since panic context is so tricky
<jfalempe>
ok thanks, yes that's primary for virtio-gpu.
<sima>
so just add a paragraph there explaining the constraint and pointing at the prepare_framebuffer hook and what should be done there to make sure you do have a pages array that you can just assign
lsntvt has joined #dri-devel
lsntvt_ has joined #dri-devel
<sima>
jfalempe, I've asked over on #linux-rt, we might need a _try version of this which can fail in nmi if we're unlucky
<MrCooper>
pq: doesn't matter, the point is it doesn't depend on endianness
<sima>
jfalempe, for testing we might want to allow NULL entries, so that you can test the failure path in your kunit test
<sima>
so maybe an additiona if (!page) return NULL; in there
varunrmallya has quit []
<jfalempe>
ok, that's true I assume the page array has the required size, and that all pages are not NULL.
soze has joined #dri-devel
<pq>
sima, that's what DRM_FORMAT already is - you sounded like you wished it was something else that what it is today.
<pq>
*than
krei-se- has joined #dri-devel
lynxeye has joined #dri-devel
varunrmallya has joined #dri-devel
krei-se has quit [Ping timeout: 480 seconds]
soze has quit [Ping timeout: 480 seconds]
soze has joined #dri-devel
<MrCooper>
pq: DRM formats are actually defined independently from endianness, the "little endian" language is a bit confusing
kts has joined #dri-devel
mvlad has joined #dri-devel
apinheiro has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
vup has quit [Quit: vup]
kaiwenjon_ has joined #dri-devel
kaiwenjon has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
vup has joined #dri-devel
aravind has joined #dri-devel
Piraty has quit [Remote host closed the connection]
Piraty has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
<mlankhorst>
sima: did you write that page of notes yet? :)
fantom has joined #dri-devel
che_ has quit [Remote host closed the connection]
<sima>
mlankhorst, it's here on a piece of paper
<sima>
since I didn't hear anything I didn't do more, plus still backlogged on m-l traffic
<sima>
mlankhorst, mripard should I transcribe it as a fairly unstructured mess as a reply to the latest dmem rfc?
<sima>
it wasn't clear to me what I should be doing with it
<mlankhorst>
I think it makes sense to put it on dri-devel and with the mm ml as well
<mlankhorst>
Perhaps cgroup too, so we can continue the discussion
<mlankhorst>
What's also complicating things is eviction from VRAM will likely charge the cgroup evicting, instead of the cgroup allocating
jsa1 has joined #dri-devel
amarsh04 has quit []
<sima>
mlankhorst, yeah need to sort that out
amarsh04 has joined #dri-devel
<sima>
also evicting from vram means you need a memcg aware shrinker for system memory
<sima>
or it just all falls apart in very unfunny ways
Company has joined #dri-devel
sguddati has joined #dri-devel
<mlankhorst>
Yeah exactly
Fijxu has quit [Quit: XD!!]
Fijxu has joined #dri-devel
varunrmallya has quit []
mattst88_ has joined #dri-devel
enzuru has quit [Remote host closed the connection]
enzuru has joined #dri-devel
varunrmallya has joined #dri-devel
mattst88 has quit [Read error: Connection reset by peer]
varunrmallya has quit []
vliaskov has quit [Read error: Connection reset by peer]
varunrmallya has joined #dri-devel
warpme has quit []
dolphin has quit [Quit: Leaving]
<pq>
MrCooper, yes, that's exactly what I'm saying.
<pq>
MrCooper, what I'm confused about is what sima said: "but all pragmatism aside, I think DRM_FORMAT should be endian independent like PIPE_FORMAT". Should be - so it isn't yet?
<pq>
as I think DRM_FORMAT are endian independent already, "endian independent" must mean something else
guludo has joined #dri-devel
warpme has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
nashpa has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
warpme has quit []
feaneron has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
nerdopolis has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
pcercuei has quit [Quit: brb]
rgallaispou has joined #dri-devel
CME_ has joined #dri-devel
warpme has quit []
varunrmallya has quit []
CME has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
<MrCooper>
pq: "should be" can also mean "I'm pretty sure are", which I suspect was meant there
krushia has joined #dri-devel
<MrCooper>
sima: FYI, there are endianness-dependant variants of 8888 PIPE_FORMATs (and the Mesa table which started this discussion currently uses those, which is a problem)
mehdi-djait3397165695212282475 has joined #dri-devel
epoch101 has joined #dri-devel
<sima>
MrCooper, pq yeah was a bit a mix of what should be and what is and what is the pragmatic approach
<sima>
MrCooper, I think we have the same issue with DRM_FORMAT, where there's essentially dupes&aliases due to the endian flag
<sima>
plus that flag doesn't make sense for a lot of formats
<sima>
and even less if you throw in modifiers
<sima>
I think defacto the endian flag has only a meaning for the 8888 formats, and maybe for the 16bit ones too
amarsh04 has quit []
rgallaispou has quit [Read error: Connection reset by peer]
kzd has joined #dri-devel
rgallaispou has joined #dri-devel
amarsh04 has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
warpme has quit []
epoch101 has joined #dri-devel
<eric_engestrom>
jljusten: good catch on the docs, they should have been updated when the bug was known but not fixed; I just had a look though and the fix for `backport-to:` was actually pretty simple, it's only the parser that needs to be updated: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34117
<eric_engestrom>
having multiple `fixes:` tags has a similar bug though, same effect where only the first one gets parsed and the rest is ignored, but for that one it's not just the parser that needs to be updated: the way we store that information only has a single field, not a list, and making that change in a backport-able way is going to be interesting
<eric_engestrom>
I'm really hoping the things that's currently sinking most of my time will be over by next week, and I can have some free time to look into this (before I forget about it again ^^)
<eric_engestrom>
actually, for multiple `fixes:`, does it mean "needs to be backported to any branch that has any of these commits", or "... that has all of these commits"?
<eric_engestrom>
(any vs all, to be clear)
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
edolnx has joined #dri-devel
haaninjo has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
<MrCooper>
sima: my impression is DRM_FORMAT_BIG_ENDIAN was an afterthought, I doubt anyone really thought it through
rgallaispou has joined #dri-devel
<sima>
MrCooper, we might just have copy-pasted it from some other fourcc.h with no thought actually
<sima>
or yeah an "oops, maybe we should pretend to think about big endian" moment, but yeah not really more
mszyprow has quit [Ping timeout: 480 seconds]
<eric_engestrom>
oh btw Venemo you were asking if gitlab had a way to automatically delete old pipelines, it turns out there is: go to https://gitlab.freedesktop.org/$USERNAME/mesa/-/settings/ci_cd#js-general-pipeline-settings (replacing `$USERNAME` with your username) and set the retention you want in "Automatic pipeline cleanup"
<eric_engestrom>
and I have a script (https://tmp.engestrom.ch/fdo-gitlab-clean-old-pipelines.py) that I use to automatically delete pipelines for branches that no longer exist (eg. merged and auto-deleted, or manually deleted), or old pipelines when another one exists for a newer version of the same branch; it's tailored to my usage, make sure you change it the way you want to use the ci :)
<eric_engestrom>
(posting it here instead of DM because others might be interested in either of these)
<Venemo>
thank you eric_engestrom I just set the automatic cleanup to 3 months, let's hope this helps our infra save some space
<Lynne>
zzoon: av1 vulkan decode on anv got broken recently
<Lynne>
keyframes decode fine, but inter frames decode to garbage
<mlankhorst>
sima: How should we pin VRAM btw, should that be done through cgroups?
lynxeye has quit [Quit: Leaving.]
coldfeet has quit [Quit: Lost terminal]
mbrost has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
varunrmallya has joined #dri-devel
Duke`` has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<yrlf>
hi! is there way to force a GPU reset on amdgpu?
<yrlf>
I'm currently testing some changes to sway's handling of those and it would be really useful to manually trigger one so I don't have to wait for the unlikely case that one occurs
<pixelcluster>
read (!) from /sys/kernel/debug/dri/<pci id>/amdgpu_gpu_recover
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
mehdi-djait3397165695212282475 has quit []
tzimmermann has quit [Quit: Leaving]
kts has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
<yrlf>
pixelcluster: that doesn't appear to trigger glGetGraphicsResetStatusKHR(); is there another way to trigger such a GPU reset or do I need to fake this in order to test it?
<pixelcluster>
that's weird
<pixelcluster>
I'm not aware of any other method to trigger a gpu reset other than writing deliberately invalid apps
<Company>
I know that it works (unless it broke at some point?) because I've accidentally crashed Mutter a few times when using cat(1) too liberally
mbrost_ has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
iive has joined #dri-devel
<yrlf>
it definitely does something, since I see a visible modeset and the brightness gets set back to the default
<yrlf>
I recently had an actual gpu reset due to some hang and in that case glGetGraphicsResetStatusKHR() did report that the context was lost
<yrlf>
i also didn't find any way in opengl to fake loss of a context, so I'll probably just fake it completely for testing and hope real context loss cases behave similarly
epoch101_ has joined #dri-devel
epoch101 has quit [Read error: Connection reset by peer]
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
cyrinux9 has quit []
cyrinux9 has joined #dri-devel
<pac85>
is that a dedicated or mobile amd gpu?
<pac85>
Perhaps on mobile chips only in flight contexts are marked as invalid since you don't lose "vram"?
phasta has quit [Quit: Leaving]
unerlige has joined #dri-devel
warpme has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
lsntvt_ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
varunrmallya has quit [Ping timeout: 480 seconds]
<Company>
yrlf: maybe llvmpipe allows faking it somehow?
varunrmallya has joined #dri-devel
mszyprow has joined #dri-devel
tanty has quit [Quit: Ciao!]
mvlad has quit [Remote host closed the connection]