01:03seamsverynice: Has anyone even have tried to solve the opengl "MT" aka multithreaded context issues on say more stable kepler or other families of cards under nouveau?
01:05HdkR: karolherbst has spent some time working on it
01:11seamsverynice: HdkR: ok that is fairly reasonably good idea to fix that.
01:13seamsverynice: No further questions for today, generally sniffing in the docs how pushbufs cache can be mapped to communicate with the shaders, or is here someone who knows that offhand?
01:15seamsverynice: heck i rather try to ask, is it possible to map the same cache or is that a default for memory that of PFIFO and shaders?
01:16seamsverynice: so same memory/cache for PGRAPH and PFIFO, possible?
01:22seamsverynice: I am pretty badass technical guy, but I am honest i do not quite parse the docs very well in that regard.
01:32seamsverynice: on radeon i think one of the CP engines is a copy engine with access to l2 cache, i have not managed to yet understand how nvidia deals with communicating with the shader
01:41seamsverynice: well maybe the so called PFIFO cache is a so called blockram on chip a tightly coupled memory by arm terms.
01:42seamsverynice: on ARM this is a memory that can be addressed exactly as main memory but is as fast as blockram SRAM
01:54seamsverynice: https://envytools.readthedocs.io/en/latest/hw/fifo/nv1-pfifo.html#space-nv1-pfifo-cache1 allright something is going on there
01:59seamsverynice: this looks about as flexible as possible, so i missed the tlb part before, almost seams that nvidia cards are on the good side for communicating with pfifo from shaders
02:09seamsverynice: I Myself think that every sane gpu has some type of blit engine also on the fifo, and this ought to be cached and coherent with the shader cache too
02:22seamsverynice: yeah cheers, seems fine totally.
11:16rhyskidd: karolherbst: i have this intermittent nouveau boot failure that i'm debugging
11:17rhyskidd: have you ever seen "state" remaining in the gpu which then differs between a warm and cold reboot?
11:17rhyskidd: (is with a hybrid nv96 and nvac, the macbookpro 2009)
11:18rhyskidd: i'm scratching my head at what seems to be a hardware heisenbug ...
11:23karolherbst: Lyude was debugging such an issue on the p50
11:24rhyskidd: yeh, i'm not excited by this one ...
11:24karolherbst: rhyskidd: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0547c81bfcfad01cbbfa93a5e66bb98ab932f80
11:26karolherbst: I'd try if the quirk works for you
11:26rhyskidd: huh -- will give it a go
11:26karolherbst: we only enable it for some p50s though
11:26karolherbst: so you might want to adjust the checks quite a bit
11:27rhyskidd: this hardware is so much older though, so i'm not hopeful they are related
11:27karolherbst: who knows
11:27karolherbst: it is some firmware mess up
11:27karolherbst: not gpu
11:27RSpliet: rhyskidd: IIRC pmoreau has some experience with that hardware too...
11:27karolherbst: rhyskidd: also, you need to disable the hda quirk somebody added recently to the kernel
11:28karolherbst: as those two quirks don't play well together
11:28RSpliet: Is it the NV96 or the NVAC failing?
11:28karolherbst: I guess it's the dedicated one
11:28karolherbst: wild guess :p
11:28RSpliet: (always found that a weird combo of GPUs by the way. The NVAC presumable is the IGP, and the NV96 the dedicated one...)
11:30RSpliet: hmm ok. I think pmoreau pushed some fixes for the NVAC in such a machine in the past, not sure he did much with the NV96
11:33rhyskidd: hangs after this: https://paste.fedoraproject.org/paste/73CQVgn5NNQZZV9EzUha1A
11:34RSpliet: At least the reason is quite understandable :-)
11:35rhyskidd: i'm after the why :)
11:35karolherbst: rhyskidd: I am sure the issue is, that the firmware doesn't do a full reinit on the nv96
11:35karolherbst: because... technically it's not required
11:35karolherbst: and the driver can just do that inside the boot process
11:36karolherbst: and the firmware can just skip on that
11:36karolherbst: that's more or less the issue with the p50
11:36rhyskidd: yeh, i do see some occasional graphics corruption during early boot that *appears* to be partial images from the old framebuffer
11:36karolherbst: I am sure the quirk will work for you
11:37karolherbst: you might need to change a few things for the actual checks
11:37karolherbst: like the "ist the gpu initizalied" register
11:37karolherbst: but generally... sounds like the exact same issue
18:17JacekJagosz: Hi, sorry for bothering. How can I check which power state my GPU is currently in?
18:17gnarface: i forget exactly, but i'm pretty sure it is somewhere in /sys
18:19WizardGed: cat /sys/kernel/debug/dri/0/pstate
18:19WizardGed: I think
18:19gnarface: something like that for sure at least
18:19gnarface: they're hex codes though i think
18:20gnarface: f0 is the lowest one?
18:20gnarface: i think?
18:20JacekJagosz: That command lists available states, but I don't know which one it is right now using
18:20karolherbst: last line shows the current clocks
18:20karolherbst: and by default no state is selected
18:23WizardGed: JacekJagosz, I'm sure I don't have to tell you to be careful when playing with powerstates
18:24WizardGed: I've had bad luck with my gtx 560 and pstates
18:25JacekJagosz: Because my Fermi even with 3D workload is using the lowest one
18:25gnarface: that's a known problem with a lot of them... there is a chart
18:26gnarface: here: https://nouveau.freedesktop.org/wiki/FeatureMatrix/
18:26JacekJagosz: I saw it, but was wondering if power state is listed can it be forced? With "echo 0f > /sys/kernel/debug/dri/0/pstate"
18:27gnarface: for some of them it can be forced
18:27gnarface: but it will also break some of them too...
18:27JacekJagosz: For me I only get
18:27JacekJagosz: "Error while writing to stdout write_loop: Function not implemented"
18:28gnarface: and it's important to note that just because you can force the power state doesn't mean it will necessarily get the proper accompanying fan speed
18:28karolherbst: JacekJagosz: only works on tesla/kepler/maxwel 1st gen
18:28karolherbst: anyway, I found somebody to work on fermi reclocking now :D
18:28karolherbst: RSpliet: ohh.. you also didn't look at engine reclocking issues, right?
18:30JacekJagosz: So all Fermi's are stuck on lowest clocks or just don't allow manual reclocking?
18:31karolherbst: JacekJagosz: it depends on the fermi GPU
18:31karolherbst: some boot with the lowest, some with higher
18:32JacekJagosz: Can I somehow change it?
18:33karolherbst: if you feel adventerous.. there are some branches around of some devs trying to implement it... but I wouldn't know what's the most recent state
18:33karolherbst: RSpliet might
18:33karolherbst: or skeggsb
18:34karolherbst: JacekJagosz: if your memory clocks are decently high, you could also try out to only enable the engine reclocking bits... this usually goes well, but is also quite useless if the memory speeds are too low
18:37JacekJagosz: Unfortunately it is running at just 135MHz instead of 2000MHz. I wanted to use PRIME to have an elegant way of using Nvidia GPU. But now I don't think I'll make it work
18:40karolherbst: JacekJagosz: probably not
18:41karolherbst: sadly the most difficult part is left to get it working, and that's memory reclocking
18:41JacekJagosz: Still thank you for your time, I'll look into current branches
19:23RSpliet: karolherbst: I think skeggsb's branch has some fixes for engine clock changing
19:24karolherbst: RSpliet: he said he didn't work on that
19:25RSpliet: my mouldy branch is all I got https://github.com/RSpliet/kernel-nouveau-nv50-pm/commits/master
19:25karolherbst: anyway.. skeggsb branch have no clk related patches
19:25RSpliet: that and a lot of shame. I really wanted to pick up Bens stuff and push it forwards. But time. Time :'(
19:25karolherbst: but, I found somebody who is willing into fixing the engine related stuff :p
19:26karolherbst: I am just not sure if that's too difficult for now
19:26karolherbst: RSpliet: well.. maybe when you find time again, all the engine stuff is out of the way
19:26karolherbst: we already found some volting stuff going wrong horribly
19:27RSpliet: Ohh yes, there might be some low-hanging fruit there, bridging the Fermi gap from knowledge you already generated for Kepler :-)
19:35karolherbst: yeah.. but that was with older version of all the tables involved
19:40karolherbst: RSpliet: but we also found a gf119 where the higher pstate just causes rendering to literally stop... but it can recover if you switch back to the lower pstate :)
19:40karolherbst: that might be fun to figure out
19:41karolherbst: but gf119 is totally weirdo gen anyway
19:45RSpliet: It's probably not the weirdest you've ever seen.
19:46karolherbst: I am sure it is
19:46karolherbst: it's half kepler half fermi in too many regards
19:46RSpliet: You haven't seen "return of the GeForce 2 memory controller" NV34?
19:46karolherbst: skeggsb even thinks that the kepler memory reclocking code might just work
19:46karolherbst: on a gf119
19:47karolherbst: RSpliet: those were the insane times where everything was legit
19:47karolherbst: being crazy while everybody is crazy, just means you are not that crazy afterall :p
19:48RSpliet: Then there is the "let's bolt GDDR5 onto a (G)DDR2/3 memory controller" GT215
19:48karolherbst: also.. going back a few steps was kind of a thing to do
19:48karolherbst: intel did the same
19:48karolherbst: RSpliet: ohh, that's probably indeed insane
19:49RSpliet: A miracle it even worked, from what I recall
19:49karolherbst: didn't it had like seriously low clocks though?
19:49RSpliet: Haven't figured out whether the engineers on that project were extremely proud or deeply embarrassed :-P
19:50RSpliet: We had to disable someting something multithreaded in the graphics context to make it work.
19:50karolherbst: actually, that was legit gddr5 stuff
19:51karolherbst: but 850MHz isn't very fast
19:51RSpliet: Nothing too impressive no :-P But isn't it quad-data-rate?
19:51karolherbst: that's why 850
19:51RSpliet: Oh and I almost forgot about TurboCache, which was neither turbo nor a cache... I think. Maybe it was a cache, who knows
19:52karolherbst: wasn't it that macbook stuff, which was just a marketing name?
19:52RSpliet: Not just macbook. Even discrete desktop graphics cards had the label
19:53karolherbst: ahh, that was this "I can also use system memory" weirdo thing
19:53RSpliet: yeah, but in a way so ingenious even they couldn't figure it out. It died a silent death after GeForce 6xxx
19:53karolherbst: wasn't it even 6200 only?
19:54karolherbst: "GeForce 6200 TurboCache" :D
19:54karolherbst: "128–256 System RAM incl.16/32–64/128 onboard"
19:54RSpliet: And a couple of GeForce Go 7xxx models I think
19:55RSpliet: and with I, of course I mean Wikipedia
21:28Lyude: yay, found a modesetting bug with switching between DP connectors
21:32HdkR: lol, wtf is a turbocache
21:33HdkR: "Main memory is accessed using the high-bandwidth PCI-Express bus."
21:34HdkR: "128–256 System RAM incl.16/32–64/128 onboard"
21:34HdkR: Oh gods. only 16MB onboard?
21:34HdkR: That is scary bad
21:34karolherbst: guess what's faster
21:34karolherbst: PCIe :p
21:35karolherbst: 5.6 GB/s had the onchip memory
21:35HdkR: 4GB/s PCIe 16x gen 1
21:35HdkR: Not much slower
21:36karolherbst: maybe it allowed the driver to skip stupid copies? :D
21:36HdkR: Just fetch textures data directly from system memory, sounds sane :)
21:37HdkR: Maybe if we had a fast enough interconnect today that would still be viable
21:37HdkR: Scale PCIe to 1TB/s
21:37karolherbst: the plans of pcie tell us, they are not interested
21:38Lyude: DP audio should work on nouveau, right?
21:39karolherbst: I hope so?
21:39HdkR: We're more likely to have one of the new high speed interconnects come along and give devices fast coherent memory access and we'll be stuck in another AGP round of devices
21:39Lyude: it could be that I'm missing something in my minimal kernel config, but I'm not getting the sound device to come up in te gnome control center
21:39karolherbst: HdkR: cable to connect the CPU with the gPU directly :p
21:39Lyude: (note: quirk_nvidia_hda() is definitely working, I can at least see the PCI device for the sound thing)
21:39karolherbst: Lyude: did you enable the alsa drivers?
21:40karolherbst: and the codecs?
21:40Lyude: karolherbst: yeah, let me just send you my config
21:40Lyude: karolherbst: https://paste.fedoraproject.org/paste/Z04l4mJfj5ePMAQk1bAJHg
21:42Lyude: snd_hda_intel seems to be binding to it as well. that part I'm entirely unsure of whether or not it's normal
21:42karolherbst: mhhh, that's normal
21:42karolherbst: Lyude: you might have to configure the output device
21:42karolherbst: HDMI.... is wierd
21:42Lyude: karolherbst: DP
21:42Lyude: karolherbst: what exactly do you mean?
21:43karolherbst: the output device config
21:43karolherbst: usually you get like thousends of the same thing
21:43karolherbst: and one works
21:43karolherbst: the other not
21:43Lyude: the sound device doesn't even come up when I try to select it in gnome
21:43karolherbst: the device profile
21:43Lyude: as in it's not listed at all
21:43karolherbst: it should I guess?
21:44karolherbst: or maybe DP is super weird
21:44Lyude: yeah I don't see it listed in puleaudio either, hm.
21:44karolherbst: did you try HDMI?
21:44Lyude: karolherbst: til the P50 only has DP ports. The HDMI port on it is a lie and is actually a DP port, or at least nouveau exposes it that way
21:45karolherbst: you should have the normal audio device settings
21:45karolherbst: and there is this profile switch
21:45karolherbst: to switch between duplex and... you know, the stuff
21:45karolherbst: and you usually get tons of hdmi profiles
21:46karolherbst: I am not 100% sure on how all that works, but you might not even get a new sound device for the GPU ones
21:46Lyude: i'm pretty sure there should at least be a new device
21:47Lyude: there it is
21:47Lyude: there's definitely another bug here I think
21:47Lyude: I'm going to make sure it's not the p50 quirk breaking the hda quirk
21:48karolherbst: that would be fun
21:49karolherbst: but I guess if you reset the card, you have to enable the multi-fun field again
21:49Lyude: surprisingly, I don't believe that's actually the case
21:49Lyude: I did a little playing around and it looks like that resetting the bus also seems to enable the HDA controller for some reason
21:50Lyude: without us having to do it manually
21:50karolherbst: I slowly getting the feeling we have a really "smart" firmware on that p50 :p
21:56Lyude: ok cool, it isn't
21:56Lyude: erm, conflicting with the p50 quirk I mean
21:57Lyude: "front, left"
21:57Lyude: everything works :), yay