ryanpcmcquen has quit [Remote host closed the connection]
kandinsk1 has joined #dri-devel
kandinsk1 has quit [Remote host closed the connection]
GloriousEggroll has quit [Quit: Death is life's way of telling you you've been fired.]
macromorgan has joined #dri-devel
macromorgan_ has quit [Read error: Connection reset by peer]
neonking has quit [Remote host closed the connection]
neonking has joined #dri-devel
neonking has quit [Remote host closed the connection]
tarceri has joined #dri-devel
mripard has quit [charon.oftc.net liquid.oftc.net]
rsripada has quit [charon.oftc.net liquid.oftc.net]
mareko has quit [charon.oftc.net liquid.oftc.net]
hikiko has quit [charon.oftc.net liquid.oftc.net]
hikiko has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
<drawat>
dim apply-branch drm-misc-next <mbox> file is not working for me. It is stuck. I did dim setup, dim update-branches, dim checkout drm-misc-next. Anything I am missing?
khfeng has joined #dri-devel
drawat has quit [Remote host closed the connection]
drawat has joined #dri-devel
thrillgore has joined #dri-devel
thrillgore has quit [Remote host closed the connection]
<drawat>
cat mbox | dim apply-branch drm-misc-next worked for me.
blue__penquin has joined #dri-devel
shankaru1 has joined #dri-devel
<airlied>
anholt: you broke gen4/5 fs with reg alloc patch
sdutt has quit [Remote host closed the connection]
<airlied>
jekstrand: ^
<airlied>
or not fs, vec4
Duke`` has joined #dri-devel
freaked has joined #dri-devel
freaked has quit [Remote host closed the connection]
<alyssa>
What's the difference between align, ALIGN, and ALIGN_POT?
<HdkR>
One is calm, one is yelling, and one is high while yelling
<pq>
lol
<ccr>
:P
<HdkR>
I can assume that align_pot is an align up to fit the integer, with alignment being power of two though
<HdkR>
Even if aligndown variants are also important to have
<alyssa>
those are all align up afaict
<alyssa>
Differences seem to be, er
<alyssa>
align/ALIGN assert the alignment is a POT, whereas ALIGN_POT just yolo's it
<alyssa>
ALIGN_POT is a macro and should work with all types, where align/ALIGN hardcode type sizes and have 64-bit variants as well
<alyssa>
between align/ALIGN one is int and the other is intptr_t
<alyssa>
but... it would seem to me that all of align/align64/ALIGN/ALIGN64/ALIGN_POT could be folded somehow and nothing of value would be lost
<alyssa>
I admit I'm one of the heaviest ALIGN_POT users :p
<HdkR>
weird. Smells like footgun
thellstrom1 has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
soreau has joined #dri-devel
<jekstrand>
airlied: Yeah, saw the issue and MR. Let me pull out ye olde ILK and take a look before we wholesale revert.
<MrCooper>
pepp: ugh, which part of that exactly? :) narrowing it down is going slow for me, since even an affected setup may not hang for days
jernej_ is now known as jernej
soreau has quit [Remote host closed the connection]
<jekstrand>
airlied: You have to be careful with ALIGN vs. ALIGN_POT. Sometimes ALIGN assumes power of two and sometimes it doesn't.
<jekstrand>
ALIGN_POT is always power-of-two.
<jekstrand>
alyssa, rather.
soreau has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
<pq>
jekstrand, "sometimes"? You mean there are several different definitions of ALIGN? In Mesa?
<jekstrand>
pq: Sadly, I think so. :-(
<pq>
wee
<jekstrand>
pq: It may be all cleaned up and clear these days but not enough that I trust it.
<alyssa>
what
<HdkR>
what, how does align sometimes do pot? =o
<robclark>
there is also ALIGN_NPOT() ;-)
<alyssa>
ahh
<robclark>
I think some of this goes back to gallium vs mesa headers
<robclark>
and then some things moved from aux/util to src/util
<alyssa>
sounds like a job from ~sed~ coccinelle
sdutt has joined #dri-devel
<enunes>
hi, could someone that understands better about dri2/dri3 take a look at https://gitlab.freedesktop.org/mesa/mesa/-/issues/4861 and double check if it makes sense to add the dri3 kmsro check that I'm suggesting?
sdutt has quit []
<jekstrand>
airlied, anholt: Looks like something's messed up with payload register interference with the new path. Debugging now.
sdutt has joined #dri-devel
<jekstrand>
I'm surprised this only blew up iron lake.
Duke`` has joined #dri-devel
kaitsh has joined #dri-devel
kaitsh is now known as Guest1154
Guest1154 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-07 15:08:44)]
thellstrom has joined #dri-devel
<pepp>
MrCooper: the issue was bisected to Mesa commit 820dec3f7c7. I'm wondering if you could trigger the hang on a Mesa branch without this commit
<jekstrand>
Running piglit on the ILK in my office and kicking through CI now.
shankaru1 has quit []
<MrCooper>
pepp: is the firmware supposed to handle 0 for those?
<alyssa>
ILK? KBL? so inconsistent.. :-p
itoral has quit [Read error: Connection reset by peer]
<jenatali>
Gotta be a TLA
<pepp>
MrCooper: I'm not sure.
<jekstrand>
alyssa: Yeah, probably should have been IRL or maybe FEL :)
shankaru1 has joined #dri-devel
emergence has joined #dri-devel
emergence has quit [Remote host closed the connection]
<HdkR>
Don't forget LKF and ADL :)
<HdkR>
Or do we not talk about those ones?
<jekstrand>
We don't like to but we do.
<jekstrand>
It's *** we don't talk about. :)
<HdkR>
:D
* ccr
pokes BYT with a very long stick.
<jekstrand>
BYT is mostly fine
<jekstrand>
CHV and GLV (I think?) are annoying because they skimped on PTE bits and, even though you have 64-bit addresses, you can't use most of those bits. :(
<jekstrand>
Otherwise, the atom parts are mostly like their bigger cousins only with less caching.
<jekstrand>
and bezarre back-porting of misc. pieces.
<alyssa>
jekstrand: "FEL" took me a minute to get =)
<jekstrand>
:)
<zmike>
robclark: maybe was a bit too quick on the rebind thing last week, but I finished atom reordering this morning (provisionally) and it does seem feasible to do that with certain caveats
mbrost has joined #dri-devel
<robclark>
cool, got MR?
<zmike>
no, I haven't even run real tests on it other than a couple games
<zmike>
going to actually try building some optimizations with it first too so I can make sure the new api is usable
blue__penquin has quit []
<zmike>
still have to finish this rebind thing first
frieder has quit [Remote host closed the connection]
gouchi has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<alyssa>
anholt: !10183 landed? Hallelujah!
<anholt>
seriously, impressive work by Roman and so desperately needed
<alyssa>
<3
<alyssa>
jekstrand: I am happy to r-b and a-b and all-the-b !9728 but my opinion means nothing :-p
gjabell10 has joined #dri-devel
gjabell10 has quit [Remote host closed the connection]
<jekstrand>
alyssa: Yeah, I really want acks from all the android peeps.
<jekstrand>
So it may take a little while yet
<jekstrand>
But hopefully in the next couple of weeks
<jekstrand>
It's crazy how much code we're carrying in the Android build. It's more than half the size of crocus.
<jekstrand>
And just as copy+pasted. 😂
<alyssa>
😂
<alyssa>
jekstrand: Can I do my part and delete the panfrost files now?
<alyssa>
If you want Android.mk frost, you have... er... 21.1
thellstrom has quit [Remote host closed the connection]
<jekstrand>
alyssa: You could but I think we should just wait for some acks from the Android folks and then torch it all.
<jekstrand>
I don't expect it'll take too long given the amount of collaboration that happened on the build-with-meson MR.
<HdkR>
Whoa. Meson in AOSP? That's...huge
idr has joined #dri-devel
<jekstrand>
Well, some clever wrapping, anyway.
<HdkR>
As long as the mesa side only cares about meson instead of breaking Android every other day :)
<anholt>
HdkR: not in aosp, it's "required as a dep in your system if you want to drop your upstream mesa into aosp"
<anholt>
very non-android, but Mesa's use of in-tree Android.mk is very non-android already.
<HdkR>
Right
Duke`` has quit [Ping timeout: 480 seconds]
<HdkR>
Much better solution though
<anholt>
yeah, it's obviously the right compromise.
<alyssa>
isn't "non-android" a good thing for upstream? :-p
tpowa has joined #dri-devel
tpowa has quit [Remote host closed the connection]
<jenatali>
jekstrand: Ready to remove "draft"? Makes it seem like it's not ready for reviews/acks yet
<HdkR>
alyssa: The less Android in one's life, the better.
<jekstrand>
Sure. No more draft. :-)
* anholt
cries in python
khfeng has quit [Ping timeout: 480 seconds]
<jekstrand>
anholt: import tears?
<ccr>
from rain import tears as all_these_memories
<anholt>
for var in "i wish I had types": print("whoops that was a string I iterated the chars of instead")
<jekstrand>
Yeah.....
<alyssa>
anholt: over in m1 r/e land we have a ton of mmio poke scripts in python
sdutt_ has joined #dri-devel
<alyssa>
saturday night: machine starts to boot for 2 minutes before it crashes because the host it was tethered too had a runtime error Python only just noticed after minutes of running
thellstrom has joined #dri-devel
Duke`` has joined #dri-devel
sdutt has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
<mareko>
I'm going to add fast_mtx_t, faster than simple_mtx_t
<zmike>
yesssss
Danct12 has joined #dri-devel
<alyssa>
mareko: Mike has taught me that adding fast in the name of things makes it faster, gauranteed.
<alyssa>
That's why my fast_asahi_fast_driver_for_fast_apple_fast_m1 is so fast!
<mareko>
today I discovered that there is slow uint32_t and fast uint32_t
<alyssa>
least?
<alyssa>
yes, right, uint_fast32_t
<mareko>
and I'm being totally 100% serious
<alyssa>
yep.
<dcbaker>
anholt: there are type annotations, which coupled with mypy or one of the other static type checkers prevent a lot of *that*
Daaanct12 has quit [Ping timeout: 480 seconds]
sdutt_ has quit []
sdutt has joined #dri-devel
<anholt>
Yeah, I know you can bolt on types if you work hard.
<dcbaker>
it really isn't any harder to use types in python than any other language
<dcbaker>
it's just that most other languages make you do it
<mareko>
if I take simple_mtx_t and put fast uint32_t into it, it becomes faster
<anholt>
I'm a fan of languages that make you make good decisions up front rather than be disciplined to avoid failures.
<dcbaker>
it's sort of the problem with being an established language though, no?
<zmike>
I like the sound of faster mutexes
<dcbaker>
what seemed like a good idea at the time turned out to be a not so good idea, and now you can't break all of the programs that rely on on that behavior without a python 4
<dcbaker>
and with the way everyone bitches about python 3, which fixed the same kind of "seems like a good idea but wasn't" design decisions we'll never get a python that forces type annotations :(
<mareko>
I can add fast_mtx_t, or I can make simple_mtx_t faster, but I would have to remove _SIMPLE_MTX_INITIALIZER_NP
<zmike>
my machine is doing a distro sync because I hit a dri3 hang and decided I may as well since I had to reboot
<zmike>
checking those tests is on my todo for this week though
<jekstrand>
Wait... Yeah, there's no way those tests are affected by my patch.
* jekstrand
kicks to jenkins. If that passes, marge.
<zmike>
I'd have said just retry
<daniels>
mareko: alignment?
<zmike>
wondering if that tc+revert MR somehow hit another tc bug since there hasn't been much else going in lately
<alyssa>
Woo! After an hour of grumbling I fixed.... 3 tests!
<alyssa>
after writing... 1 line of code!
* alyssa
sighs
<alyssa>
hey, progress
<jekstrand>
Hey, that's a pretty good tests/line there
<jekstrand>
Though I did just fix a bug that hosed an entire 3 platforms with -LOC so....
ngcortes has joined #dri-devel
<alyssa>
jekstrand: Hey, planned obsolesence takes a lot of work, you have to write lots of LOC to hose old platforms without affecting the new shiny
<jekstrand>
heh
<Venemo>
alyssa: I found the most embarassing 1 liner bug ever in my MR today
ak_hepcat13 has joined #dri-devel
<alyssa>
Adding a new test suite to a driver passing 100% of a single suite and not tested on any other
<alyssa>
is a great exericse in exposing 1 liners
ak_hepcat13 has quit [Remote host closed the connection]
<alyssa>
ha ha! 1 fail fixed!
<Venemo>
I accidentally allocated the maximum amount of LDS (shared memory) to every vertex shader and then I had the surprised pikachu face when I was told the MR decreases performance significantly
<alyssa>
pika pika
<Venemo>
in my defense, it was a rebase gone wrong
<mareko>
the optimization was that I would move atomic variables next to each other in memory, so that an atomic op on a cache line would not evict non-atomic data, except that it doesn't work like that
<tango_>
but then it wouldn't matter where they are, right?
<tango_>
why would it make unrelated code slower?
<airlied>
mareko: wouldn't that have more contention on the cache line you stored the atomics in?
<airlied>
I'd have though you'd be better doing something like the kernel does in some places and aligning things to consume a full cacheline
<tango_>
airlied: you mean if multiple threads tried atomic updates of adjancet variables?
<mareko>
airlied: atomics would only be accessed via atomics, so caching wouldn't occur anyway
<tango_>
they'd hit the same cacheline instead of being on separate ones?
<airlied>
mareko: my guess is that statement isn't exactly true, though I don't know enough of modern cpu microarchitecture
<airlied>
esp with prefetching etc
<airlied>
tango_: yes, and that would cause more invaldiations etc
<tango_>
well this should be easy to check though
<mareko>
well, we use atomics to do simple_mtx_t, and to make that work, it must invalidate the whole cache
<tango_>
look at the assembly and see if loads use nontemporal instructions or not
<mareko>
tango_: what is that?
csoriano has quit []
<tango_>
mareko: how are atomics read at the assembly level?
<tango_>
in the sense: what cpu instructions end up being used when reading the atomics?
<mareko>
via gcc intrinsics
<tango_>
mareko: can I see the code somewhere?
<mareko>
tango_: lock addl $0x1,(%rdx)
mbrost_ has quit [Remote host closed the connection]