MrRobot7_ has quit [autokilled: spambot. Dont mail support@oftc.net with questions (2021-06-14 00:12:30)]
Lucretia has quit []
eschwartz20 has joined #dri-devel
eschwartz20 has quit [Remote host closed the connection]
luzipher__ has joined #dri-devel
aswar002 has joined #dri-devel
luzipher_ has quit [Ping timeout: 480 seconds]
majdi has joined #dri-devel
majdi has quit [Remote host closed the connection]
mlankhorst has quit [Ping timeout: 480 seconds]
luzipher_ has joined #dri-devel
<kisak>
airlied: congrats on landing crocus
luzipher__ has quit [Ping timeout: 480 seconds]
<kisak>
now it's a race to get a graceful, regression free transition to crocus before i965 is yeeted out the window, isn't it?
<airlied>
kisak: oh we can yeet i965 into LTS first :-P
* dcbaker
goes to merge the delete classic MR
<dcbaker>
airlied: congrats!
<kisak>
I still don't understand why a LTS branch is better than having it as a subfolder.
<kisak>
but my perception of reality in this case doesn't affect anything important
<dcbaker>
For Intel having classic in tree is huge pain. Changes to core Mesa break things, and no one notices until rc1. In a branch the core Mesa layers won't change
<kisak>
right, and mesa/src/core would be completely separate from legacy/mesa/src/core.
<dcbaker>
Exactly
<kisak>
the difference being that you could keep mesa a single distro source package and have some build option the equivilent to --build-legacy which fires up meson in the subfolder as a subproject
<kisak>
^along with building the current driver in the main tree.
<bloom>
kisak: That sounds complicated. How is that better than having it as an LTS branch? :)
<dcbaker>
I don't understand why that would be valuable? You'd end up copying all of Mesa into a subfolder in that case, right?
<bloom>
(I think any attempt to answer either question is little more than bikeshedding. Aesthetically they're both icky. I think LTS branch is a bit less icky.)
<kisak>
dcbaker: to start, yes, I'd expect that to be the low effort direction to get things started, then trim unwanted stuff later. I just don't want to get stuck in the situation where nobody wants to cut a LTS point release and it falls into the same category of supported but not really as xf86-video-intel
<bloom>
> then trim unwanted stuff later.
<bloom>
I'm not sure this would really happen..
<bloom>
AFAIU, nobody really cares about classic drivers, with iris in top shape and crocus merged.
<robclark>
the layering between mesa and mesa/st is already breaking down in the name of perf.. I think trimming classic driver cruft will come sooner more than later
<bloom>
Making an LTS branch is just a much softer approach than deleting the classic drivers and telling users they're stuck on 21.1
<robclark>
mareko will delete a bunch of code and refactor what is left in the name of 10% :-P
<bloom>
This way there's still a reasonable way for hot fixes to be backported but otherwise the code disappears for the 99% of mesa devs who don't work on classic
<dcbaker>
And other than i965, that hardware is *ancient*
<bloom>
dcbaker: and on i965 nowadays is there /any/ reason to prefer i965c over iris? other than Enterprise(TM) needing no changes, but they're stuck on 19.1 anyway :-p
<airlied>
pretty sure RHEL switched to iris
<airlied>
we don't stick to old things
<dcbaker>
Iris? No. Crocus? For a while longer, yeah
<bloom>
airlied: ah, Debian then :-p
<dcbaker>
You need iris for ice lake aka tiger lake
<dcbaker>
*and
<bloom>
Apparently in just a few months Panfrost support will land in Debian ;-P
<HdkR>
`MESA: error: compile failed! ((null):(null))` is a ...fun error message
aswar002 has quit [Remote host closed the connection]
<kisak>
dcbaker: The more important parts of the topic has been iterated on more than once. I just don't look forward to the support void while things get figured out in the distro packaging, and what it'll take to get the pieces to fit together on older Ubuntu (which it probably won't multislot mesa properly).
<mareko>
having faster display lists in gallium would be nice
Lightkey has quit [Ping timeout: 480 seconds]
<HdkR>
Oh, this is a turnip specific error message
* HdkR
shakes fist at robclark
luzipher__ has joined #dri-devel
boistordu_old has joined #dri-devel
<bloom>
HdkR: rob's got nothin' to do with turnip bugs
* bloom
shakes fist at krh
<bloom>
😋
Lightkey has joined #dri-devel
* HdkR
shakes fist at the world
luzipher_ has quit [Ping timeout: 480 seconds]
boistordu has quit [Ping timeout: 480 seconds]
<robclark>
HdkR: iirc one of the nulls is shader name and other is label.. seems like both where null for you
<robclark>
bloom: tbf that is a compiler error.. so probably my fault.. most likely RA fail
<HdkR>
robclark: Yea, after inspecting source I realized :)
<robclark>
if it is a shader that needs spilling for RA to succeed.. I guess have patience.. otherwise send .shader_test
flto_ has joined #dri-devel
<HdkR>
I just saw it in the logs when running Dirt 4 with Turnip. Not sure how fatal that ends up being
flto has quit [Ping timeout: 480 seconds]
<HdkR>
Game runs out of memory on my 6GB board anyway :P
<robclark>
HdkR: I guess a compile fail isn't great if the game actually ends up using the shader.. although I've run across games that compile some extra shaders just for lolz..
<robclark>
HdkR: if you feel like living dangerously, add zram swap and `echo 1 > /sys/module/msm/parameters/enable_eviction`
<robclark>
4GB chromebooks are all about zram swap.. and fitting 8GB of chrome in a 4GB bag
<HdkR>
I do have zram swap enabled. So flicking that switch is pretty easy
<robclark>
(might be a bit less useful with vk/tu compared to gallium.. because vk isn't tracking what actually needs to be paged in for a given batch)
<HdkR>
Looks like the shader that fails 42 blocks and 1613 ssa values
<HdkR>
fails has*
luzipher_ has joined #dri-devel
<HdkR>
Not even as complex as the prvious ones :D
flto_ has quit []
flto has joined #dri-devel
<robclark>
HdkR: if you are more than a few days behind ToT, then rebase to get new RA pass.. there are some corners where original RA didn't do so well.. and new RA lays the groundwork for spilling if on it's own it is not enough
<HdkR>
Definitely a few days old. I'm running 21.1 here
luzipher__ has quit [Ping timeout: 480 seconds]
<robclark>
worth giving it a try on something more recent.. esp for shaders with more flow control
<HdkR>
Alright, when I have a bit of time I will rebuild ToT
<bloom>
HdkR: 1613 ssa values doesn't even seem so bad
<robclark>
old RA was good enough for most android games, but I guess you can find stuff on steam which exposes it's weaknesses
<bloom>
i've been broken by dEQP-GLES31.functional.ssbo.layout.random.*
<HdkR>
Seeing if it gets further with this eviction bit set
<robclark>
bloom: it depends on the live ranges
<bloom>
robclark: well, yes
<HdkR>
It also has the dangerous loop and divergent flow inside that loop :P
dviola has joined #dri-devel
<bloom>
i meant more in ters of "how many instructions before your O(N^2) passes grind to a halt"
<robclark>
(eviction won't help w/ RA fail obv, but could help w/ OoM)
<HdkR>
Exactly. Seeing if it gets a bit farther by avoiding the oom
<HdkR>
I'm running 100GB of swap, shouldn't get close to that
<robclark>
CrOS does zram swap at 2x RAM size for x86 and 1.5x for arm (but we might bump to 2x once I can get the kinks sorted.. the diff is down to swappable GEM bos)
<HdkR>
Nice
dviola has quit []
lemonzest has quit [Quit: Quitting]
<HdkR>
Looks like Dirt4 gets very upset about shaders failing to compile. It has just hung on the loading screen :)
<HdkR>
Oom gone though
<HdkR>
Maybe I'll find time once 21.2-rc1 launches :P
xq[m] has quit [Remote host closed the connection]
GloriousEggroll has quit [Quit: Death is life's way of telling you you've been fired.]
NiksDev has joined #dri-devel
shankaru has joined #dri-devel
xp4ns3 has quit []
xp4ns3 has joined #dri-devel
xp4ns3 has quit []
xp4ns3 has joined #dri-devel
GloriousEggroll has joined #dri-devel
Duke`` has joined #dri-devel
ryzokuken has joined #dri-devel
ryzokuken has quit [Remote host closed the connection]
doda12 has joined #dri-devel
doda12 has quit [Remote host closed the connection]
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
itoral has joined #dri-devel
blue__penquin has joined #dri-devel
blue__penquin has quit []
blue__penquin has joined #dri-devel
blue__penquin has quit []
luzipher__ has joined #dri-devel
luzipher_ has quit [Ping timeout: 480 seconds]
blue__penquin has joined #dri-devel
Daaanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
RobertC has joined #dri-devel
blue__penquin has quit []
sdutt has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
mwalle has quit [Quit: WeeChat 2.3]
mwalle has joined #dri-devel
mwalle has quit []
Duke`` has quit [Ping timeout: 480 seconds]
mwalle has joined #dri-devel
danvet_ has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
i-garrison has joined #dri-devel
Danct12 has joined #dri-devel
myfreeweb has joined #dri-devel
NiksDev2 has joined #dri-devel
myfreeweb has quit [Remote host closed the connection]
agx_ has quit [Read error: Connection reset by peer]
agx_ has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
bcarvalho has quit [Quit: Leaving]
thellstrom has joined #dri-devel
andrey-konovalov has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
robertfoss has quit [Quit: WeeChat 2.6]
thellstrom has joined #dri-devel
robertfoss has joined #dri-devel
zf` has joined #dri-devel
zf has quit [Ping timeout: 480 seconds]
thellstrom1 has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
shankaru1 has joined #dri-devel
lynxeye has joined #dri-devel
bcarvalho has joined #dri-devel
pochu has joined #dri-devel
shankaru has quit [Ping timeout: 480 seconds]
<MrCooper>
mareko: IME (might depend on the games though) DXVK doesn't stutter that badly with ACO, it's very painful with LLVM though
rasterman has joined #dri-devel
pcercuei has joined #dri-devel
andrey-konovalov has quit [Ping timeout: 480 seconds]
<airlied>
would be good to have some synthetic benchmark for stutter
<airlied>
even if it needed some driver instrumentation
lemonzest has joined #dri-devel
Lucretia has joined #dri-devel
itoral has quit [Remote host closed the connection]
pnowack has joined #dri-devel
yk has joined #dri-devel
pnowack has quit []
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
burrhole has joined #dri-devel
burrhole has quit [Remote host closed the connection]
mlankhorst has quit [Remote host closed the connection]
Namarrgon has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
Benjojo11 has joined #dri-devel
Benjojo11 has quit [Remote host closed the connection]
aravind has joined #dri-devel
xp4ns3 has quit []
sumits has joined #dri-devel
hikiko has quit [Read error: Connection reset by peer]
Gizmokid2005 has joined #dri-devel
Gizmokid2005 is now known as Guest2087
Guest2087 has quit [Remote host closed the connection]
hikiko has joined #dri-devel
ircuser-1 has joined #dri-devel
ircuser-1 has quit [Remote host closed the connection]
itoral has joined #dri-devel
Newbyte[m] has joined #dri-devel
SpikeHeron has joined #dri-devel
SpikeHeron has quit [Remote host closed the connection]
Aleksey6-t has joined #dri-devel
Aleksey6-t has quit [Remote host closed the connection]
blocked has joined #dri-devel
blocked has quit [Remote host closed the connection]
danvet_ has quit []
danvet_ has joined #dri-devel
jonasschnelli has joined #dri-devel
jonasschnelli has quit [Remote host closed the connection]
danvet_ is now known as danvet
danvet has quit [Quit: Leaving]
danvet has joined #dri-devel
danvet has quit []
danvet has joined #dri-devel
shankaru1 has quit []
itoral has quit [Remote host closed the connection]
robert_mader has joined #dri-devel
ignapk has joined #dri-devel
<robert_mader>
Hi - is it intended that users without higher permissions can't subscribe to issues/mrs on gitlab.freedesktop.org any more? Makes it hard to follow :/
ignapk has quit [Remote host closed the connection]
<robert_mader>
If not, whom could I ping about it?
<emersion>
maybe ask in #freedesktop?
<pendingchaos>
it's a gitlab bug
<pendingchaos>
you can workaround it by commenting or using the thumbs up/down thing
<robert_mader>
pendingchaos: you mean once I commented or upvoted an issue I can subscribe?
<pendingchaos>
if you comment or upvote, you will be subscribed
mpickering9 has joined #dri-devel
mpickering9 has quit [Remote host closed the connection]
thellstrom has quit [Quit: thellstrom]
blue__penquin has joined #dri-devel
beardface has joined #dri-devel
beardface has quit [Remote host closed the connection]
vivijim has joined #dri-devel
Bruners has joined #dri-devel
Bruners has quit [Remote host closed the connection]
enilflah has joined #dri-devel
blue__penquin has quit [Remote host closed the connection]
blue__penquin has joined #dri-devel
shankaru has joined #dri-devel
aravind has quit []
blue__penquin has quit []
<yk>
robert_mader: you can also put /subscribe or /unsubscribe commands in the comments.
<yk>
It will not create an actual comment.
blue__penquin has joined #dri-devel
<robert_mader>
yk: thanks. I guess that's better anyway for people hacking on mesa - now I know how to subscribe to issues when my drivers are broken and I need to use elinks on a tty ;)
* jekstrand
pulls Hey Look, a new driver in my tree. :D
<JoshuaAshton>
Better get the fire brigade to get them down then. Drivers in trees are usually because of a car crash.
macromorgan has joined #dri-devel
ddavenport has joined #dri-devel
<jekstrand>
:D
ddavenport has quit [Remote host closed the connection]
rgallaispou has quit [Remote host closed the connection]
chrootsu-t has joined #dri-devel
chrootsu-t has quit [Remote host closed the connection]
huz[m] has joined #dri-devel
huz[m] has quit [Remote host closed the connection]
rgallaispou has joined #dri-devel
Ghegs has joined #dri-devel
Ghegs has quit [Remote host closed the connection]
NiksDev has quit []
thellstrom has joined #dri-devel
thellstrom has quit []
karolherbst has quit [Quit: Konversation terminated!]
blue__penquin has quit [Remote host closed the connection]
sdutt has joined #dri-devel
blue__penquin has joined #dri-devel
ced117 has joined #dri-devel
blue__penquin has quit []
Duke`` has joined #dri-devel
karolherbst has joined #dri-devel
thellstrom has joined #dri-devel
tlwoerner_ has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
xp4ns3 has joined #dri-devel
ppascher has joined #dri-devel
<jekstrand>
Phornoix comments are just wonderful sometimes....
<jekstrand>
"gallium drivers are build with two blocks: first implements NIR, and second is using NIR to implement Vulkan/OpenGL and etc.
<jekstrand>
There is big win because second block can be shared between all gallium drivers. Less bugs and easier to introduce optimizations for all drivers. "
<zmike>
that feels like a good copypasta template
<jekstrand>
surprisingly, the comments section on the crocus article has managed to go 23 whole comments without drifting off into nvidia or network cards...
pekkari has joined #dri-devel
andrey-konovalov has joined #dri-devel
anderson has joined #dri-devel
anderson has quit [Read error: Connection reset by peer]
<pinchartl>
dianders: I had completely overlooked the fact that your sn65dsi86 changes were making use of auxiliary_device, it got hidden by the discussion of a new AUX bus :-S
GloriousEggroll has quit [Remote host closed the connection]
<FLHerne>
jekstrand: Is that not mostly accurate, if badly-worded?
<dianders>
pinchartl: Yeah, the naming similarity was pretty unfortunate. :( Though some of the auxiliary_device changes I landed actually landed before the new AUX bus support, since it also fixed the GPIO chicken-and-egg problem.
<jekstrand>
FLHerne: Maybe sort-of. If all you're concerned about is compiler stuff, maybe?
<FLHerne>
(modulo the few TGSI things, and lavapipe being not very performant)
<jekstrand>
But there's an entire driver worth of state setup that it's totally ignoring
<jekstrand>
Also gallium has nothing to do with Vulkan
<pinchartl>
dianders: well, the code has been merged, so I'd better shut up anyway :-)
<FLHerne>
Lavapipe has a Vulkan-Gallium frontend, no?
<FLHerne>
I don't understand the state stuff properly so I'll believe you that it's complex :p
bluebugs has joined #dri-devel
<jekstrand>
Yes, lavapipe sort-of goes through gallium, but it's the only one.
<dianders>
pinchartl: LOL. Yeah, it definitely was a bit weird but it really did cleanup a bunch of the inter-dependencies a lot to break the probe into chunks and allow their probes to finish even if other parts of the driver needed to "defer".
<jekstrand>
And lavapipe can get away with it because it does all non-trivial work in vkQueueSubmit()
<pinchartl>
dianders: I challenge you to unload modules in a safe way
<pinchartl>
one may argue it was already broken, and that's true, but it's sad to see we're giving up
<FLHerne>
Would it make sense to create a lower-than-Gallium layer for more codesharing between Vulkan and Gallium drivers? Or would that just be a midlayer-vs-library mistake?
GloriousEggroll has joined #dri-devel
<FLHerne>
How about when someone wants a d3d12 frontend?
<dianders>
pinchartl: it wasn't possible beforehand on my system anyway. :(
<FLHerne>
Or a Metal one
<pinchartl>
dianders: hence my comment about giving up
<pinchartl>
we're making it worse with pretty much every release of the kernel :-(
<jekstrand>
FLHerne: I don't think you could effectively make such a thing in a cross-driver way.
<jekstrand>
FLHerne: I've thought about doing something to try and share more between iris and ANV but it's really tricky
<jekstrand>
IMO, write both drivers and see what you can merge.
<pinchartl>
danvet: do you consider driver unloading (and in general unbinding of devices from their driver through sysfs) something that DRM/KMS should officially support ?
<danvet>
yeah
<danvet>
I mean there's very active discussion about fixing it
<danvet>
and already quite some work
<danvet>
I think for kms side it should be mostly there
<danvet>
aside from some lolz around shareable objects like dma-buf and dma_fence
<jekstrand>
danvet: Yeah, dma-fence..... :)
<pinchartl>
danvet: have you looked at bridges ? :-)
<danvet>
lol
<danvet>
I'm occasionally trying to kick the can a bit on fixing some of the bridge device driver model issues
<danvet>
like devlinks or whatever it is to fix unload, and encouraging drivers to not roll their own component.c stuff on top of drm_bridge.c (because that just wreaks it all I think)
<danvet>
but mostly people then get upset that I'm even just suggesting they work on more than their own little world
<danvet>
so *shrug*
<danvet>
but yeah if you don't have a drm_bridge, it should work
<pinchartl>
well, auxiliary_device won't help, we're making the issue harder to fix
<pinchartl>
if you have a monolithic driver that doesn't need any resource provided by modules it's easy, indeed
<pinchartl>
for anything else, the current code base is a mine field that everybody hopes to never have to fix
luckyxxl has joined #dri-devel
<robclark>
working module unload seems like a unicorn
GloriousEggroll has quit [Read error: Connection reset by peer]
<dianders>
pinchartl: why is auxiliary_device fundamentally a problem? It should still be possible to unbind stuff assuming you get it in the right order, right? I certainly see the attributes there.
luckyxxl has quit []
GloriousEggroll has joined #dri-devel
<pinchartl>
dianders: because it has no lifetime management as far as I can tell. once you acquire a pointer to the auxiliary device, and from there get the pointer to the driver and to the driver-specific ops (the latter isn't used in your series, that at least is good news) nothing prevents those from becoming invalid due to device unbind behind the back of their user
<dianders>
pinchartl: In general, though, can't you assume that the parent device is alive and well if you're running in the child? In other words it's not OK to unbind the parent until after you've unbound all the children?
Jmainguy has joined #dri-devel
Jmainguy has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-14 16:23:33)]
<pinchartl>
dianders: it's not just about parent and children here, but about provider and consumer
shankaru1 has joined #dri-devel
<pinchartl>
an device can provide a GPIO and someone else can consume it. try to unbind the GPIO provide device and watch the world collapse
<pinchartl>
regarding parents and children, unbinding a parent needs to unbind the children, or we'd really be screwed :-)
<pinchartl>
but someone may still hold a pointer to a resource provided by a device getting unbound
<pinchartl>
a typical example is drm_bridge, driver look up bridges from DT nodes and get a pointer that isn't even reference-counted
shankaru has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
<alyssa>
trying to track down a copy of valhall-1691526.wa
shankaru1 has quit [Ping timeout: 480 seconds]
<robclark>
alyssa: not sure.. dianders might know, I've not really touched mali chromebooks, we get our gpu fw from linux-firmware
<dianders>
pinchartl: that makes it sound like it's a more serious problem with Linux in general, though. I need to expose a GPIO from my driver that's consumed by someone else. If Linux isn't doing some sort of protection here then this isn't really going to be something that's so solvable. Are you sure that's not handled, though? gpiod_request() seems to add a reference? So shouldn't Linux yell? Hrm, though. It doesn't seem to. :(
<alyssa>
robclark: ack, thanks
<alyssa>
dianders: fancy seeing you here ;-P
<pinchartl>
dianders: it's a kernel-wide issue that we make worse every time we add a producer/consumer pair
<dianders>
alyssa: Never heard of `valhall-1691526.wa`. Let me see if I can figure out what's going on with that.
<alyssa>
dianders: Could I PM?
<dianders>
alyssa: sure
jewins has joined #dri-devel
jewins1 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
jzelinskie has joined #dri-devel
jzelinskie has quit [Remote host closed the connection]
gouchi has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
xxpor has joined #dri-devel
xxpor has quit [Remote host closed the connection]
illwieckz has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
aswar002 has joined #dri-devel
mattrope has joined #dri-devel
xp4ns3 has quit [Quit: Konversation terminated!]
xp4ns3 has joined #dri-devel
dllud has joined #dri-devel
<cwabbott>
dschuermann: alyssa: just catching up on scrollback after i was gone... tbh i was kinda thinking of doing an SSA register allocation talk too
<bloom>
cwabbott: would love to watch it
<bloom>
erm
bloom has left #dri-devel [#dri-devel]
<alyssa>
cwabbott: would love to watch it
* alyssa
whistles
<cwabbott>
for the ir3 RA work, i was kinda disappointed that there was no resource i could point reviewers at that really did a good job explaining how ssa-based allocation actually works in practice with aco (and now ir3) with live-range splitting and whatnot
<alyssa>
yeah
teardown has joined #dri-devel
<alyssa>
the academic papers referenced seem so far off from how aco/ir3 actually work
<cwabbott>
most papers start out by telling you what a chordal graph is
xp4ns3 has quit [Quit: Konversation terminated!]
teardown has quit [Remote host closed the connection]
<cwabbott>
which is sort of interesting from a historical perspective, and in connecting it to the chaitin graph-based allocator, but in practice it's irrelevant to how one actually implements an ssa-based allocator imo
<alyssa>
yeah, for sure
<alyssa>
I don't like RA being regarded as a graph problem at all, tbh
gouchi has quit [Remote host closed the connection]
<cwabbott>
iirc then papers sort-of handwave how to split live ranges
<alyssa>
Sure, graph colouring is a (useful!) approach but it's not inherently privileged as the 'natural' expression of the problem
<alyssa>
except in the history with chaitin
xp4ns3 has joined #dri-devel
<cwabbott>
like, sure, you can pre-emptively insert a parallel-copy instruction around every place where you possibly might need to split live ranges, but then compile-time performance would probably suck... since vector loads/stores are pretty common
<cwabbott>
iirc this is how the papers i've seen hand-wave away how to split live ranges
ngcortes has joined #dri-devel
xp4ns3 has quit [Quit: Konversation terminated!]
ngcortes has quit [Remote host closed the connection]
<alyssa>
out of SSA is for black belts :-(
<alyssa>
i'm like
<alyssa>
purple at best
<dschuermann>
yeah, the live-range splitting seems not interesting enough to write a paper about it, although that definitely was the hardest part
<dschuermann>
most papers also don't really care about phi coalescing
<dschuermann>
just chordal graph -> linear solution -> done :D
<alyssa>
dschuermann: this is the proble with big-O
<alyssa>
i also have a big-O "proof" that linked lists and dynarrays perform identically for backend IR's
<alyssa>
errrrr up to a constant factor 🙃
<dschuermann>
I think aco RA eats like 30% of the backend's compile time which is still 5x faster than llvm.. so :)
<alyssa>
dschuermann: 30% seems like a lot
<alyssa>
unless i guess your other passes are just that fast
<dschuermann>
both, I think ;)
<alyssa>
>:P
mlankhorst has quit [Ping timeout: 480 seconds]
<cwabbott>
dschuermann: i think i'd like to see an introduction that never ever mentions chordal graphs at all
ngcortes has joined #dri-devel
<cwabbott>
it just seems like such a huge red herring, because it makes it seem like it's related to graph-coloring RA but beyond the simplest toy examples it's not a useful way to think about it... they just trot out the chordal graphs probably because that's the context where it was initially invented
<alyssa>
100% agree
<dschuermann>
cwabbott: when writing the live-range split algorithm, I formulated it as bin packing problem. so tetris, is definitely on the table as well ;)
<bnieuwenhuizen>
wasn't there that paper on the puzzle allocator?
<alyssa>
Pereira?
<bnieuwenhuizen>
probably
<dschuermann>
yeah, but it's basically useless for real world
<cwabbott>
well, it's useful for x86 and such
<cwabbott>
just not for GPU's
<dschuermann>
for AOT maybe
<cwabbott>
i think GPU's are actually really weird for having "vector" registers that can start at any offset and have an odd size
<cwabbott>
although the framing as a puzzle def helps their solution doesn't work bc of that
<alyssa>
I guess SSA_based RA also seems really... overwhelming, and frustratingly DIY
<bnieuwenhuizen>
cwabbott: they fixed the glitch
<bnieuwenhuizen>
now they don't need to be consecutive
<dschuermann>
yeah, I thought the freedom of unaligned registers would be beneficial, but it makes it worse
<bnieuwenhuizen>
of course at significant extra encoding size cos
<alyssa>
you can wire in nir's out-of-SSA and util's graph colouring and have a good enough RA in a few hundred lines
<cwabbott>
bnieuwenhuizen: not when you can still load/store a vec3
<alyssa>
it's not clear to me you can do SSA-based RA in under 3kloc
<cwabbott>
it's just vec3 instead of vec11 :)
<alyssa>
(When you cinlude things like parallel copy lowering yourself)
<bnieuwenhuizen>
oh right
<cwabbott>
alyssa: yeah, that's true, but unfortunately i think that's gonna be the case for any RA with "grown up stuff" like live range splitting
<dschuermann>
alyssa: well, the whole point is to precalculate the register pressure to base other decisions on that
<alyssa>
cwabbott: sure.. it's more that SSA-based RA is inherently grown up, skipping live range splitting doesn't make it fundamentally easier..
<cwabbott>
alyssa: skipping live range splitting does make it a lot easier
<dschuermann>
every RA with vectors has to do live-range splitting. it if's into spill slots or within the register file
<dschuermann>
that's an inherent problem of vectors in the ISA
<cwabbott>
but that's kinda academic since you'll need to do it
<bnieuwenhuizen>
if you skip live range splitting and the other grown up stuff it is mostly "walk forward through code, assign register that is not currently in use"
<bnieuwenhuizen>
kinda linear scan on a proper cfg :)
<alyssa>
hmm
<cwabbott>
bnieuwenhuizen: yeah, "linear scan with extra steps" is exactly how i'd frame it
<bnieuwenhuizen>
cwabbott: actually wrote a "paper" about that in high school :P
<cwabbott>
there's a pretty clean separation between inter-block and intra-block concerns in both aco and ir3
tobiasjakobi has joined #dri-devel
<alyssa>
I just
<cwabbott>
and the inter-block stuff is basically linear scan + the "puzzle solver" thing
<alyssa>
don't even know how to get started with this stuff
<alyssa>
and I have a new shiny entire arch to r/e in 2 months so errr
XgF has joined #dri-devel
<alyssa>
backburner, toodle-a-loo :-p
XgF has quit [Remote host closed the connection]
mdnavare has quit []
mdnavare has joined #dri-devel
<mdnavare>
danvet: emersion:bnieuwenhuizen: What does it mean when I enable DRI_PRIME =1 and run vblank_mode=0 glxgears and get a GUI freeze with these in syslog: Jun 11 06:02:13 DUT113-DG1MRB kernel: [ 152.860813] [drm:drm_ioctl] comm="glxgears" pid=2443, dev=0xe281, auth=0, DRM_IOCTL_SYNCOBJ_CREATE
<bnieuwenhuizen>
depending on the creation flags, someone forgot to signal? Don't know know enough context
<dschuermann>
alyssa: if (nir_shader_get_entrypoint(shader)->num_blocks == 1) ssa_based_ra()
<dschuermann>
for starters ;)
<bnieuwenhuizen>
FWIW for DRI_PRIME GL stuff we don't really do cross-device syncobj stuff so might just be a problem within one driver
<mdnavare>
bnieuwenhuizen: So is there a way to disable the syncobj?
philipp641 has joined #dri-devel
<bnieuwenhuizen>
Likely not
philipp641 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-14 18:16:55)]
<bnieuwenhuizen>
maybe someone from tyour userspace driver team knows more though
<bnieuwenhuizen>
all of the ynsocjb stuff is in driver specific code in mesa at this point
<bnieuwenhuizen>
syncobj*
<alyssa>
dschuermann: hahahah
<alyssa>
fair enough
meena has joined #dri-devel
meena has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-14 18:18:45)]
Pavel-t has joined #dri-devel
Pavel-t has quit [Remote host closed the connection]
packeteer has joined #dri-devel
packeteer has quit [Remote host closed the connection]
<daniels>
cwabbott: 'I think GPU's are actually really weird for having "vector" registers that can start at any offset and have an odd size' - x86 says hi
<cwabbott>
daniels: dunno, the original paper referenced was explicitly about x86
<cwabbott>
and they didn't have to deal with this
<cwabbott>
don't think you can have a vec3 register in x86
<daniels>
that'll teach me to skim-read backlog
<daniels>
_odd_ size indeed not
shankaru has joined #dri-devel
<mareko>
vec3 in wave64 is actually 3x vec64, so not odd
<bnieuwenhuizen>
yeah I also think the int8/16/3264 always start at aligned positions in the larger register
<daniels>
the sizes may be odd in the sense of unusual, but not in the sense of (n & 1) :P
<bnieuwenhuizen>
(the fact that we can talk about a specific larger register is something you can't do on GPUs because they can literally start at every offset)
<daniels>
but you certainly get to deal with both aliasing and unnatural alignment
<bnieuwenhuizen>
on some GPUs*
<mdnavare>
bnieuwenhuizen: So this is likely because Mesa fails to signal correctly and the syncobj waits forever?
<bnieuwenhuizen>
dunno, the logs don't explicitly say that, but sounds likely that something is waiting indefinitely there
<mdnavare>
Yea and its wierd because this is not seen when vblank_mode=1 only seen when we run glxgears with vblank_mode=0
luzipher_ has joined #dri-devel
lemonzest has quit [Quit: Quitting]
luzipher__ has quit [Ping timeout: 480 seconds]
<dschuermann>
bnieuwenhuizen: int64 VGPRs can start at odd registers. SGPRs are always aligned, what makes them way easier to coalesce
<bnieuwenhuizen>
dschuermann: the int8/16/32/64 thing was directed at x86 :)
<dschuermann>
ah
<dschuermann>
of course, if you consider GCN explicit SIMD2048 (as 64*32bit), then everything is aligned :D
<bnieuwenhuizen>
dschuermann: even if you don't they're still aligned to data size up to 32-bits
<dschuermann>
for efficient live-range splits, you'd need alignment to be size and power of 2. then, you can always get away with at most <size> shuffle instructions
<dschuermann>
these unaligned vectors have a worst case of 256 (== sizeof(register file)) shuffles, and we actually do hit that in CTS
<mareko>
AVX-2048!
aswar002 has quit [Remote host closed the connection]
<bnieuwenhuizen>
mareko: avx-2048 with more useful lane masks to avoid some insanity in register allocation with non-32-bit types
<mareko>
let's not do non-32bit types
<dschuermann>
mareko: do you want to forward a request to remove packed fp16 and replace with faster execution times? :P
<alyssa>
yeah, Arm
pekkari has quit []
pjakobsson has joined #dri-devel
luzipher__ has joined #dri-devel
luzipher_ has quit [Ping timeout: 480 seconds]
txenoo has joined #dri-devel
Defender1031 has joined #dri-devel
Defender1031 has quit [Remote host closed the connection]
pochu has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<alyssa>
cross compile hell...
luzipher_ has joined #dri-devel
danvet has joined #dri-devel
sneil_ has quit []
<mareko>
dschuermann: I think 16-bit register usage is a bigger problem than execution times
rishubhjain[m] has quit [Remote host closed the connection]
luzipher_ has quit [Ping timeout: 480 seconds]
bridge[evilred] has joined #dri-devel
bridge[evilred] has quit [Remote host closed the connection]
alanc-away has joined #dri-devel
alanc has quit [Ping timeout: 480 seconds]
<jekstrand>
eric_engestrom: You around? Trying to add more sphinx docs and very confused as to how it's all supposed to work.
andrey-konovalov has quit [Ping timeout: 480 seconds]
<alyssa>
i never wanted to learn this much about the dynamic linker
<HdkR>
You /really/ don't want to learn about the dynamic linker
<HdkR>
I tried writing my own and gave up
<emersion>
i wrote my own and can confirm it's painful
<emersion>
do not recommend
<alyssa>
I er
<alyssa>
unknown type [0x13] section `.relr.dyn
<alyssa>
what...
<airlied>
isnt it just a strcmp wrapper ;-p
<alyssa>
ok, it's supported in lld but not gnu ld, fine
<alyssa>
-fuse-ld=lld makes it build
<alyssa>
./a.out segfaults
<alyssa>
there's no winning
<airlied>
oh dyn linker
<airlied>
n9t dyn loader
ddavenport has quit [Remote host closed the connection]
<alyssa>
all I want to do is link with a library built for another architecture on another operating system targeting unreleased hardware
<alyssa>
how hard can that be?! :-p
<Sachiel>
use rust and statically link everything
<alyssa>
chromeos has its own dyn linker.....
tobiasjakobi has quit [Remote host closed the connection]
ddavenport has joined #dri-devel
<zmike>
can confirm rust would've fixed all of this
<zmike>
smh
<alyssa>
yes..
<HdkR>
Moving the problems from one box to another :P
<alyssa>
WTF's per minute cranking up
<alyssa>
ld linux segfaulting should err not happen
V_PauAmma_V has joined #dri-devel
<HdkR>
Oh I do that all the time, nothing new :P
<alyssa>
HdkR: segfault jumping to an unmapped address
V_PauAmma_V has quit [Remote host closed the connection]
<HdkR>
Bad relocations?
<HdkR>
Or not understood relocation so it was skipped?
<alyssa>
I think so..
<alyssa>
The address it's trying to jump to /is/ picked up by llvm-objdump
<alyssa>
chromeos/android have a funny reloc format that linux/gcc really, really doesn't like.
cphealy has quit [Ping timeout: 480 seconds]
<alyssa>
tempted to try to yak shave away the relrs
<HdkR>
How are you going to deal with the TLS differences? :D
<alyssa>
what now
<alyssa>
oh man.. coreelec has a glibc patch for exactly this (the relocs thing)
Duke`` has quit [Ping timeout: 480 seconds]
<alyssa>
do I dare rebuild glibc?
<bnieuwenhuizen>
yes
<alyssa>
bnieuwenhuizen: it seems sssscary
<HdkR>
rebuilding glibc is one of those things that even with a threadripper I walk away from
<bnieuwenhuizen>
due to slowness or complexity?
<HdkR>
slowness
<bnieuwenhuizen>
can't be much worse than Chrome can it?
<alyssa>
bluuuugh
<HdkR>
Luckily I don't need to build chrome often :P
* alyssa
rocks
<bnieuwenhuizen>
HdkR: luckily most people need to sleep too. PErfect time to build Chrome
<HdkR>
Sounds like when I was building Android on a dual core system
<HdkR>
Sleeping in front of the laptop to catch failures
<bnieuwenhuizen>
my home workstation has significantly more cores than my work workstation. Guess on which one I'm always building Chrome :|
<alyssa>
your sleep workstation, of course
<HdkR>
haha, typical
<alyssa>
maybe i should just snag a libreelec rootfs... no, that's silly... or is it?
<alyssa>
looks like libreelec has 3 different patches for this ... blugh
<mattst88>
HdkR: multilib (32- and 64-bit) builds of glibc take < 7 minutes on an 8 year old quad-core haswell system
<HdkR>
Oh, it might be the check that takes forever then
<mattst88>
it used to be much more comparable to a gcc build, but now gcc is like 50 minutes for me
Penagwin24 has joined #dri-devel
<jekstrand>
eric_engestrom, kusma: Just posted an MR to add some more docs. Includes a really bad stab at doxygen integration. I'd love it if I could get some help with doing that in such a way that GitLab CI website auto-rebuilding and readthedocs both work.
Penagwin24 has quit [Remote host closed the connection]
ddavenport has quit [Remote host closed the connection]
<alyssa>
mattst88: when will hsw be marked EoL and renamed "hadwell"?
<alyssa>
:-p
<Sachiel>
I need a week off to recover from that one
<mattst88>
lol
<kisak>
alyssa: Intel graphics get marked EoL?
<jekstrand>
gm45 will live forever!
<dcbaker>
oh please, can we mark i915 (gen3) as EoL?
<dcbaker>
what about i8xx?
<dcbaker>
i7xx?
<ccr>
gray havens is calling
<jekstrand>
dcbaker: anholt is working on i915g
<dcbaker>
I know, but not for i8xx support like i915
<dcbaker>
... I hope
* airlied
wonders where my i810 and i855 went
<anholt>
right, imo users are better off with swrast than i8xx 3d
ddavenport has joined #dri-devel
<dcbaker>
Users are better off with a pci card from the garbage than i8xx... lol
<bnieuwenhuizen>
even dGPUs from the dumpster are priced high these days ;)
shankaru has quit []
luzipher_ has joined #dri-devel
<dcbaker>
Given that r100 is a huge improvement over i8xx...
<kisak>
jekstrand: the more that nvidia backs off driver support for cards that run well on nouveau, the more users that will try to use nouveau in the wild.
<mattst88>
O_o
<mattst88>
what in the world?
NiksDev2 has quit [Ping timeout: 480 seconds]
luzipher__ has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
gruetzkopf has quit [Quit: quit]
gruetzkopf has joined #dri-devel
gruetzkopf is now known as Guest2154
i-garrison has quit []
gpoo has quit [Quit: Leaving]
gpoo has joined #dri-devel
ddavenport has quit [Remote host closed the connection]