12:43swiftgeek: k got some medium res pictures of that zotac fx5200 card, sadly with stickers in wrong place so can't tell whether i need to shift some resistors to upgrade ram :D
12:55imirkin: swiftgeek: not sure what you're looking for... i have this card:
12:55imirkin: 09:00.0 VGA compatible controller : NVIDIA Corporation NV34 [GeForce FX 5200] [10de:0322] (rev a1) (prog-if 00 [VGA controller])
12:55imirkin: Subsystem: Device [196e:01ad]
12:56swiftgeek: looking for this exact card https://cdn.videocardz.net/cache/128d5eb8d8a614e90f1faf4dc5b76e96-1200x900.jpg :D
12:56swiftgeek: i have 128MiB variant
12:56swiftgeek: i can barely see on those pics what ram chips those are but i think same as i have on my variant
13:04imirkin: trying to remember which one it is... it's currently plugged in, but there are actually not a ton of pci nv34's out there
13:05swiftgeek: imirkin: if it has yellow ports - it's that one
13:05swiftgeek: ( if 256 mib )
13:06swiftgeek: imirkin: ah and it's PCI
13:14imirkin: i can't see it easily. it has 2x VGA (even though nouveau lists one as DVI)
13:14imirkin: and s-video
13:15imirkin: so probably a diff one
13:15swiftgeek: imirkin: zotac has yellow ports so that's one way to differentiate it
13:15imirkin: can't really see the color
13:15imirkin: like i said, not easily accessible ;)
13:17imirkin: oh wow, the actual port itself is yellow
13:17imirkin: yeah, these are blue
13:19swiftgeek: btw any idea why does it have 2 SPI flashes?
13:19swiftgeek: ah one is for 45xx k
13:19swiftgeek: that makes sense then
14:18john_cephalopoda: Hey. My laptop has a 3D controller: NVIDIA Corporation GF117M, which runs with nouveau. It seems to run rather slow though. Apparently the GPU is underclocked.
14:19john_cephalopoda: When I cat pstate in the debugfs, it tells me that it has 3 different clock speeds, when I try to echo a new speed to it, it says "bash: echo: write error: Function not implemented" though.
14:19john_cephalopoda: Did I overlook something in the configuration or is reclocking simply not supported for that chipset yet?
14:20john_cephalopoda: OpenGL renderer string: NVD7, Linux adrastea 4.15.4 #5 SMP Mon Jul 30 14:39:46 CEST 2018 x86_64 Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz GenuineIntel GNU/Linux
14:20swiftgeek: imirkin: what confuses me is missing configurations for overall capacity i think not sure
14:21john_cephalopoda: Oh, and xorg nouveau driver is 1.0.15, in case that's relevant.
14:21swiftgeek: i'm not sure whether it's using chipselects or whether i have 64bit bus width and 256mib one has 128bit bus width
14:22imirkin: john_cephalopoda: no reclocking for fermi
14:22swiftgeek: chips are 4Mx16
14:22imirkin: john_cephalopoda: skeggsb has a test branch, but on the one fermi gpu i tried, it didn't work well, despite it being literally identical to one that he had tested with.
14:22swiftgeek: 4M x 4banks x 16bits
14:23imirkin: [and that he claimed it work well on]
14:23john_cephalopoda: imirkin: Ah, thanks. The nvidia GPU runs slower than the integrated GPU right now :D
14:23swiftgeek: is there a way to get state of RAM_CFG_* from software?
14:24imirkin: john_cephalopoda: https://github.com/skeggsb/nouveau/commits/devel-clk
14:24john_cephalopoda: I'll try out the branch, thanks for the link :)
14:24imirkin: john_cephalopoda: even at max clocks, it's not much faster... hsw is pretty decent.
14:24swiftgeek: WAIT WHAT
14:25swiftgeek: are those straps on regulars pins that could be traced out? :D
14:26imirkin: john_cephalopoda: not to mention the relative quality of the intel driver is _much_ higher than nouveau's
14:26swiftgeek: yeah it's on VGA dsub or sth probably lol
14:26john_cephalopoda: I like nouveau anyway. It's great work that you all are doing.
14:27imirkin: it's fun. just not practical.
14:29swiftgeek: VSYNC/HSYNC should be easy to spot even with scope :D
14:30swiftgeek: and all use 10kΩ in reference schematics which will be odd compared to fine tuned analog stuff
14:32swiftgeek: yeah ram config straps are the only ones there that would be relatively easy to find xD
14:34john_cephalopoda: imirkin: My next GPU will be AMD. But for now I am stuck with nvidia.
14:35karolherbst: imirkin: saw my TEXS patches? Wondering if you find some time to review them soonish
14:36imirkin: karolherbst: next week or even more likely weekend after that =/
14:38karolherbst: imirkin: no worries. I still want to look into why quite a lot of shaders show higher gprs usage, because my assuption was it should rather decrease (~3000 helped, ~400 hurt though in total)
14:38imirkin: not surprising
14:38imirkin: the tex quads caused a ton of movs to happen
14:39imirkin: more movs = fewer regs
14:39karolherbst: right, but those movs are like directly before the tex
14:39imirkin: sometimes. sometimes not.
14:39karolherbst: ohh, yeah maybe that's it then
14:39karolherbst: I should just take a look
14:40karolherbst: overall it still helps quite a lot, -0.66% gprs, which is quite nice
14:40karolherbst: just wondering about the hurt shaders
15:56Lyude: Does anyone know what the nvif_mthd() here actually does? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/dispnv50/disp.c#n1114 I found https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c#n224 which i assume is the nvkm thing it's calling down to, but it doesn't seem to actually do anything
15:56Lyude: important other then setting a single variable
15:56Lyude: trying to make sure there isn't some magic GPU display script that's being called here that I'm missing
18:55JayFoxRox: how does swizzling / tiling work for surfaces [render outputs]? I have a functional swizzle code for POT textures. I also have an 640x480 XRGB framebuffer and weird/shitty algorithm to unswizzle/untile/[or whatever] it; but I can't figure out how that algo works
18:56JayFoxRox: at this point I'm not even sure if my framebuffer might just be linear, and only tiled in some form; or swizzled [and possibly also tiled in some form?]
18:56JayFoxRox: I do have other framebuffers in 128x128 which I can decode just fine with my texture decoder
18:57JayFoxRox: [talking about NV2A - xbox GPU; I can provide PGRAPH and framebuffer dumps if anyone wants to take a look]
22:01karolherbst: imirkin, mwk: if you don't mind I would add the sched opcode generation stuff to envyas as an optional step
22:04mwk: that's going to be a mess with the envyas codebase
22:04karolherbst: mwk: the thing we do inside codegen
22:04mwk: how do you want to pull that off?
22:04karolherbst: no idea yet
22:05karolherbst: mwk: it is mainly for verifying our scheduling logic is correct
22:06mwk: hm, how would that help?
22:06karolherbst: mwk: what I want to do is to take nvidia generated shaders and let it be processed by some tool
22:06karolherbst: and check if we come up with the same sched opcodes as nvidia is
22:07karolherbst: maybe we use higher stalls somewhere, or lower ones, or use too many barriers or not enough, whatever
22:07mwk: wouldn't envydis be the more logical tool to use for that?
22:08karolherbst: the advantage of anvyas would be, we could write the assembly and don't care about the sched stuff at all
22:08karolherbst: and let anvyas generate those
22:08karolherbst: we have some of that for the builins in codegen
22:08karolherbst: and currently you have to fill the scheds by hand
22:08karolherbst: but the verification thing is kind of the more important part for me
22:46imirkin: karolherbst: i don't think it makes a ton of sense in envyas itself
22:47imirkin: but perhaps as a tool that uses the same library
22:51karolherbst: yeah, something like that
22:55imirkin: JayFoxRox: http://envytools.readthedocs.io/en/latest/hw/memory/g80-surface.html
22:56imirkin: i realize that describes later ones, but i think it's still applicable to nv2a
22:56imirkin: you're looking for "blocklinear" in there
22:57imirkin: note that there is no NPOT support on there
22:57imirkin: so a 640x480 image would either be non-swizzled, or it would be 1024x512
22:58imirkin: G80+ supports tiling on npot surfaces, but not earlier
23:00mwk: that's not applicable at all to NV2A
23:01mwk: blocklinear is non-existent before G80
23:01imirkin: but there's "swizzle"
23:01imirkin: i thought it was roughly the same
23:01imirkin: but not as ... configurable
23:01mwk: it barely has anything in common
23:01mwk: on NV2A, you have three options
23:02mwk: a plain linear buffer, a tiled buffer, or a swizzled buffer
23:02mwk: swizzled is POT-only, the other two can be used for NPOT
23:02imirkin: oh crap right.. all that fb_tile junk?
23:03imirkin: totally forgot
23:03mwk: you only use swizzled for textures, they're slower to render to
23:03imirkin: JayFoxRox: don't listen to me. listen to mwk.
23:03mwk: and tiled is weird
23:03imirkin: it's handled by the fb transparently right?
23:04imirkin: there's no separate "tiled" setting in pgraph when describing a surface to render/texture
23:04mwk: basically, tiled surfaces look exactly like linear surfaces to software, you use the same command streams, and when you look at them through the VRAM window you see linear addressing
23:04mwk: yeah, mostly transparently
23:04imirkin: right. that's why i forgot about it :p
23:05mwk: you have 12 or so tiled surfaces available, which you have to set up in advance as base-length-mode triples in PGRAPH+PFB registers
23:05imirkin: do we have docs on the tiled thing? i think he's looking to detile
23:05mwk: once you do that, your rendering commands just magically become faster
23:05mwk: yeah, but there's no point to detiling
23:05imirkin: although... if you're writing a full emulator
23:06imirkin: no point in tiling in the first place
23:06mwk: there's no way to look at the memory without detiling
23:06imirkin: since it's transparent to software
23:06mwk: we don't have docs
23:06imirkin: you just have to handle swizzled
23:06imirkin: do we have docs on that one?
23:06mwk: though we have functionally-equivalent source code
23:06imirkin: it's just 64x64 chunks, same as g80 blocklinear?
23:06mwk: I reversed tiling down to the bit a long time ago
23:06mwk: swizzling is very very different
23:07mwk: blocklinear has 1 level of tiling
23:07mwk: well, maybe two, in strange configs
23:07mwk: [at least, levels that you see, what the memory controller does under the wraps is a different story]
23:07mwk: swizzlign has... all levels of tiling
23:07mwk: as in, it interleaves X and Y coordinates into the address
23:08mwk: so you have 256×256 texture, made of 128×128 tiles, made of 64×64 tiles, made of 32×32 tiles, and so on until 2×2
23:08mwk: quite annoying to handle in software
23:08mwk: unless you happen to be programming in INTERCAL
23:08imirkin: so it tiles 2x2 "groups" of tiles, recursively?
23:09imirkin: in what way? i.e. if the logical layout is
23:09imirkin: 1 2
23:09imirkin: 3 4
23:09imirkin: then how are those 4 groups laid out in memory?
23:09mwk: 1 2 3 4
23:09imirkin: i see. and for a 2x2 group, that is literally those 4 pixels
23:10imirkin: er, 2x2 tile
23:10imirkin: and for everything else, it's annoying to write down :)
23:12mwk: in case of width != height, the low bits are still interleaved, and the leftover high bits just appear as one chunk
23:12mwk: and in case of 3D textures... well, I have NFI what happens
23:14mwk: though I'd be guessing it's just a series of independent 2D slices
23:24growpotkin: Has anyone had issues with monitor-ids changing between boot cycles?
23:26growpotkin: My drivers seem to just randomly assign various "HDMI-#" or "DP-#" ids. It's making my xrandr config a real headache
23:26karolherbst: growpotkin: that would be odd
23:27karolherbst: usually that is quite stable
23:27karolherbst: growpotkin: maybe some DP-MST stuff going on there?
23:27Lyude: any warnings about connectors being leaked in your kernel log?
23:28Lyude: karolherbst: i mean; the numbers shouldn't change that much even with connector creation/destruction at runtime
23:28karolherbst: Lyude: doesn't leaking only happens when you unload/load the module?
23:28Lyude: karolherbst: as far as I know
23:28karolherbst: Lyude: "Has anyone had issues with monitor-ids changing between boot cycles?"
23:28Lyude: but, maybe I don't know this issue :)
23:28growpotkin: The alternate explanation could be an xrandr issue, but this only began when I swapped over to nouveau so
23:28karolherbst: growpotkin: the driver kind of decides how to name things
23:28Lyude: it's not xrandr
23:29growpotkin: okay good to know, that focuses me in a bit.
23:29karolherbst: growpotkin: desktop GPU?
23:29Lyude: mind showing me a two or three kernel logs where the connector IDs change?
23:29karolherbst: not intel?
23:29karolherbst: growpotkin: is the output of "ls /sys/class/drm" the same between those boots even if the ids are changing?
23:29growpotkin: yeah I can do that. do you know where I might find those? I can do the ol' google hunt otherwise
23:29growpotkin: oh there's my answer haha
23:30growpotkin: Yes so I have the same drm slots, but my monitors seem to just get assigned to them randomly.
23:30growpotkin: so for example, I have some DVI-D's, some HDMI's, and some DP's
23:31growpotkin: on one boot Monitor A -> DVI-D-0, B -> DP-3, C -> HDMI-0
23:31karolherbst: growpotkin: okay, so the output names stay the same, but monitors get randomly assigned, so sometimes one display is at HDMI-1 and then at HDMI-2 or something like that?
23:31growpotkin: then on the next one Monitor A -> DVI-D-1, B -> DP-2, C -> HDMI-3
23:31growpotkin: without changing plugs or anything
23:32karolherbst: yeah, weird
23:32karolherbst: dmesg might help
23:32growpotkin: you've got the idea karol
23:32nyef: growpotkin: And this isn't a nouveau vs. dmesg thing, or a "bios picks a random boot screen" thing?
23:32nyef: Damnit, nouveau vs. nvidia thing.
23:33nyef: (Either I've had too much wine, or not enough.)
23:33annadane: but not WINE
23:35growpotkin: no my issue comes when I setting my xrandr later
23:35imirkin: growpotkin: that could also happen if you have multiple GPUs and the drivers load in different orders
23:35growpotkin: althought it might be happening earlier on.
23:36imirkin: DVI-D-0 implies a very odd driver. most number from 1.
23:36growpotkin: I do have a little radeon chip built in to my board, but nothing it plugged in to it
23:36imirkin: plugged in or not, if the driver loads, the connectors are created
23:36Lyude: that's probably it
23:36growpotkin: oh yeah my bad that was just a random number I chose haha
23:36Lyude: blacklist amdgpu/radeon, whichever one it's using and see what happens
23:37karolherbst: next time I ask for ls /sys/class/drm -la
23:37karolherbst: uhm -l
23:37growpotkin: I technically have "DVI-D-1, HDMI-A-1, VGA-1, DP-1, DP-2, DP-3, DVI-D-2, HDMI-A-2"
23:37Lyude: karolherbst: jfyi; at some point since it's next to no effort I will be adding drm debugging stuff to sosreport
23:37Lyude: growpotkin: really-try blacklisting amdgpu/radeon
23:37growpotkin: will do. let me give that a shot and reboot
23:37nyef: ... What about i915?
23:37growpotkin: Thank you for the help
23:38Lyude: is i915 involved?
23:38Lyude: blacklist everyone involved!!! except nouveau
23:38karolherbst: nyef: I guess if hyou have an embedded AMD GPU, you most likely don't have an intel one as well ;)
23:38nyef: Okay, fair enough.
23:38karolherbst: _that_ would be quite the system though
23:38imirkin: except ... Vega-M?
23:38karolherbst: imirkin: why the nvidia GPU then?
23:39imirkin: pci slot
23:39nyef: It could be a crazy situation of on-CPU i915, on-mainboard radeon, and then an nvidia card.
23:39imirkin: or mxm
23:39karolherbst: imirkin: well, there are laptops with 3 GPUs, but those are usually those crazy SLI ones ;)
23:40karolherbst: no idea if mxm is a thing on non laptops
23:40karolherbst: is it?
23:40nyef: Urgh. Right. At some point I need to figure out which thing that nouveau does on startup that kicks on the extra functionality in the ACPI EC, so that I can figure out how to bring that mess under control. And I have no idea if it's part of the MXM stuff or if it's ACPI Video, or if it's something else entirely.
23:40Lyude: nyef: which functionality?
23:41nyef: HDMI input, actually.
23:42nyef: There's an HDMI receiver (and a DP encoder) in this system that will swap the video signal between the GPU (either the MXM card or the i915) and the HDMI input, but it's under control of ACPI, and only enables once nouveau (or nVidia) loads.
23:42karolherbst: nyef: there are some 3 custom MXM pins free for whatever purpose
23:42karolherbst: well, 3
23:42Lyude: oh ok-I don't know how that works then :(
23:43karolherbst: but dunno if they do anything with it
23:44nyef: The thing is, SOME systems by this manufacturer have driver support for the HDMI input controls in Linux, but this one appears to pre-date (post-date?) whatever magic it is that the WMI driver does, so I need to track it down.
23:44karolherbst: have fun
23:44karolherbst: MXM is quite the mess anyway
23:44nyef: Plus it turns out that the HDMI input is also mapped to the SPDIF input on the sound codec, which means that the only way to get jack sense there is via detecting the HDMI input.
23:45nyef: And *THEN* it turns out that the SPDIF output port jack sense is wired through the embedded controller instead of having it mapped through the HD-Audio codec.
23:46nyef: Thus far, I've turned up on the order of three 8051 devices, a tms430, and an x86 as various embedded controllers.
23:47nyef: And I've only managed to get some semblance of control of two of the 8051s.
23:47nyef: ... Oh, and the APCI "embedded controller" is probably another one, but I don't know what.
23:50karolherbst: nyef: ACPI is just some wrapper around stuff
23:50karolherbst: more or less
23:50karolherbst: in a weird sense
23:55nyef: I know. But some of that stuff is more microcontrollers, and then they talk to other parts of the system over various protocols or they just have GPIO pins or whatever.
23:58Lyude: that's definitely not unheard of
23:58Lyude: i915 does that for hpd detection in runtime suspend on some systems by getting the pin mappings through acpi iirc