00:01 nyef: So, something that nouveau does tells the ACPI EC that there's a driver running that can handle the effect of the HDMI input logic on the display panel connection, and unless I can figure out what sort of microcontroller the EC is and dump its code, tracking through ACPI from nouveau is my best bet for finding some sort of leverage.
00:01 Lyude: luckily, acpi has support for exactly that!
00:01 karolherbst: nyef: there is no ACPI stuff we do inside nouveau, except runpm
00:01 karolherbst: but yeah, there is some tracing you can enable
00:02 karolherbst: and the othr subsystem are doing quite a lot of acpi stuff, especially the pci one
00:03 nyef: Oh?
00:03 nyef: Beyond merely disassembling the DSDT and various SSDTs and trying to puzzle out the code?
00:03 Lyude: nyef: yes
00:03 nyef: But nouveau interacts with acpi-video and mxm wmi.
00:04 Lyude: i am about to get on the train to work but keep me updated on this, you've got me curious
04:14 mooch: hey, does anybody know why yuzu is getting a pixel format of 0x7f and a component type of 7? tbh it smells like fishy fifo commands to me, but you can never be sure, ya know?
04:14 mooch: i've already had to fix similar shit for rpcs3
04:16 mooch: yuzu is a nintendo switch emulator btw
08:53 JayFoxRox: mwk: the 640x480 is definitely not linear. and it's not swizzled using the POT swizzle either. so it must be tiled then I guess? your explanation implies that tiling can not be swizzled? so how do those tiles work?
08:54 JayFoxRox: a bit of motivation / background: I'm tracing FIFO commands and then single step through them. I also intend to re-inject streams later. it's basically for comparing our emulation against hardware
08:55 mooch2: hold on, i think envytools has docs on this, actually
08:55 mooch2: lemme dig dat shit up
08:55 mooch2: https://github.com/envytools/envytools/blob/master/hwtest/nv10_tile.cc
08:55 mooch2: JayFoxRox, this even supports the nv20 memory controller! :D
08:56 mooch2: but i'm guessing this is the thing mwk meant by "tiling"
08:56 JayFoxRox: https://cdn.discordapp.com/attachments/428359408204906497/477056314946748427/video.webm here's a webm where I show what I'm looking at with 640x480 - at any other solution I don't have a working algorithm and I just get garbage
09:01 JayFoxRox: *resolution
09:01 mooch2: JayFoxRox, here's the algorithm mwk got https://github.com/envytools/envytools/blob/master/hwtest/nv10_tile.cc#L356-L359
09:01 mooch2: oh wait, that part of the file isn't it
09:02 mooch2: but still, these are tests that have been tested on nv20, so presumably they should apply to nv2a as well
09:03 JayFoxRox: mooch2: I still have no idea what I'm looking at? this looks like a function to write to GPU regs. I need a simple function to give me a byte address for the pixel at [X,Y], so I can turn bytes into pixels / image
09:06 mooch: well, still, JayFoxRox, looking through this whole file might help you
09:08 JayFoxRox: idk.. I'd rather want some good pointers or information how data is actually arranged. if I care about the regs where this information is stored [second step], then I'll look at that file probably
09:09 JayFoxRox: anything else will just be a waste of time / bruteforcing
09:10 JayFoxRox: https://github.com/envytools/envytools/blob/a6a1dc54d59c87ce0a2718415c3ceb2ec2488008/nvhw/tile.c#L105 this might be more interesting?
09:11 mooch2: JayFoxRox, yeah i was just about to show you that
09:12 mooch2: i guess just change that code until it ONLY handles NV20 and MAYBE nv25
09:18 JayFoxRox: yeah, porting it to python rn [NV10 and NV20 code path only] and then I'll test it
09:19 mooch2: why the nv10 code path? o.o
09:19 mooch2: nv2a is based on nv20, not nv10
09:20 JayFoxRox: iirc there's a ton of backwards compatibility?
09:21 JayFoxRox: the NV10 code is like 8 lines and doesn't add any complexity either - better safe than sorry
09:21 mooch2: eh, fair enough
09:22 mooch2: there is a ton of back-compat, but it just translates the old methods to the current register writes and shit
13:51 JayFoxRox: ftr: the code linked above does indeed produce the same output as the cryptic algorithm I had before :)
16:31 JayFoxRox: just to get this right: the tiling is portion of the memory manager, and the GPU MMU can set up to 8 tiling regions? so it's indepedent of everything else? so I could also tile vertex data or texture data if I wanted to?
16:32 JayFoxRox: [simply by marking those memory regions as tiled]
16:40 mooch2: i'm pretty sure that it's just handled automatically by the pfb? i dunno tho. sounds like something to test on hardware, for sure
17:10 JayFoxRox: https://github.com/envytools/envytools/blob/master/hwtest/nv10_tile.cc#L35 according to is_igp, the NV2A should be an IGP [true], however, with mcc all-zero I get bad images. I'm using self.mcbits = 2, self.partbits = 2, self.colbits_lo = 2, self.burstbits = 0 for testing right now [which produces good images for my input]
17:12 JayFoxRox: mwk: ^ any thoughts?
17:13 mwk: JayFoxRox: don't treat the NV2A as an IGP
17:13 mwk: it might be an IGP by definition, but the xbox.... is very strange
17:14 mwk: in normal IGP setup, the GPU borrows memory from the main mem controller, but in xbox, it's the other way around -- all the memory in the xbox is VRAM, and the CPU borrows it
17:14 mwk: so the memory controller is pretty much identical to a normal discrete GPU
17:16 JayFoxRox: mwk: NV2A is chipset 0x2A, correct? so should I make is_igp return False in my use-case?
17:16 JayFoxRox: and what's `mode` in `tile_translate_addr`? it did not matter for IGPs, but for GPUs with VRAM it would make a difference
17:17 mwk: JayFoxRox: yeah, 0x2a
17:18 mwk: is_igp... I guess it'd be OK to make is_igp false
17:18 mwk: though it might be better to tie that to PFB type instead
17:19 mwk: creating a new one for NV40-gen IGPs [which that branch is really for]
17:19 mwk: as for mode, it is, well, the tiling mode
17:19 mwk: IIRC it only applies to NV40 and up, on earlier cards you only get one mode anyway
17:20 mwk: which is equivalent to mode 1 of the later cards
17:20 mwk: which is what you should pass
17:21 JayFoxRox: I'll just hardcode it in my code anyway - I'm porting all of this to python, which is what our dev tools are written in
17:25 JayFoxRox: this has been tremendously helpful mwk :) thanks a lot for all your research and comments. I've been banging my head against a wall for days, but now things are slowly coming together