<MrCooper>
FLHerne: 2D acceleration in the X server is required for any HW accelerated direct rendering, so radeonsi is required for AMD GPUs (until glamor can work with zink)
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
<vsyrjala>
MrCooper: is there some fundemental reason for that? obviously you'd need to get at the bo with the cpu, but i thought dma-buf had some kind of generic mmap thing
rgallaispou has joined #dri-devel
<airlied>
karolherbst: btw I mentioned before but verified now, the non 8-bit packed formats are wrong on your branch, 555, 565,101010, 1010102
<airlied>
karolherbst: pushed a fix into your branch for now, I'll merge it backwards later
<MrCooper>
vsyrjala: it can perform worse than without any acceleration in some cases (which is why I think allowing mmap of dma-buf fds was a mistake, classic footgun)
<vsyrjala>
sure. performance would suck
<MrCooper>
xf86-video-amdgpu supports Option "AccelMethod" "none", if anyone wants to try it (assuming it's currently working, which isn't very likely)
<vsyrjala>
sna has it as well. not sure i've actually used it once :) ah, maybe i did during some early hw/simulation bringup
<clever>
MrCooper: that reminds me, i had problems on my amd card years ago, 2d(plain xterm!) had horrible performance but 3d worked, and if i turned accel off in xorg.conf, 2d was great, but i obviously lost 3d
<clever>
MrCooper: the problem turned out to be that some optional library within xorg, got merged into xorg proper, but my distro was using the ancient external version of it, from before those bugs got fixed
<clever>
so the solution was to build xorg itself (or was it mesa?) with a --enable flag, and to skip the external version
<MrCooper>
vsyrjala: Intel iGPUs are special, it's probably not so bad there
<MrCooper>
clever: sounds like glamor
thellstrom has quit [Ping timeout: 480 seconds]
<clever>
2016-10-25 08:56:36< clever> using the in-tree glamor instead of the deprecated repo fixed them
<clever>
MrCooper: yep, that was it exactly
<clever>
once i had a keyword, finding that old convo in my irc logs was easy
rasterman has joined #dri-devel
pcercuei has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
gio has joined #dri-devel
oneforall2 has quit [Quit: Leaving]
gawin has joined #dri-devel
<pinchartl>
karolherbst: out of curiosity, I wonder how you ended up handling the gitlab SoB issue. there's currently a requirement in linux-next that every commit must be signed by the committer. with a bot rebasing branches, the committer will be the bot, and a SoB line for a bot is dubious from a legal point of view
Ahuj has joined #dri-devel
oneforall2 has joined #dri-devel
thellstrom has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
kts has joined #dri-devel
thellstrom1 has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
mnadrian has quit [Ping timeout: 480 seconds]
cwabbott_ has quit []
cwabbott_ has joined #dri-devel
cwabbott_ has quit []
cwabbott has joined #dri-devel
thellstrom1 has quit []
unsolo has joined #dri-devel
unsolo_ has quit [Ping timeout: 480 seconds]
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
kts_ has quit []
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
orbea1 has joined #dri-devel
orbea has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
JohnnyonFlame has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
unsolo_ has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
hikiko_ has joined #dri-devel
hikiko has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
flacks has quit [Read error: Connection reset by peer]
flacks has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
itoral has quit []
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
vivijim has joined #dri-devel
Peste_Bubonica has joined #dri-devel
Terman has quit [Remote host closed the connection]
camus1 has joined #dri-devel
Terman has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
<karolherbst>
pinchartl: not using any bot for now
<karolherbst>
but the commiter is also a valid concern.. mhh
fxkamd has joined #dri-devel
<karolherbst>
airlied: ahh.. weird
<pinchartl>
maybe the right answer to that is to change the kernel workflow, and stop requiring an SoB line from the committer when the committer is a bot
<pinchartl>
but if the issue is ignored (or just overlooked) then you'll get angry feedback to the first pull request :-)
<pinchartl>
(linux-next has a bot that checks that)
<karolherbst>
airlied: also.. you want to add your red hat email address to your gitlab account :D
<karolherbst>
pinchartl: right.. for now I just did most of the bits manually. Using dim to apply patches, pushed them to a branch, pushed it through gitlab CI and applied them manually into drm-misc
<karolherbst>
the CI compile checking every commit and running checkpatch is kind of worth it..
<karolherbst>
but yeah..
<karolherbst>
next step would be to reduce the pain from this
<karolherbst>
anyway.. if we want to discuss this upstream, then airlied or danvet have to be part of the discussion, otherwise I doubt it would have enough weight, that people would care much? dunno
sumits has joined #dri-devel
hansg has quit [Quit: Leaving]
unsolo has joined #dri-devel
unsolo_ has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: Do I need an environment variable for llvmpipe opencl?
<jekstrand>
airlied: ^^
<karolherbst>
LP_CL=1 afaik
<jekstrand>
thanks
<pinchartl>
karolherbst: the part where you could expect push back upstream would be the rebase itself, as Linus considers rebase bad. if that part of the workflow gets accepted, I think the committer and SoB lines will just be technicalities
<karolherbst>
pinchartl: huh? what's so bad about rebases
<karolherbst>
I mean.. that we can't do it on Linus level, okay, but generally?
orbea1 has quit []
orbea has joined #dri-devel
<pinchartl>
multiple things. beside the fact that it's painful for people who use your branch when you rebase it (but I don't think that would apply here), there's the fact that a branch has been tested with a certain base. rebasing thus (in theory at least) invalidate (part of) the testing, and thus the Tested-by tags. of course, when testing is automated, tests would re-run on the rebased branch, so this is a
<pinchartl>
different situation than when Linus complained about rebases originally
<pinchartl>
why rebase and not merge btw ?
<pinchartl>
any particular reason ?
<karolherbst>
ahh
<karolherbst>
yeah... mhh
<karolherbst>
I mean.. today we already have invalid Tested-by tags by this definition :p
<karolherbst>
you review patches on the ML and test it based on some random state
<pinchartl>
(I have a vested interest here, we're wondering whether to rebase or merge in libcamera, so any feedback from experience is useful)
<pinchartl>
I can't disagree with you on that :-)
<karolherbst>
I think it matters more if you do things cross subsystem
<pinchartl>
(although I think Linus was complaining more about maintainers performing rebases later during the process, but I could be wrong, don't quote me on that)
<karolherbst>
well, Linux wouldn't scale if we would have to rebase
<karolherbst>
and merges outside of a subsystem boundary does make sense
<karolherbst>
and I think doing rebases in MRs inside a subsystem is fine
<karolherbst>
but we should also still do merges on a drm level when merging all the sub trees (intel, adm, drm-misc, etc...)
<karolherbst>
so that's all fine
<karolherbst>
atm I just focus on the workflow of a single driver
JohnnyonFlame has joined #dri-devel
<pinchartl>
but even at the lowest level, are there pros & cons for rebases vs. merges ?
<karolherbst>
rebases lead to a easy to follow timeline
<karolherbst>
and makes git bisect less annoying
<pinchartl>
(assuming we're talking about pull requests, not branches that other people then build upon)
<karolherbst>
merge is easier from a workflow perspective
<karolherbst>
think about hundreds of open MRs where you would have to retarget every kernel release
<pinchartl>
in either case there's an authorship and SoB issue, either for the committer of rebased commits, or for the committer and author of the merge
<karolherbst>
ye
<karolherbst>
s
<karolherbst>
those are all valid concerns
<zmike>
eric_engestrom / dcbaker: what do the stable scripts actually scan for in the commit log for cc stable?
<zmike>
like if I do "cc mesa-stable" will that be caught?
<jekstrand>
tarceri: It seems like a NIR change broke GLSL serialization
<jekstrand>
That seems bad
<jekstrand>
Like we've got a nasty layering violation somewhere
<jekstrand>
It's related to the NIR linking stuff
<jekstrand>
Why would NIR linking changes break glsl serialization?
danvet has joined #dri-devel
nchery has joined #dri-devel
lplc has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<jekstrand>
karolherbst: Trying to remember some bindless details... I know samplers can be in structs in GLSL but can images when they're not bindless?
unsolo_ has joined #dri-devel
flto has quit [Read error: Connection reset by peer]
unsolo has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
flto has joined #dri-devel
<dcbaker>
zmike: A regex like `\s*[Cc]{2}:\s*(\d+\.\d+)\s*mesa-stable.*`
<dcbaker>
I really keep meaning to add a `stable: X.Y` tag to replace the CC, but so many things to work on...
mlankhorst has quit [Ping timeout: 480 seconds]
dongwonk has joined #dri-devel
<karolherbst>
jekstrand: uhm... I think yes
<karolherbst>
but we assume they are not part of the structs and extract those
<karolherbst>
we have some glsl lowering for it
<karolherbst>
because I think they don't take away any storage to begin with
<jekstrand>
Yeah
<karolherbst>
I assume same is true for images
<karolherbst>
but maybe it doesn't work, because images are that special.. dunno
kenjigashu has quit []
<karolherbst>
jekstrand: wait.. we have piglit tests for this I think
<jekstrand>
Don't start reviewing just yet. I posted the MR mostly so I can start running it in CI and seeing what explodes. :D
<jekstrand>
But if you wanted to give feedback on the first couple patches and general scheme, feel free.
<jekstrand>
And, yeah, there's plenty of room for debate about whether it should be nir_var_texture or nir_var_sampler. I picked one. If there's strong agreement that it should go the other direction, I guess I could be convinced.
anujp has quit [Ping timeout: 480 seconds]
unerlige has joined #dri-devel
shashank1202 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
alyssa has joined #dri-devel
nchery has quit [Remote host closed the connection]
<alyssa>
identify KBti0Xdbit_yyoL_6Tb3
<alyssa>
ah shoto.
<alyssa>
*shoot
orbea1 has joined #dri-devel
orbea1 has quit []
orbea has quit [Ping timeout: 480 seconds]
<pinchartl>
alyssa: we've all been there, done that
<pinchartl>
one of the reasons one should not pick an embarassing password
orbea has joined #dri-devel
<alyssa>
sendpass alyssa hunter3
<CounterPillow>
for me, it's hunter2.
<vsyrjala>
huh. gitlab auto closes bugs when i push something with the closes: tag? that's almost nice, except it just says "@foo closed X hours ago". no link to the actual commit that closed it that i can see? am i just blind?
ybogdano has quit [Remote host closed the connection]
<emersion>
there should be a link
<emersion>
the commit hash should be clickable
<pinchartl>
it reminds me of a friend of mine who, when she was young, picked an e-mail address that would roughly translate to emberpanties@hotmail.fr, without realizing how it could be construed (not sure how she meant it in the first place though, but knowing her, I'm sure there was no innuendo). when she graduated and started job hunting, she realized her mistake
<vsyrjala>
it does have some kind of hash on it, but it just jumps around a bit inside the bug report instead of going to any git repo/etc.
<pinchartl>
passwords are less public, but still :-)
<emersion>
" Pekka Paalanen closed via commit 51d336ec 3 months ago"
<emersion>
the date link is the permalink to the item in the issue timeline
<vsyrjala>
i have no commit has on my link. and it was definitely autoclosed by gitlab. i was just going there to close it when i noticed it had magically closed already
<vsyrjala>
maybe igt+gitlab is somehow broken
* vsyrjala
goes look for older closes: tagsff...
camus has joined #dri-devel
<vsyrjala>
hmm. found a few with the link, but more where it has no link
<vsyrjala>
daniels: ^ do you know what could cause the commit link to not be there when gitlab closes a bug due to Closes: tag?
<karolherbst>
alyssa: are you happy? :D You now have a good reason to spend $4k on a new high end laptop :P
<cmarcelo>
jekstrand: ok
camus1 has quit [Ping timeout: 480 seconds]
<alyssa>
karolherbst: ?
<karolherbst>
alyssa: m1 max
<karolherbst>
wait
<karolherbst>
did you miss the apple event today?
<alyssa>
i have 5 uni classes and a job
<karolherbst>
so? I did nouveau work while in the uni :D
<karolherbst>
anyway
<karolherbst>
there are new m1 chips: m1 pro and m1 max
<karolherbst>
dunno if the gpus are any different, but sounded like it
<pinchartl>
have they announced they will replace macos with linux, or should I keep dismissing apple as <explitive removed> ?
<pinchartl>
s/explitive/expletive/
<karolherbst>
they did not
<pinchartl>
well
<pinchartl>
my hopes were not high, so I'm not disappointed :-)
<karolherbst>
I put it like this: theyr new laptops will take over the entire laptop market
<karolherbst>
there is no alternative to theirs anymore
<vsyrjala>
lemme know when they start making thinkpads
<pinchartl>
let me know they start thinking about their users :-)
<pinchartl>
s/know/know when/
<pinchartl>
(as something else than wallets on legs)
<pinchartl>
I've been forced to use a macbook recently to connect to a customer VPN. I was taken aback by how bad the OS is, it's worse than I had imagined
<alyssa>
pinchartl: legs?
<pinchartl>
as for the hardware, I suppose it's better (can't be worse)
<alyssa>
apple accepts wallets of all body shapes
<pinchartl>
alyssa: a French expression I suppose
<karolherbst>
vsyrjala: thinkpads are something people want? I alwyas considered them bad laptops :D
<karolherbst>
they are loud
pnowack has quit [Quit: pnowack]
<karolherbst>
and clumby
<karolherbst>
and look bad
<karolherbst>
everything I despise in laptops
<vsyrjala>
can't live without the nipple. at least if i have to use any gui stuff
<karolherbst>
ehh
<karolherbst>
that hw feature sounds like as important as literally all other 500 hw features if you ask thinkpad users :p
<karolherbst>
I think there are more important ones, like fans not spinning
<FLHerne>
It is though
<karolherbst>
FLHerne: ever worked an entire day with a laptop which didn't spin up its fans at all?
* pinchartl
goes to get the popcorn and listen to the "debate" :-)
<FLHerne>
My Thinkpad fan wasn't *that* loud, after I replaced it with one from a different model and then dismantled it and adjusted the blades and added a custom-made mounting spacer
<karolherbst>
:D
<karolherbst>
if you can hear it, it's too loud
<karolherbst>
:D
<karolherbst>
but yeah..
<karolherbst>
heck
<karolherbst>
that you even have to mod the hw :D
<FLHerne>
(that was a T420s)
<karolherbst>
no.. thinkpads are just loud
<karolherbst>
dunno why
<karolherbst>
they spin up just because I opened a web browser
<FLHerne>
well, you can configure the fan curve
<pinchartl>
karolherbst: come on, you have to concede that apple fans are the loudest
<FLHerne>
there's a little daemon for that
<CounterPillow>
lol
<pinchartl>
(I'm talking about people)
<karolherbst>
pinchartl: true, they make up for their silent laptops
<sven>
lol
<karolherbst>
can't have everything
* vsyrjala
opens the browser
<vsyrjala>
fan idn't spin yet
<karolherbst>
FLHerne: why do I _have_ to configure any of this
<karolherbst>
I don't want to :D
<pinchartl>
I'd rather have a very loud laptop, at least the machine isn't arrogant and obnoxious ;-)
<karolherbst>
it should just work out of the box
<vsyrjala>
"out of the box" right after you'v ereverse engineered the gpu and writtent drivers for it :)
<karolherbst>
so you say, a laptop where I have to replace the fan, mod the case, configure some stupid daemon is better than a laptop which is silent out of the box, just because it's a thinkpad? right... :P
<FLHerne>
You know this is a Linux graphics channel, right? :p
<karolherbst>
vsyrjala: :D
<karolherbst>
FLHerne: I can still say that most laptops are shit
dongwonk has quit [Ping timeout: 480 seconds]
<CounterPillow>
#dri-devel has been closed due to the sunset of the Linux project in the face of Apple's absolute dominance in the laptop segment, sorry kids
<alyssa>
CounterPillow: Hold my beer.
<pinchartl>
all computers are, and all software is. I'm sure everybody knows that
<karolherbst>
alyssa: yeah, if linux works nicelys on the macbooks, I'd even buy one
<karolherbst>
apple should pay you for getting the 0.5% linux users to use macbooks :P
<alyssa>
lol
<karolherbst>
alyssa: see it like this: for apple it means more money, but also more rumours, and you get stripped of the fun of rever..... okay, I see, bad idea
phinxy has joined #dri-devel
<anarsoul>
karolherbst: there's no widevine for aarch64 yet, so no netflix/disney+/amazon prime/spotify on macbooks running linux as of now
nchery has joined #dri-devel
<HdkR>
Android TV disagrees with that statement
<HdkR>
:>
<karolherbst>
anarsoul: sw can be written
<anarsoul>
HdkR: I'm pretty sure android TV uses native apps for these, not browser + widevine
<karolherbst>
it's more or less the same under the hood
<anarsoul>
karolherbst: yeah, the thing is widevine is closed-source and owned by google
<karolherbst>
at least on android it is also called widevine
<karolherbst>
anarsoul: well... yes
camus1 has joined #dri-devel
dongwonk has joined #dri-devel
Ahuj has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
pnowack has joined #dri-devel
<jenatali>
jekstrand: cool. I'm out of town for a week so probably won't have any real feedback til next week
<jekstrand>
jenatali: That's fine. This one can sit and bake. It'll probably take time for me to get it passing CI anyway.
<jenatali>
Sounds good
dongwonk has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
dongwonk has joined #dri-devel
<jekstrand>
jenatali: That's fine. This one can sit and bake. It'll probably take time for me to get it passing CI anyway.
<jekstrand>
sorry. Wrong window
dongwonk_ has joined #dri-devel
dongwonk has quit [Ping timeout: 480 seconds]
<eric_engestrom>
alyssa: did you end up adding `cc: mesa-stable` to that bugfix MR of yours?
<eric_engestrom>
if you've merged it without the tag, just give me the link and I'll cherry-pick the commits ;)
mlankhorst has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
phinxy has quit []
Daanct12 has quit [Quit: Quitting]
Danct12 has quit [Ping timeout: 480 seconds]
elongbug has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<airlied>
karolherbst: any specific reason why the sampler patch is WIP? was there something you were unhappy with?
<alyssa>
eric_engestrom: it was point out that it regressed some piglits due to unmasking another bug, but the bug fix regressed even more piglits due to possibly a third bug and.....
<alyssa>
so no still not merged :(
<eric_engestrom>
ah, sounds like you'll have a lot of fun with this one
<eric_engestrom>
good luck (:
<alyssa>
srsly
<alyssa>
there are at least 4 distinct bugs, 3 of which affect hw that's shipping in prod (:
Duke`` has quit [Ping timeout: 480 seconds]
mclasen has quit [Remote host closed the connection]
mclasen has joined #dri-devel
<karolherbst>
airlied: ehh.. it always felt like a hack
<karolherbst>
but it went through a few iterations
zackr has quit [Remote host closed the connection]
<airlied>
karolherbst: a hack how, had you a better idea for how it might look?
<karolherbst>
that's the problem, I have no better idea
<karolherbst>
I hoped somebody else has a better one :)
<airlied>
okay I'll stare at it a bit and see if I can come up with a better one, going to land the formats stuff soon, since it seems reasonable now, and passes tests
<karolherbst>
but I think there was also a potential problem somewhere
<karolherbst>
something with order of args or something
<karolherbst>
but as long as things are passing... dunno
<airlied>
I had to fixup the format/order patch on top of jekstrand latest changes, which took me a little while to realise yesterday
<jekstrand>
-/
<jekstrand>
:-/
<alyssa>
:p
<alyssa>
oops
danvet has quit [Ping timeout: 480 seconds]
sravn has quit [Quit: WeeChat 3.0.1]
Ahuj has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
gouchi has quit [Remote host closed the connection]
rasterman has joined #dri-devel
pnowack has quit [Quit: pnowack]
zackr has joined #dri-devel
rasterman has quit []
sadlerap has joined #dri-devel
<airlied>
okay the 1.2 image wip is now mostly just wip
<airlied>
and a misc nouveau patch
<cmarcelo>
I'm moving code from N files with different copyright lines into a single file. (1) should I just make an union of all the copyright lines for the new file? (2) for cases of same company and different years, should I consolidate in one line (e.g. 2009, 2011)?
<cmarcelo>
(this is the mesa repo)
<cmarcelo>
in the mesa repo
<karolherbst>
nice.. marge timed out because cloning a kernel tree won't work in 120 seconds
<karolherbst>
:D
<karolherbst>
uhhh
<karolherbst>
and now it uses ssh even though I told it to use https...
<eric_engestrom>
cmarcelo: yeah, I think doing a union is the right thing there (of both the copyright lines and the years within a copyright holder)
xexaxo_ has quit [Remote host closed the connection]
xexaxo_ has joined #dri-devel
kenjigashu has joined #dri-devel
kenjigashu has quit [Remote host closed the connection]
<alyssa>
karolherbst: get a faster connection
<alyssa>
or a microkernel
<alyssa>
:p
<robclark>
true, I imagine hurd is a smaller codebase than the linux git tree
gio has quit [Ping timeout: 480 seconds]
<alyssa>
robclark: Hey I can make Linux smaller too
<alyssa>
Just drop all those AMD register headers, what could go wrong? :-p
kenjigashu has joined #dri-devel
gio has joined #dri-devel
<FLHerne>
Do they *really* need those enormous headers? It seems crazy
nchery has quit [Quit: Leaving]
camus has joined #dri-devel
urja has quit [Remote host closed the connection]
urja has joined #dri-devel
pcercuei has quit [Quit: dodo]
camus1 has quit [Ping timeout: 480 seconds]
kenjigashu has quit []
<airlied>
alyssa: they compress really well for git
tursulin has quit [Remote host closed the connection]
<alyssa>
airlied: 270M of my disk is drivers/gpu/drm/amd
<alyssa>
This is a 32GB laptop
<alyssa>
(For reference, linux/.git is 4.3G)
<airlied>
if you don't build them just rm them :-P, though building a kernel on a 32GB laptop is going to be tight
<alyssa>
(And linux/ is 6.5GB)
<airlied>
maybe we should ship them gzipped, and make gcc support gzipped headers :P
<alyssa>
:D
<alyssa>
I just think it's wild that 12% of my kernel sources are AMD gfx stack.
<alyssa>
Or more to the point that, that 80% of drivers/gpu is AMD
<FLHerne>
airlied: How much of them could be generated at build time with a 20-line shell script?
<FLHerne>
(if the hardware team didn't revolt at the mere suggestion of not using The Official Tables)
<airlied>
0, unless we include an equally large xml database
<bnieuwenhuizen>
I think the biggest win would probably be deduping them, the headers are like 90% the same between gens
<airlied>
but really it's only a major problem for people crazy enough to build kernels on 32GB disks :P
<bnieuwenhuizen>
airlied: 32GiB is a lot if you have a ramdisk for CI
<airlied>
if you are doing CI you probably have much larger worries
<bnieuwenhuizen>
touche
* airlied
runs out of space more often because I've left a perf.data or core file sitting around
<airlied>
-rw-------. 1 root root 462502388 Aug 2 2017 perf.data.old
<bnieuwenhuizen>
you're clearly not using enough renderdoc
<airlied>
that's been sitting there for 4 years and I keep running out of disk space on that machine
<airlied>
the next biggest file is a renderdoc trace :-P
<bnieuwenhuizen>
also 4 years old?
<airlied>
5 :-P
<airlied>
some early days radv dev box then
<bnieuwenhuizen>
wow, that'd be summer when we started radv?
* airlied
bets on it being a talos scene
<airlied>
karolherbst: so I suppose on AMD hw and maybe others it might make sense to wire inline samplers through nir into the backend compiler
<airlied>
but I think that should be an optimisation