01:13 CaptainCoward_: hello, I am interested in native init of nvidia cards without running the pci rom (as in coreboot). does anyone know of a suitable card that might work in this way?
01:47 Wonka: CaptainCoward_: If I remember correctly, I did that with the nvidia gpu in my 2007 macbook pro...
01:48 Wonka: CaptainCoward_: but only halfway. I had to dump the pci rom and load it from a file when booting via EFI without BIOS emulation.
01:48 Wonka: CaptainCoward_: even the nvidia native driver for linux needed the pci rom. No idea what theOSX driver does though.
01:49 CaptainCoward_: but it does not run the rom, right? it just extracts data from it and feeds it to the gfx card?
02:04 e-anima: hi
02:05 e-anima: i get random freezes with noveau output is like nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
02:05 e-anima: random gpu locks leading to a full system freeze with a gforce 750 ti
02:05 e-anima: normal pc, no laptop
02:10 mupuf: CaptainCoward_: it is not possible
02:10 mupuf: the vbios contains init tables
02:10 mupuf: the vbios contains init tables x86 code, so you can interpret them
02:10 mupuf: nouveau can POST GPUs, so you have all the code you need
02:11 mupuf: you "just" need to port it to coreboot
02:12 CaptainCoward_: I don't need coreboot to init the gfx card. I am just looking at adding a gfx card and booting without running the pci rom at boot time and having nouveau init the card in linux. on the coreboot channel I was told this has a high chance of working
02:14 mupuf: CaptainCoward_: yep, no need to do anything basically
02:14 karolherbst: e-anima: did you change the clocks?
02:14 mupuf: but you will be left without VESA support
02:14 mupuf: that means no display until nouveau takes over
02:14 e-anima: clocks? the clock or the mhz? nothing i changed
02:14 CaptainCoward_: I mistakenly thought the pci rom is mandatory part of initialization at first but someone explained that only one card gets init by the bios normally anyways
02:14 mupuf: yes
02:15 karolherbst: e-anima: pstate interface in nouveau
02:15 e-anima: karolherbst, what do you mean with "in nouveau"
02:16 karolherbst: e-anima: well there is a pstate interface, but if you don't know of it, you most likely didn't change the clock, in any case, the core shouldn't lockup because of high clocks, because memory is still slow
02:16 e-anima: i didnt change anything here
02:16 karolherbst: mhhhh
02:17 e-anima: thst is the crashlog after reboot http://paste.debian.net/413119/
02:17 karolherbst: mupuf: maybe we should take a deep deep look on the gr falcon
02:17 mupuf: karolherbst: what for?
02:17 karolherbst: well random crashes?
02:18 karolherbst: e-anima: can you get us the begin of the errors?
02:18 karolherbst: maybe there is something there
02:18 e-anima: yes. random means after a random time.
02:18 mupuf: karolherbst: random crashes when doing what?
02:18 e-anima: beeing inside kde. mostly having music or video active
02:18 karolherbst: e-anima: so with random, you mean really random? no pattern, any application, and so on?
02:19 karolherbst: mupuf: well on maxwell the gr fuc code could have the same issues as the pmu too
02:19 e-anima: well mostly i have a browser running, my ide, 2 shells and music/video
02:20 e-anima: karolherbst, "the begin of the error" is there a log somewhere? if the system freezes i cant do nothing no more, no tty no numlock
02:22 karolherbst: e-anima: well you should have a dmesg.log in /var/log or journalctl (if you use systemd)
02:24 e-anima: random freeze right 1 minute ago
02:25 e-anima: i get logs now
02:25 e-anima: errors: http://paste.debian.net/413122/
02:26 e-anima: dmesg grep: http://paste.debian.net/413123/
02:27 RSpliet: karolherbst: why do you tell me that?
02:27 e-anima: is this enogh?
02:27 RSpliet: is there some context I need to know about?
02:28 karolherbst: RSpliet: I thought there would be, let me think
02:30 karolherbst: RSpliet: ohh right you just commented on the reclocking abilities
02:31 karolherbst: maybe there was something else, but I don't remeber
02:31 karolherbst: e-anima: for now, yes
02:32 e-anima: ok thank you
02:36 karolherbst: pmoreau: do you also have a "MCP79 Co-processor"?
02:36 karolherbst: or something simliar?
02:38 RSpliet: karolherbst: I have one of those, but that's because the entire platform is MCP79
02:38 karolherbst: yeah, I just want to know what kernel drivers I might need :D
02:38 karolherbst: or what that thing is
02:38 RSpliet: doesn't have a driver, but I recall mwk looking into this device in a long distance past
02:39 karolherbst: I also have a LPC bridge, but that sounds unimportant :)
02:51 karolherbst: e-anima: maybe it is something display related
02:51 karolherbst: I see some kscreen stuff before the error
02:51 e-anima: yes thatsright
03:06 karolherbst: uhhh a broken sensor agian...
03:07 karolherbst: "Mainboard Proximity" mhh
03:35 e-anima: now the system freezed while i was afk eating. so nice. i again found something untraceble
03:36 RSpliet: karolherbst: btw, for the GK107, have you ever double-checked whether the 2-stage PLL should be used for other clocks than the memory clock too?
03:36 RSpliet: there's some pretty high clocks in the VBIOS
03:36 RSpliet: (I didn't verify, just thinking out loud)
03:37 karolherbst: RSpliet: you mean like, the clocks share one refclock?
03:38 karolherbst: mhhh
03:38 karolherbst: that would actually work
03:38 karolherbst: the reflock is around 150-250MHz in the 2-stage pll mode for memory
03:39 RSpliet: karolherbst: not entirely. For the memory clock you had to configure two PLLs. One to get the reference input to so many MHz (150-250), second stage was required to bring it to 2GHz
03:39 karolherbst: yeah
03:39 karolherbst: ohh you mean those core engines would share one ref pll
03:40 RSpliet: no, I don't think about sharing
03:40 RSpliet: just
03:40 karolherbst: ahh
03:40 karolherbst: oaky
03:40 karolherbst: got it
03:40 karolherbst: just using two plls
03:40 RSpliet: does the core PLL have two stages too?
03:40 karolherbst: yes
03:40 RSpliet: or the ROP, or some of the HUBS
03:40 karolherbst: I read the gk20a code
03:40 karolherbst: and they do it there
03:40 karolherbst: but for other reasons
03:40 RSpliet: okay
03:40 RSpliet: does nouveau use that too for those clocks?
03:40 karolherbst: and on gk110+ we can't even read out the nvidia clock out right
03:41 karolherbst: mhhh
03:41 karolherbst: maybe?
03:41 karolherbst: but so did nouveau for gddr5 too
03:41 karolherbst: just not the right way
03:41 RSpliet: could explain the instability I'm experiencing
03:41 karolherbst: I was already thinking about this actually
03:41 karolherbst: that the pll configuration is instable
03:42 karolherbst: RSpliet: the gddr5 card has no cstates though, so we can't check lower clocks
03:42 karolherbst: how does 0a pstate driver?
03:42 karolherbst: *drive?
03:42 RSpliet: works fine
03:42 karolherbst: okay, I've got an idea
03:42 RSpliet: there's plenty of ways to check lower clocks
03:42 RSpliet: fake VBIOS, coolbits...
03:42 karolherbst: the wrong readings begin around 1GHz
03:42 karolherbst: try out if 0f at 900MHz is good
03:43 karolherbst: well 1800, wait second
03:43 karolherbst: memory uses 2-stage pll at 1600MHz+
03:43 karolherbst: so try out 1500MHz in the vbios
03:43 karolherbst: or was it more?
03:43 RSpliet: if you check my VBIOS, you'd see that there's quite a few clocks running around 2GHz
03:43 karolherbst: maybe it was 2400
03:44 karolherbst: but something in that area
03:44 karolherbst: yeah
03:44 RSpliet: also: PLLs have a lock test
03:44 karolherbst: nice
03:44 RSpliet: and I'm quite sure I use that on GT215 and MCP79
03:45 karolherbst: RSpliet: k, try to limit the core clock to 1500MHz in the vbios and step it up with 100Mhz steps until it becomes unstable
03:45 RSpliet: I'd rather take a bisecting approach
03:45 karolherbst: RSpliet: does it also hang with glxgears?
03:45 karolherbst: RSpliet: yeah, would work too
03:46 RSpliet: bit busy with other bits atm, but I'll see what I can do today
03:48 karolherbst: k, thanks
04:18 karolherbst: I have a new gsoc idea: writing a new falcon compiler with it's own brutally simplified C dialect or to modify envyas in a way, that we can add code conventions, so that envyas can bother us about it
04:18 karolherbst: but I doubt anybody will ever do the former
04:30 e-anima: karolherbst, i have the feeling that it works if i chose xrander instead og open gl 2/3 in kde compositor :)
04:31 karolherbst: e-anima: mhh okay
04:33 e-anima: but i have mesa installed. also the 32 bit stuff
04:35 e-anima: interesting thing. but i am not suprised as using opengl 2 or 3 caused strange graphic erros in kde. like pixeling effects on buttons and stuff. not so solid as i thought it is :)
04:36 e-anima: i heard general opinion is that nouveau is more stable than the closed source nvidia drivers. would like to know your opinion on this
04:36 karolherbst: you said this?
04:36 karolherbst: *who
04:37 e-anima: i read that on the net a lot. so there is no special person
04:37 karolherbst: odd
04:37 e-anima: i googled around a lot reading.
04:37 karolherbst: well maybe the plain X interaction is more stable
04:37 karolherbst: I don't know
04:37 karolherbst: but there are lots of issues left
04:38 e-anima: ok thx
07:01 pmoreau: karolherbst: IIRC, yes, I have a MCP79 Co-processor
07:03 karolherbst: pmoreau: do you have any drivers in use for that one?
07:03 karolherbst: and what does this thing do?
07:03 karolherbst: or do you have no idea about this one?
07:03 pmoreau: No idea. I haven't installed anything specific, and don't have the laptop at hand right now to confirm
07:03 karolherbst: ahh okay
07:03 karolherbst: I was just wondering, because I was setting up my machine here
07:04 pmoreau: Makes sense
07:04 karolherbst: but I got the sensors working :)
07:04 pmoreau: Which sensors?
07:04 karolherbst: mhh
07:04 karolherbst: you don't know that macs have like a hand full of sensors?
07:04 karolherbst: https://gist.github.com/karolherbst/06318f174ef14c46beec
07:05 karolherbst: apple-smc driver
07:05 pmoreau: Well, I mean temp sensors are already working, so not sure which ones you are talking about
07:05 pmoreau: apple-smc rings a bell
07:05 karolherbst: Tm0P is a approximation sensors
07:06 karolherbst: all the others might be temperature as well
07:06 karolherbst: usually there are sensors for all kind of stuff: hdds, ram, gpu, cpu, north bridge, whatever :D
07:06 karolherbst: I just noticed it was disabled in the x86 defconfig
07:07 karolherbst: pmoreau: SENSORS_APPLESMC if you don't have it
07:09 pmoreau: It's enabled by default on Arch it seems
07:09 karolherbst: ohh nice
07:09 karolherbst: maybe not auto loaded?
07:10 pmoreau: sensors always reported an "applesmc-isa" thingy, and listed tons of temp measurements
07:10 karolherbst: ahh okay
07:10 karolherbst: nice
07:10 pmoreau: So, probably auto loaded as well :-)
07:11 karolherbst: I was wondering if there is a power sensor as well
07:13 pmoreau: Ah… Would be great! :-)
07:14 karolherbst: at least I would expect as much
07:17 RSpliet: karolherbst: random fact of the day, I have not encountered a single NVAC that changes the voltage of the GPU
07:17 karolherbst: RSpliet: mhh well this is also a mobile gpu I have here
07:17 karolherbst: ohh wait
07:17 karolherbst: it isn'T
07:18 karolherbst: no, it is
07:29 karolherbst: I think I will also work on the autosuspend stuff on that nvac
07:29 karolherbst: I already encountered hangs because of that
07:37 karolherbst: holy..
07:37 karolherbst: why is the nvidia gpu like 78°C hot
07:38 karolherbst: and is doing nothing?
07:38 karolherbst: ohh second highest pstate
07:39 pmoreau: Yep, Tesla tends to boot pretty high ;-)
07:40 karolherbst: but I am also worried about the fan
07:40 RSpliet: checked the fans? tried hovering the machine? might simply be full of dust...
07:40 karolherbst: cpu got to 80°C and fan still at minimum
07:40 karolherbst: but, the cpus also didn't get hotter than that
07:41 pmoreau: Check the trigger points in sensors, mine has high at 84 and crit at 100
07:42 pmoreau: (For the CPU)
07:42 karolherbst: mine has 105 both
07:42 pmoreau: On no, those are the value for the new laptop. The one with the NVAC as 105 in both cases
07:42 pmoreau: Yep
07:42 karolherbst: well I don't mind if the thing is silent
07:43 pmoreau: So fans start going up quite late… :-/
07:43 karolherbst: much better than miny laptop where the fans are already noticeable at 55°C
07:43 karolherbst: okay, gpu at 74°C with lowest pstate
07:43 pmoreau: I would prefer mine to start cooling before reaching 100
07:44 karolherbst: are they acpi controlled?
07:44 karolherbst: ohh wait, I have an idea
07:44 pmoreau: Dunno
07:45 karolherbst: I had a tool to modify the rpm curve
07:45 karolherbst: yeah you can talk with the smc and configure it
07:45 karolherbst: the fans are smc controlled
07:46 pmoreau: Nice
07:47 karolherbst: well I have no clue how though
07:47 karolherbst: but there is this tool called smcfancontrol
07:47 karolherbst: nice: https://github.com/hholtmann/smcFanControl
07:50 karolherbst: but I doubt I care enough to actually implement this, seems like you are on your own pmoreau :p
07:50 pmoreau: Oh! Nice tool
07:50 karolherbst: yeah I used it on my macbook back then
07:51 pmoreau: :-p Meh, I might start spending less and less time on that laptop, so, I might end up not caring enough either :-D
07:51 karolherbst: ohh wait
07:51 karolherbst: I think I used a different one
07:51 karolherbst: where you could actually modify the curve directly
07:51 karolherbst: which means you could set the min/max points
07:52 karolherbst: well I think in the end my mac mini will end up as a cups server or something like that
07:52 karolherbst: :D
07:52 karolherbst: and yeah, something isn't right with the gpu, 73°C and it is doing nothing
07:52 karolherbst: are teslas that bad?
07:54 pmoreau: I guess power/clock gating might help to cool them further
07:54 karolherbst: yeah
07:54 pmoreau: Plus, don't forget it's quite close to the CPU ;-)
07:54 karolherbst: but first the runpm stuff is on the list, cause it affects both my gpus
07:54 karolherbst: mhhh
07:55 karolherbst: yeah well
07:55 karolherbst: cpu 45°C, gpu 72°C
07:55 pmoreau: :-D
07:55 pmoreau: The CPU is freezing, but the GPU is trying to keep it warm
07:56 karolherbst: right
07:56 karolherbst: 4 pastes and two are horrible slow and two are pretty fast
07:56 karolherbst: such a design
07:57 pmoreau: But at least they had pstates, which is not the case of many desktops cards from that time
07:57 karolherbst: right
08:00 RSpliet: karolherbst: on my ION board (MCP79), I can set the highest pstate in the BIOS setup utility
08:01 RSpliet: it would actually alter the VBIOS
08:01 RSpliet: init script included, iirc
08:02 karolherbst: oha
08:04 karolherbst: are there some tesla related changes from 4.1 to 4.4?
08:04 karolherbst: because currently I run 4.1
08:05 karolherbst: I will update either way, just curious
08:09 pmoreau: Hum… some reclocking most likely
08:13 karolherbst: ohhhh
08:13 karolherbst: I found something goldy: "userfaultfd"
08:13 karolherbst: "Enable the userfaultfd() system call that allows to intercept and handle page faults in userland."
08:37 karolherbst: ohh right :) I have something on that gpu
08:38 karolherbst: what the heck is "DVI-I-TV-S-Video"
08:39 karolherbst: ohh
08:39 karolherbst: that*s mini dvi?
08:39 karolherbst: hehe I have an adapter from mini-dvi to vga
08:45 karolherbst: the dcb spec says "DVI-I-TV-S-Video" for that output
08:45 karolherbst: but what is this TV-S-video part?
08:48 pmoreau: https://en.wikipedia.org/wiki/S-Video ? The S-video is plugged onto a regular DVI-I?
08:48 karolherbst: mhh
08:48 karolherbst: well the vbios says 0x20 for the port
08:48 karolherbst: and DCB DVI-I-TV-S-Video for 0x20
08:49 karolherbst: but it is a mini DVI-I actually
08:49 karolherbst: but
08:49 karolherbst: there are mini DVI-i to VGA, to S-Video, Composite and to DVI-D adapters
08:50 pmoreau: Hum, weird
08:51 karolherbst: well it works though
08:51 karolherbst: sadly
08:52 karolherbst: nouveau just printed "DRM: unknown connector type 20"
08:52 karolherbst: well I will stick to nvidia docs and put this stupid string there
09:15 jayhost: imirkin okay I understand nvdis does machine code -> nvidia assembly ... the opengl assembly extension and S2R is the undocumented head banging part.
09:39 night199uk: hey - in nvidia speak was is a ROP FBP?
09:40 night199uk: e.g.
09:40 night199uk: nvkm/engine/gr/ctxgm204.c
09:40 night199uk: oops
09:40 night199uk: gm204_grctx_generate_rop_active_fbps(struct gf100_gr_priv *priv)
12:15 hakzsam: I'm confident with this SHFL insn :-)
12:35 karolherbst1: pmoreau: ever had wifi problems with your macbook?
13:47 mupuf: karolherbst: hmm hmm
13:47 mupuf: what the fuck is nvidia doing? :o
13:47 mupuf: I got nvafakebios to work on the GM206
13:47 mupuf: well, seems like it at least
13:47 mupuf: I need to change one value in the vbios and see if it is actually used
13:48 mupuf: but hey, why the heck does nvidia change the ROM window address?
13:49 mupuf: let's see when it does it
13:49 mupuf: but yeah, the general idea is: the blob changes the address ... and exceed the address space while reading the vbios
13:50 mupuf: the problem is the following, the bios is MUCH bigger on GM206
13:50 mupuf: (*4)
13:50 mupuf: we will have to change that in our allocator too
14:08 mupuf: hmm hmm, on a successful load, the blob copies the vbios out from memory and writes it to a different address
14:12 karolherbst: mupuf: k
14:12 karolherbst: mupuf: I tell you what I have to do to get it work
14:12 karolherbst: 1. POST gpu (loading nvidia or something) then unload all drivers
14:13 karolherbst: 2. nvapoke 619f04 0xbffe09
14:13 karolherbst: bffe09 comes from vram size - 256k? & 0x1
14:13 karolherbst: or something
14:13 karolherbst: I have 3G
14:13 karolherbst: 3. nvafakebios
14:14 mupuf: well, this is because the blob does not set 619f04 for you
14:14 mupuf: but there is a different issue on GM206
14:15 mupuf: first of all, the vbios is 4 times bigger
14:15 mupuf: which meant I had to bump the size in nvafakebios
14:15 mupuf: and then, the first run after the upload would work ... but it would fail to reload afterwards
14:19 mupuf: and the blob tries to read past the RAM window, up to 10001fffc
14:20 karolherbst: ohhh
14:20 karolherbst: odd
14:20 mupuf: or maybe not the window, but the address may be limited to 32 bits
14:20 karolherbst: what does 0x1700 say?
14:20 mupuf: PBUS.HOST_MEM.PMEM => { OFFSET = 0xfffe0000 | TARGET = VRAM }
14:21 karolherbst: mhh
14:21 karolherbst: that looks high
14:21 mupuf: as you can see, the blob allocated 0x20000 but the bios is actually 0x40000
14:21 mupuf: original value: 00020e09
14:21 karolherbst: the offset is 0xbff0 here, but well maybe on maxwell it is shifted, which makes no sense
14:21 mupuf: that is for RAM offset
14:22 mupuf: Sounds like fun, right? :D
14:23 karolherbst: yeah
14:24 karolherbst: maybe adjust both 1700 and 619f04 and it works then?
14:24 karolherbst: your 1700 can't be right, can it?
14:24 mupuf: yeah, for some reason, the blob ALWAYS mirror the first 0x2000 of the ROM_WINDOW to another address
14:24 mupuf: but they forget to reset the address of the ROM_WINDOW when they are done
14:25 mupuf: which breaks the next faking
14:25 mupuf: err, the next boot
14:25 karolherbst: uhhh
14:25 mupuf: my 1700 does not matter, the problem is 619f04
14:25 mupuf: resetting 619f04 is enough
14:31 karolherbst: k
14:31 karolherbst: mhh
14:33 karolherbst: mhh can you shrink the vbios a little?
14:38 mupuf: well, nvidia is reading firmwares, probably
14:38 mupuf: so, no?
14:42 karolherbst: well, 0x40000 sounds a bit big
14:42 karolherbst: you mean that 1M vbios of yours?
14:43 karolherbst: mhh
14:45 mupuf: yep
14:46 mupuf: not sure it actually works though :s
14:46 mupuf: I cannot change the fan minimum speed
14:50 karolherbst: can you change anything else?
14:51 karolherbst: wipe out all power budgets to 0
14:51 karolherbst: if the driver still loads, something is odd
14:51 karolherbst: or set unk12 to 0 for the first one
14:51 karolherbst: good enough
14:58 mupuf: karolherbst: I can try that
14:59 karolherbst: but I think the most visible effect is modding the base clock, but this is a bit hard to see on a server, but the first clock through nvidia-settings should be equal to it
15:01 mupuf: yeah, it does not complain at all
15:01 mupuf: well, I guess it means I need to spend more time on this!
15:23 karolherbst: mupuf: can we extrace gm20x desktop vbios with nouveau?
15:25 mupuf: no idea, did not check
15:25 karolherbst: I think the vbios file may be smaller from debugfs
15:26 karolherbst: nvagetbios gets me 128K and the one from nouveau is 99k
15:26 mupuf: well, nouveau does not know about potentially new fw after the vbios tables
15:27 karolherbst: or just cut your vbios file after 128K and see what nvidia does
15:27 mupuf: it just reads and then aborts
15:27 mupuf: with no useful error message
15:28 karolherbst: do you think we might miss some tables? Because maybe it is worth to write a simple vbios compactor tool (and improve it later to do usefull stuff with it)
15:29 karolherbst: ohh also a nice gsoc project: write a nouveau vbios editor :)
15:34 mupuf: karolherbst: sounds good, how about you add the project?
15:50 mupuf: well, that was annoying, but I can confirm that with a without a faked vbios, the blob follows the same logic
15:51 mupuf: I wonder why the heck the blob ignores my modifications though :s
15:51 mupuf: maybe that will warrant an email to nvidia
15:52 mupuf: hopefully, they can tell us if it is still possible to fake the vbios
15:52 mupuf: and if not, maybe that can be a feature request :D
15:53 discipline: hi, has anyone ever tried to reverse engineer the changing of the LCD backlight from the Nvidia ? I'm on NV110 and trying to understand how it changes the LCD PWM for lower brightness on Windows 10. I understand that it gets the min max and current pwm values through the ACPI method \_SB.PCI0.WMI1.WMMX
15:53 discipline: but I can't yet figure it out how is it changed.
15:54 discipline: if anyone can give some directions on how could I understand that, it would be greatly appreciated
15:54 discipline: unfortunately I don't have a checked build of Windows 10 to debug ACPI+AML to see if changing the brightness is done through an ACPI call...
15:55 discipline: in reality I do have a checked build of windows 10, got it from dreamspark from university, but it doesn't install, keeps rebooting in the instalation process :}
15:55 discipline: :|
15:57 mupuf: discipline: well, if you do not want to go through ACPI, then sure, we know how to control the backlight
15:57 mupuf: as long as it is controlled by the nvidia gpu
15:57 discipline: I would love to go through ACPI
15:57 discipline: don't get me wrong :>
15:57 discipline: yes, it seems to be controlled by the nvidia driver
15:58 discipline: because brightness only works after installing the driver
15:58 discipline: hence I would conclude so....
15:58 mupuf: well, then it is likely a HW PWM controller
15:58 mupuf: you can check with nvbios which GPIO line is connected to the backlight
15:59 mupuf: as for which PWM controller is actually connected to it, it should be documented in rnndb
15:59 mupuf: both of these tools are located in envytools
15:59 mupuf: now, it is time for me to hit the sack
15:59 discipline: man, thank you so much!!!
15:59 discipline: I was really lost, will look into it!
16:18 AlexAltea: another guy and I are reversing PS3's hypervisor which includes a RSX (NV47-ish) driver. Aside from all typical MMIO regs (PFIFO at 0x002XXXX, PGRAPH at 0x40XXXX, etc.) there are a bunch of other engines whose registers are do not appear in any of the headers (e.g. 0x00088XXX, 0x0008CXXX)
16:18 AlexAltea: luckily, retrieving debug strings, assert messages, etc. we got some infos about them
16:19 AlexAltea: I'm wondering: is any of this relevant to anyone here, or does it sounds like something very specific to this GPU
16:47 mwk: AlexAltea: I'd be interested in having that sort of info in envytools, but it does sound specific to the GPU
16:47 mwk: 88xxx is PPCI area, ie. PCI configuration registers... NFI what it could be on RSX though
16:48 mwk: maybe they have some weido PCI stub
19:26 imirkin: skeggsb: i was about to ask you about the ramht vzalloc patch, but i see you just pushed it out - thanks :)