<jenatali>
karolherbst: You'll probably have to remind me next week :)
gawin has quit [Ping timeout: 480 seconds]
<karolherbst>
oh I will :D I might even add more changes, because apparently that `dladdr` trick won't work if you don't add `fPIC` or something 🙃 but maybe I can also ignore systems not suing fPIC....
lyudess has quit []
Lyude has joined #dri-devel
<tzimmermann>
jfalempe, i briefly looked over it, but didn't understand the point
<jfalempe>
tzimmermann, it's really the Write-Combine of the internal RAM that affect the latency.
<jfalempe>
so for latency-critical application, we should have a way to disable it.
<tzimmermann>
last time we discussed this, we already knew that WC mode triggered the problem.
<jfalempe>
tzimmermann, yes but last time, it was the WC of the system RAM, which doesn't make much sense.
<tzimmermann>
the actual problem is that the RT process is not suffciently isolated from non-RT parts
<tzimmermann>
no amount of papering over will fix this
<jfalempe>
or that the WC mechanism of the CPU is not good enough to achieve good latency.
<jfalempe>
(in case of slow PCI device like MGA)
<tzimmermann>
you don't understand. the RT feature is not a function of the underlying hardware
<tzimmermann>
it comes from the design of the system as a whole
<jfalempe>
and software workaround for broken hardware is quite common I think.
<tzimmermann>
that hardware is not broken
<tzimmermann>
my first question is: why does the terminal interfere with the RT process?
<jfalempe>
it's not terminal related, even without VT/fbcon, writing to the video memory of the matrox interfere with RT process.
<tzimmermann>
yes, why?
<jfalempe>
I think when the CPU flushes the write combine buffer, it locks the whole PCI bus.
<tzimmermann>
that's what I mean: this is a problem of the system's overall design
<tzimmermann>
the designer of the RT system needs to take this into account
yyds has quit [Remote host closed the connection]
<jfalempe>
tzimmermann, it used to work with older kernel
<jfalempe>
they see that as a regression in the mgag200 driver.
<tzimmermann>
there's plenty of research out there, about how to make the individual HW components compatible with RT requirements by design (not merely by implementation)
<jfalempe>
I think mapping system RAM as WC, probably makes it disable WC on the mgag200 RAM, since copying from WC to WC memory is not possible.
<tzimmermann>
hence, i don't want patches that paper over problems that someone caused by mis-designing their computer system
<tzimmermann>
i think this patch should go into RHEL kernels for your customer, but not into upstream
simondnnsn has joined #dri-devel
<jfalempe>
We always try to upstream first, so that it can benefit all Linux users.
<tzimmermann>
how often do i have to say it: AFAICT this problem is happens because of your customer's system's poor design. it's not a problem that generally happens in the wild
<jfalempe>
For me it's more a compromise between performance or latency. the hardware allows to do both, but not at the same time. And users should be able to choose what fits their usage.
<tzimmermann>
if the system was correctly designed, it would take the PCI write's WCET into account. which seems to be 40 usec according to your measurements
<tzimmermann>
the system designer overcommitted to 10 usec AFAICT, hence it now fails its deadlines
Company has quit [Quit: Leaving]
aravind has quit [Ping timeout: 480 seconds]
<jfalempe>
tzimmermann, yes we can say don't use Matrox as it is outdated hardware, then why having a driver for it ?
<tzimmermann>
jfalempe, would you please try to address my points and concerns instead of shifting the topic
<jfalempe>
tzimmermann, the problem is that Matrox are not discrete GPU, so you can't remove it and put something else when you design such system.
<tzimmermann>
no, the problem is that the system's designer didn't even take the PCI write's WCET into account
simondnnsn has quit [Ping timeout: 480 seconds]
<jfalempe>
it's working fine for other PCIE hardware, only Matrox slows the bus down.
macromorgan_ has quit []
macromorgan has joined #dri-devel
<tzimmermann>
the designer still needs to take this into account
<tzimmermann>
as i said before. RT systems are designed; not just installed
<jfalempe>
Aspeed also uses Write Combine, and don't have such issue.
illwieckz has quit [Quit: I'll be back!]
<tzimmermann>
an RT system with aspeed is something else and needs its own design and planning
<mripard>
tzimmermann: how the system was (poorly) designed is irrelevant. it's a regression, period.
<tzimmermann>
mripard, we never gave any guarantees
<mripard>
could they have done better? probably. But it was working so far, and it should keep working. Anything short of that is super user hostile.
<mripard>
sure, but that's true for pretty much the entire kernel
kts has joined #dri-devel
<mripard>
it's even said so in the license
<mripard>
I'm still not sure how that's relevant
Duke`` has joined #dri-devel
<tzimmermann>
mripard, i'm not arguing against redhat shipping this patch in their kernels
<mripard>
so if someone was to reproduce that with a mainline kernel, you would consider patching it?
alatiera has joined #dri-devel
<jfalempe>
mripard, I've run the test with a mainline kernel. I always do that before sending thing upstream.
<mripard>
jfalempe: I know :)
<mripard>
that you're working for redhat is irrelevant too.
<tzimmermann>
mripard, this happens on mainline. to be clear, i'm not opposing performance fixes. if the general performance of the driver would go down, we could simply revert original patch. but this case happens in a single RT system where someone apparently overcommitted a resource. since we don't evern know what causes the interference, we cannot be sure that the patch even fixes the problem
<mripard>
it's something that used to work fine and doesn't. On mainline. It's a regression. It doesn't get simpler than that
<tzimmermann>
it's not, unfortunately
illwieckz has joined #dri-devel
<mripard>
ok, so what level of explanation do you want to consider fixing that issue (or merging a patch that would) ?
<tzimmermann>
i'd first want to know how exactly the drm driver interferes with the RT process. because that's still unclear
<jfalempe>
tzimmermann, we reproduced it on multiple servers. It's just the one I have at home can't reproduce it, so it took me some time to get access to an affected server.
<tzimmermann>
jfalempe, are they all the same?
djbw has joined #dri-devel
<jfalempe>
tzimmermann, let me check, but I'm pretty sure some HP and Dell systems have the issue.
<tzimmermann>
if this problem would affect every other user and/or use case, the patch would be a no-brainer
kts has quit [Quit: Leaving]
pzanoni has joined #dri-devel
<jfalempe>
tzimmermann, at least one Supermicro Icelake server is affected. And I tested on a HP ProLiant DL110
<tzimmermann>
jfalempe, they both run the same userspace, i assume?
<jfalempe>
tzimmermann, yes
<tzimmermann>
jfalempe, i do have a dl120. maybe i can do a local test
krushia has joined #dri-devel
<tzimmermann>
if this happens with physical vram (accordin to your email), it might affect other systems or processes. that would mean we should have a blacklist of system or something like this.
<tzimmermann>
jfalempe, i have to quite for today. let's talk tomorrow.
<jfalempe>
tzimmermann, you also need to write 0 to /dev/cpu_dma_latency if you want to reproduce low latency.
<jfalempe>
tzimmermann, ok thanks.
tzimmermann has quit [Quit: Leaving]
kts has joined #dri-devel
Fijxu has quit [Ping timeout: 480 seconds]
greenjustin has joined #dri-devel
<MrCooper>
emersion: in case you're not aware, Markus Elfring is known for submitting mostly non-sense patches, and trying to start pointless arguments when called out
simondnnsn has joined #dri-devel
<emersion>
ah, ok
<ccr>
ehh. googling that name brought up a bizarre discussion on SQLite development forum.
kts has quit [Quit: Leaving]
<zmike>
mareko: ok so reading through that it looks like mostly I should just be replacing pb_buffer with pb_buffer_lean?
kzd has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<mareko>
zmike: the perf is in the BO fence tracking, 1-level slabs, and delayed unique_id initialization for slabs
<mareko>
slab entries that is
<zmike>
hm
macslayer has joined #dri-devel
<mareko>
if you don't track fences per BOs, you can skip that one
<zmike>
yeah
<zmike>
the struggle to remember how to graphics after a long break is real 🤕
jeeeun841351908 has quit []
jeeeun841351908 has joined #dri-devel
jaro-AT has joined #dri-devel
jaro-AT has left #dri-devel [#dri-devel]
ZeZu has quit [Ping timeout: 480 seconds]
ZeZu has joined #dri-devel
<mareko>
a distant goal might be to make zink work with viewperf13+2020
<mareko>
DavidHeidelberg: how close are we to increasing the libdrm version in mesa?
<zmike>
it doesn't work already?
<zmike>
mareko: is this through wine? or is there a native version
jsa has quit [Remote host closed the connection]
heat has joined #dri-devel
<JoshuaAshton>
If I send something to amd-gfx but forgot a Fixes tag and it was applied already, is there a way to tag something as "probably should be backported"?
<JoshuaAshton>
Or is it too late :frog:
tango_ has quit [Read error: Connection reset by peer]
<kisak>
until it goes upstream to torvalds, it's a negotiation with the subsystem maintainer?
<mareko>
zmike: there is a native version, free for ISVs
<zmike>
ah
<zmike>
that explains it
<zmike>
do I have to contact them or something? I didn't see it on the site
<mareko>
no
<mareko>
and it doesn't work
<zmike>
haha
<zmike>
distant goal indeed
<mareko>
it's still good for testing performance because the testing can be automated, it takes me 50 minutes while AFK to run both viewperf suites, gputest, unigine and some others
<zmike>
so you run in wine?
<mareko>
never
<zmike>
then I'm confused...you said the native version doesn't work?
<mareko>
there is a native version, and it doesn't work with zink only
<zmike>
ah
<zmike>
yes
<zmike>
I'm trying to find that native version now to download and test
<zmike>
since I'm acting in the capacity of FDO it's probably fine
<mareko>
all work I do outside of my office hours is still owned by AMD
<zmike>
not the case for me
<JoshuaAshton>
I would recommend contacting them to be certain
<JoshuaAshton>
Valve is a computer hardware and software vendor
<zmike>
that's true, but this would only affect my billable hours
<zmike>
when I take off my Big Triangle hat, I am again just an unwashed plebeian hobbyist like everyone else
<JoshuaAshton>
Can you be a vendor of free software
<JoshuaAshton>
Many philosophical questions
<zmike>
deep thoughts
<Lynne>
in ffmpeg, we have an Elvis Presley, a pseudonym used by anyone who cannot publish their work for one reason or another
<zmike>
tremendous
<JoshuaAshton>
Sounds like crappy situation to be in *badum tiss*
<zmike>
maybe we should have Gordon Fr33man
<mareko>
zmike: since you said it, you can't use that name now ;)
<zmike>
dang, it'll be a real challenge to come up with something else
<zmike>
that's all for the distant future though, cuz for now I've got at least 6 hours of lavapipe cts to push through
<airlied>
only 6? I had 18hrs projected run yesterday :-P, but I ctrl-c once I paged back in the horror show I'd forgotten about over break
<zmike>
🤕
<airlied>
atexit is the devil
<zmike>
yes
<airlied>
atexit with piglit test + glthread + tc + zink + lavapipe + llvm is quite the horrors
<mareko>
just llvm
<airlied>
piglit test renders a frame then exits, the exit causes atexits to be called, one of which destroys the context which flushes the rendered frame
<airlied>
but only after llvm atexit has been called
<mareko>
you need ac_llvm_run_atexit_for_destructors
<airlied>
oh that does look like it might fix it
<airlied>
thanks, that might save my sanity
krushia has quit [Quit: Konversation terminated!]
krushia has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<mareko>
np
iive has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
anzel has joined #dri-devel
<agd5f>
JoshuaAshton, we can add the tags when it gets applied. Just waiting for the display team to review it
mvlad has quit [Remote host closed the connection]
<mareko>
vulkan on softpipe when? ;)
* zmike
whacks mareko with the newspaper again
<zmike>
no.
<airlied>
I'd rather rm softpipe :-P
<mareko>
but you could make it faster by replacing TGSI with a NIR interpreter ;)
<JoshuaAshton>
agd5f: Thanks!
<airlied>
not sure it would be faster, but you could make it something else :-P
<airlied>
maybe someone could add MSAA
<airlied>
(narrator: I wrote softpipe msaa once, and got it 99% of the way before I noped out)
theanorak_ has joined #dri-devel
<theanorak_>
hello!
<theanorak_>
i hope everyone is having a great day
<theanorak_>
i'm interested in contributing to NVK. I have a gtx 1650 mobile. Any good documentation or tips related for a first contribution?
<kisak>
#nouveau is probably a closer channel to the topic
<theanorak_>
thanks, i'll head into the channel and ask about it
<theanorak_>
Hope you have a great day!
rbmarliere has quit [Quit: rbmarliere]
rbmarliere has joined #dri-devel
<karolherbst>
airlied: is there any reason to keep softpipe still?
<karolherbst>
guess for systems not supporting llvm? do we care about any of those?
crabbedhaloablut has quit []
sima has quit [Ping timeout: 480 seconds]
pac85 has joined #dri-devel
<jenatali>
FWIW we use it as the swrast that handles things like rasterpos, since LLVM has to be statically linked on Windows and accelerating that isn't worth a full copy of LLVM in our driver DLL
<airlied>
that is just draw I think
<airlied>
though I'd like to gut draw of tgsi as well :-P
<jenatali>
Yeah, but draw can use LLVM or not. Isn't draw essentially the entire guts of LLVMPipe/softpipe?
<karolherbst>
thre is also tgsi_exec
<airlied>
it's everything that isn't a binner/rasterizer/fragment/compute/mesh stage
<karolherbst>
which is kinda a CPU simulator of TGSI instructions
<airlied>
tgsi_exec is the shader engine for draw/softpipe in tgsi mode
<airlied>
just need nir_exec :-P
<karolherbst>
ez, just use the consting folding expressing
<karolherbst>
*expressions
<karolherbst>
(and handle intrinsics)
<karolherbst>
finally a driver which has all the nir features
<airlied>
I'm surprised gfxstrand has never done it for the lols