ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Haaninjo has quit [Quit: Ex-Chat]
theanorak_ has quit [Quit: WeeChat 4.1.2]
Company has joined #dri-devel
<mareko>
Mesa has a tiny x86 assembler, so in theory it could do NIR -> x86
<mareko>
the GL select mode uses a geometry shader now, so draw is only used by rasterpos and feedback mode, and rasterpos is a single shader thread that could run quickly on x86
<airlied>
we have aarch64 users though, so I'm not sure we'd care for x86 only answers
<airlied>
since we have llvm for x86 anways
<airlied>
unless we start adding NIR cpu backends :-P
<zmike>
I can't imagine such a thing would ever work
<airlied>
zmike: you don't have to imagine it, just fund it :-P
<zmike>
I'll put in $20 that says it doesn't work
<karolherbst>
zmike: why wouldn't it tho?
<karolherbst>
shit... now I gonna have to do it, no?
<zmike>
I don't know why you'd bother, there's no way you'd ever get it to even run glxgears
glennk has quit [Ping timeout: 480 seconds]
<karolherbst>
your taunts do nothing
<karolherbst>
🙃
<zmike>
just stating facts
<zmike>
you're too busy with rusticl anyway
<karolherbst>
true
<Sachiel>
software rasterizer in OpenCL C
<karolherbst>
no
<karolherbst>
somehow just compile mesa for CL C
<airlied>
I wonder which I could make happen first, this 18 hours cts run or a nir exec :-P
<karolherbst>
my best are on nir exec
<karolherbst>
*bets
<zmike>
airlied no.
<zmike>
focus.
<karolherbst>
just do it airlied
<zmike>
just think of all the useful things you could be doing instead
<zmike>
like
<karolherbst>
supporting function calls in aco
<karolherbst>
zmike: oh btw, have any ideas to fix the use-after-free? I wouldn't even mind fixing it myself
<airlied>
I'm trialing introducing coffee so I do have to restrain major impluses to write stuff
<mareko>
coffee is a hell of a drug
<zmike>
karolherbst: yes, in short the zink_batch_state structs need to become screen-owned such that, upon a context being created or destroyed, they are cached/retrieved under lock from the screen instead of being destroyed
<karolherbst>
ahh
<zmike>
I was planning to do it tomorrow or friday since I have fewer calls, but feel free if you want to
<karolherbst>
let me give it a shot tomorrow and I'll tell you if I get annoyed or give up
<zmike>
ok
<zmike>
the gist is you need to still clear all the batch states on ctx destroy but then not free them, and then on ctx/batch_state creation you need to reinit the cached batch states so they "belong" to the new ctx
<karolherbst>
yeah...
<zmike>
very little new code, just some moving
flynnjiang has joined #dri-devel
<mareko>
or rusticl could be enabled for softpipe
<karolherbst>
pain
kzd has quit [Quit: kzd]
<zmike>
it would have to have a compelling name to justify the work
<zmike>
and surely no one is that clever
iive has quit [Quit: They came for me...]
<jenatali>
Softicl?
<mareko>
vulkan on softpipe could be called cloggedpipe
kzd has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
zmike: congrats on your chairmanship :)
<karolherbst>
what did mike get himself into this time?
<HdkR>
Something like a Herman Miller or more a recliner situation? :P
<airlied>
khr gl/gles chair
<karolherbst>
fun
<alyssa>
an aeron
<karolherbst>
congrats tho
<airlied>
konstantin, zmike : finally the lvp descriptor size reduction is assigned to marge
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
alatiera has quit [Quit: Connection closed for inactivity]
<karolherbst>
zmike: guess that wasn't hard after all 🙃
<karolherbst>
basically done
<karolherbst>
well.. I have a bug, I never reuse the batches :D
<karolherbst>
ohh.. I forgot to reassign the context...
<alyssa>
airlied: re 54232bee06a ("llvmpipe: flush resources on sampler view binding"),
<alyssa>
is that actually required?
<alyssa>
It seems to be papering over a test bu
<alyssa>
bug
Daanct12 has joined #dri-devel
<alyssa>
The GLES version of the test has the barrier, the GL one doesnot
<airlied>
alyssa: nice, will happily burn that fix once that lands
<alyssa>
:)
flynnjiang has joined #dri-devel
aravind has joined #dri-devel
<JoshuaAshton>
Lynne: Thanks for hooking up ffmpeg h265 encode, it's much easier to follow than that weird NVIDIA sample that's incredibly confusing and weird
kts has joined #dri-devel
crabbedhaloablut has joined #dri-devel
alarumbe has quit [Read error: Connection reset by peer]
yyds has quit [Remote host closed the connection]
alarumbe has joined #dri-devel
yyds has joined #dri-devel
yyds has quit [Read error: Connection reset by peer]
yyds has joined #dri-devel
bmodem has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
oneforall2 has joined #dri-devel
anzel has quit [Ping timeout: 480 seconds]
anzel has joined #dri-devel
Duke`` has joined #dri-devel
FL4SHK has quit [Ping timeout: 480 seconds]
FL4SHK has joined #dri-devel
simondnnsn has joined #dri-devel
yyds has quit [Remote host closed the connection]
flynnjiang has quit [Quit: flynnjiang]
kzd has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
yyds has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
fab has joined #dri-devel
sima has joined #dri-devel
glennk has joined #dri-devel
gawin has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.1.2]
lemonzest has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jsa has joined #dri-devel
rgallaispou has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
pzanoni has quit [Read error: Connection reset by peer]
lynxeye has joined #dri-devel
lplc has joined #dri-devel
tursulin has joined #dri-devel
apinheiro has joined #dri-devel
flto has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<dj-death>
should the divergence analysis pass be dealing with registers?
<dj-death>
looks like nothing does currently for registers created with nir_lower_locals_to_regs()
<tzimmermann>
there's a section on removing mtrrs via /proc/mtrr
<tzimmermann>
how does the RT process behave if you remove the VRAM's mtrr?
<jani>
jfalempe: -> has a higher precedence than e.g. & or *. passing &plane to that macro would end up being parsed as &(plane->type) instead of (&plane)->type as intended
pitust has quit [Remote host closed the connection]
mainiomano has quit [Remote host closed the connection]
ella-0 has quit [Remote host closed the connection]
rpigott has quit [Remote host closed the connection]
ifreund has quit [Write error: connection closed]
sumoon has quit [Remote host closed the connection]
cmarcelo has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
kchibisov has quit [Remote host closed the connection]
kuruczgy has quit [Remote host closed the connection]
rosefromthedead has quit [Write error: connection closed]
mainiomano has joined #dri-devel
kuruczgy has joined #dri-devel
rosefromthedead has joined #dri-devel
sumoon has joined #dri-devel
kennylevinsen has joined #dri-devel
cmarcelo has joined #dri-devel
rpigott has joined #dri-devel
kchibisov has joined #dri-devel
ifreund has joined #dri-devel
ella-0 has joined #dri-devel
pitust has joined #dri-devel
anzel has quit [Quit: Konversation terminated!]
simondnnsn has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
yyds has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
<jfalempe>
jani, I already put all plane under (plane), but that's not enough for checkpatch, it wants the whole macro under ()
<jfalempe>
tzimmermann, Yes I read a bit about mtrr, but it should do the same as removing the devm_arch_phys_wc_add() call ?
<jfalempe>
tzimmermann, ah so it can be done from userspace, without having to modify the mgag200 driver ?
<tzimmermann>
jfalempe, exactly
<tzimmermann>
i'm currently trying your instructions on my dl120 machine
<tzimmermann>
clearing the mtrr reg seems to have an impact on the latency
<jfalempe>
tzimmermann, looks strange to change the memory mapping in the "back" of the driver, but I can try that.
<tzimmermann>
jfalempe, i have to boot the kernel with 'nopat' to enable the mtrr
<tzimmermann>
then ' echo "disable=2" >| /proc/mtrr
<tzimmermann>
reg02 is the framebuffer, hence disable=2
<tzimmermann>
and then the latency goes down for the test
<tzimmermann>
you could do this via ioctl from within the RT process
<tzimmermann>
or in a wrapper script
<tzimmermann>
and then re-enable the mtrr if the RT process goes away
<jfalempe>
tzimmermann, ok, I 'll try to get access to that server again, but that sounds good.
<tzimmermann>
i could not find a way to manipulate the PAT entries from userspace, though
Daanct12 has quit [Quit: WeeChat 4.1.2]
<jfalempe>
tzimmermann, are there side effect to disable PAT ?
<tzimmermann>
you have to try. on my dl120, pat only affects the framebuffer memory
<tzimmermann>
there's no apparent difference in proactice, but still
<tzimmermann>
s/proactice/practice
<jfalempe>
ok so we can remove devm_arch_io_reserve_memtype_wc() and devm_arch_phys_wc_add(), and change devm_ioremap() to devm_ioremap_wc() ?
yyds has quit [Read error: Connection reset by peer]
<tzimmermann>
jfalempe, let me test first
<tzimmermann>
we should keep devm_arch_phys_wc_add(), but it's a no-op if PAT has been enabled
<tzimmermann>
let me do some testing and see if how the latency changes
<jfalempe>
ok
yyds has joined #dri-devel
<jfalempe>
on my server, the /proc/mtrr approach works. (it was reg08, so disable=8)
<tzimmermann>
great. so we have sound fallback if the driver cleanup doesn't do it
glennk has joined #dri-devel
bmodem has joined #dri-devel
kts has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
rasterman has joined #dri-devel
yyds has quit [Remote host closed the connection]
<Company>
here's a random question that confuses me:
<Company>
It turns out I forgot glBindAttribLocation() calls in my code, yet everything worked fine for me on all my machines and with all drivers and versions - software, zink, Intel, AMD
<Company>
that part is fine
<Company>
however, mclasen - who has the same laptop as me - had broken rendering due to that
<Company>
the only difference being that he's on rawhide and I'm on F39
<Company>
but they're both Mesa 23.3
<Company>
what can cause that?
<Company>
and the difference was with both Intel and swrast
<karolherbst>
UB being UB
<Company>
I'm interested in what's causing it
<karolherbst>
could be related to MESA_NO_ERROR
jsa has quit [Ping timeout: 480 seconds]
<Company>
that would mean that rawhide runs with MESA_NO_ERROR?
<karolherbst>
mhhh... does rawhide have different compile flags?
<karolherbst>
but I'd assume that you run with MESA_NO_ERROR for whatever reasons, as this will just skip over API errors... but anyway, kinda hard to judge what's going on here without debugging it
<Company>
running with MESA_NO_ERROR=1 doesn't cause any issues for me at least
<Company>
but maybe there's still shader caches
<Company>
I'm mostly curious so I can detect things like that when they happen in the future
<karolherbst>
what about when you run with `MESA_NO_ERROR=0` and your glBindAttribLocation call removed
<karolherbst>
mhh
<karolherbst>
Company: tried creating a gl debug context?
kzd has joined #dri-devel
<karolherbst>
I think debug builds of mesa do that by default
<karolherbst>
might also change some of the UB or something
<karolherbst>
MESA_DEBUG=context
<MrCooper>
it could just be uninitialized memory, which happens to have contain different values on different systems?
halves has joined #dri-devel
<Company>
MrCooper: I tried both asan and valgrind and they found nothing
<karolherbst>
something like that
<karolherbst>
anyway, I'd check with "MESA_DEBUG=context" with your glBindAttribLocation calls removed, just to see if any errors are printed
<Company>
nope
<Company>
there aren't any
<karolherbst>
maybe there are on mclasens system
<karolherbst>
I guess it's an gtk4 app or something?
<karolherbst>
or some other toolkit?
<karolherbst>
maybe something changed there as well
<Company>
it's the new GTK4 renderer - but we're both running the same commit
<karolherbst>
worst case do an apitrace and see what's different
<karolherbst>
mhh
<Company>
I'm pretty sure the apitrace would be identical
<karolherbst>
seems like mclasen doesn't have any additional errors
<karolherbst>
well
<Company>
I mean it works with the BindAttribLocation calls added
MrCooper has quit [Remote host closed the connection]
<Company>
but I'm still stumped by why seemingly identical code lead to different results
MrCooper has joined #dri-devel
<karolherbst>
welcome to driver development
<Company>
and I haven't yet been brave enough to dive into how mesa assigns locations
<Company>
well, it happened the same for all drivers
<Company>
including software
<karolherbst>
sure, but the bug exists or doesn't depending on the system
<Company>
right - independent of hardware apparently
<karolherbst>
the hw can still be different in subtle ways
<karolherbst>
or it's indeed some memory issue
<karolherbst>
something something
<Company>
sure, it could be things like inodes
<Company>
or caches
<karolherbst>
yeah.. anyway, nothing surprising with the same code having different results in driver development
<Company>
yeah
<Company>
I can live with it remaining a mystery, but I'd love to figure it out
<karolherbst>
maybe a reboot would trigger the bug for you, or fix it for mclasen, who knows
<Company>
I've developed on this thing for a few months and never had an issue
<Company>
and I've used mesa versions from 23.2 to git main - on multiple machines
<karolherbst>
tried with the same testcases?
<Company>
yes
macromorgan_ has joined #dri-devel
<Company>
make check with 0 failures for me and 50% of tests failing for him
<Company>
so it's really obvious
<karolherbst>
could also be a case of "you have to run thoes test cases in order to trigger it"
<karolherbst>
ohhh
<karolherbst>
I see
<karolherbst>
interesting
<Company>
all his shaders were mixing attribs seemingly randomly
<karolherbst>
well, maybe you got lucky or mclasen got unlucky
<Company>
and all my shaders kept perfect order
macromorgan_ has quit []
<karolherbst>
maybe the GPU is less/more busy on your system and it just changes things in weird ways
<karolherbst>
anyway
<Company>
... for software rendering
<karolherbst>
at this point I'd make an apitrace
macromorgan has quit [Remote host closed the connection]
<Company>
I would start reading Mesa's code next if I cared - but I'm not that curious
<karolherbst>
that wouldn't really help
<Company>
trying to figure out how it selects attrib locations when none are set
macromorgan has joined #dri-devel
macslayer has joined #dri-devel
<jenatali>
Company: I've run into that before. There's a quicksort call, which isn't a stable sort, and depending on the result you can get different bindings assigned
<jenatali>
I saw a test fail on Windows but pass on Linux due to that
<Company>
glibc:
<Company>
Fedora Rawhide 2.38.9000-30.fc40
<Company>
Fedora 39 2.38-14.fc39
<Company>
that sounds like a possible culprit
glennk has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
<jenatali>
Company: I'm curious if that does end up being it. Let me know if you confirm it
<Company>
hard to test without installing a new libc
<Company>
not sure I dare installing the rawhide libc on my F39
<Company>
I stopped using qsort() because it isn't stable (glib has a copy that is stable)
<Company>
but this might be good to know for all the GL tools that will now break because of this in F40 ;)
<ccr>
quicksort is a unstable algorithm by definition. of course many of the "qsort()" implementations like the one in glibc are not actually quicksort but something else, not that it matters per se ..
<tzimmermann>
jfalempe, it's weird
<tzimmermann>
i absolutely have to use the nopat parameter to get the reduced latency on my test system
<Company>
ccr: the qsort part in glibc used to be stable - only the non-qsort insertion sort part wasn't
<tzimmermann>
even just having pat enabled (without WC for the vram) gives worse results
<Company>
but IMO all sort algorithms should be stable by default, because nobody expects sorts to be unstable and that causes bugs
pzanoni has joined #dri-devel
<Company>
it's especially bad in C because afaik there's not even a stable sort available in libc
<jfalempe>
tzimmermann, that's weird indeed, for me disabling wc was enough and pat was always enabled before.
<Company>
jenatali: I installed rawhide glibc now
<Company>
jenatali: everything kept working
<Company>
jenatali: then I deleted the shader cache
<jenatali>
Huh
<Company>
jenatali: and now I reproduced it
<jenatali>
Ah makes sense
<Company>
so yes, F40 libc is the culprit
<jenatali>
Libc wouldn't be part of the cache key
<tzimmermann>
jfalempe, i removed devm_arch_io_reserve_memtype_wc() and also used plain ioremap(). so there was no entry in the PAT list
<tzimmermann>
but i do use a debugging build. it could be that seomthing else interferes here
<ccr>
Company, agreed about the "should be stable", yes. unstable sorts .. well, I suppose they have their uses if they are more performant and there's no need for stability.
<tzimmermann>
jfalempe, and if i now use nopat results are always good. changing /proc/mtrr doesn't seem to have much of an effect
<Company>
in my experience, they're not more performant in almost all cases
<Company>
if you want a fast sort, use timsort
<jfalempe>
tzimmermann, even with WriteCombine enabled ? that's surprising.
<jenatali>
FWIW Windows/MSVCRT qsort has always been unstable so cross-platform GL code should be fine at least
<tzimmermann>
yes, even when i has mtrrs set to WC
<jfalempe>
tzimmermann, let me try that too.
<tzimmermann>
jfalempe, i'll send out a patch that cleans up mgag200 to do the right thing for the common case. from there, nopat + /proc/mtrr should still be an option
Duke`` has joined #dri-devel
<jfalempe>
tzimmermann, ok, sounds good. even "nopat" alone should be good, if I can reproduce.
<Company>
jenatali: everybody should just use glBindAttribLocation() - but I guess simple tools can forget the call as long as it works fine
<Company>
I expect a bunch of tools to break with F40
<tzimmermann>
plain ioremap + mtrr setup
<Company>
yay, dnf downgrade is a thing, I easily can get my libc back
<tzimmermann>
that does not create a PAT entry, but an mtrr (if nopat given)
<jfalempe>
tzimmermann, ok, I'm rebuilding a kernel, I should have the results shortly.
yann-kaelig has joined #dri-devel
<tzimmermann>
jfalempe, see you tomorrow
<jfalempe>
tzimmermann, see you, thanks for all the helps.
tzimmermann has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
glennk has joined #dri-devel
yann-kaelig has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
yann-kaelig has joined #dri-devel
yann-kaelig has quit [Read error: Connection reset by peer]
ykaelig has joined #dri-devel
Kayden has quit [Quit: -> JF]
kts has quit [Quit: Leaving]
heat has joined #dri-devel
yann-kaelig has joined #dri-devel
ykaelig has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
ced117_ has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
<karolherbst>
zmike: no regressions on my side with my zink fix + using a real buffer for cb0, so I kinda want to merge it soonish
ngcortes has joined #dri-devel
pzanoni has quit [Quit: pzanoni]
<mattst88>
m/win 6
Aura has joined #dri-devel
ngcortes_ has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
Company has quit [Remote host closed the connection]
<eric_engestrom>
zmike: no, `backport-to:` is not case-sensitive (btw neither is `fixes: $sha` or `cc: mesa-stable`); there is however a bug right now, where if you specify the line two or more times, only the first match is parsed; I haven't looked into fixing that yet but I have a script that detects any such commit and I handle them manually
<eric_engestrom>
zmike: are you asking because something was not backported properly?
<zmike>
eric_engestrom: no I was asking because I was going to start using it
<zmike>
karolherbst: you can start hassling me if it's been more than 24 hours since you posted a MR
<zmike>
it's barely been 12
<eric_engestrom>
zmike: ack
<karolherbst>
oh, sorry
ngcortes__ has joined #dri-devel
ngcortes_ has quit [Read error: Connection reset by peer]
ngcortes__ has quit [Read error: Connection reset by peer]
fab has quit [Ping timeout: 480 seconds]
AnuthaDev has joined #dri-devel
gouchi has joined #dri-devel
ngcortes has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
yann-kaelig has quit []
tursulin has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
pzanoni has joined #dri-devel
mvlad has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
ngcortes has joined #dri-devel
Kayden has quit [Remote host closed the connection]
Kayden has joined #dri-devel
Haaninjo has joined #dri-devel
AnuthaDev has quit []
<mareko>
DavidHeidelberg: ping on libdrm
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
anzel has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
simon-perretta-img has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
crabbedhaloablut has quit []
sima has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
<JoshuaAshton>
Lynne: Did not test ffmpeg myself, just was peeking at the code in that branch to see wtf I was missing my own Vulkan Video Encode setup
<JoshuaAshton>
This stuff is so hard to follow :sweat_smile:
Haaninjo has quit [Quit: Ex-Chat]
kasper93 has quit [Ping timeout: 480 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
Kayden has quit [Quit: testing network changes]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
nukelet has joined #dri-devel
jeeeun841351908 has quit [Remote host closed the connection]