02:52 imirkin: in case anyone is curious (i assume no one), here is the list of gles2 fails when it is enabled on nv34: https://people.freedesktop.org/~imirkin/nv30-gles2.fail
06:59 mupuf: imirkin_: pretty good for nv30!
08:47 rmrfchik: Hi, i have gt 210. Want to try nouveau. I did "rmmod nvidia; modprobe nouveau", immediatelly got fb screen (which is good).
08:48 rmrfchik: Now starting X11 gives black screen. Wiki says it may be because clock speed
08:48 rmrfchik: and I have 2 monitors
08:50 karolherbst: rmrfchik: well, unloading nvidia and then loading nouveau might cause issues
08:50 karolherbst: rmrfchik: you should check your X log and dmesg
08:53 rmrfchik: nothing suspect
10:55 RSpliet: imirkin: heh, iirc correctly our NV30 assembler doesn't do control flow
10:55 RSpliet: so not very surprised that there's a lot of tests failing with "loop" in the name
11:00 karolherbst: rmrfchik: well maybe you should boot with nouveau loaded (and nvidia blacklisted)
11:03 mupuf: RSpliet: :p
11:09 karolherbst: mupuf: well, regarding the reg from yesterday, there might be a valid correlation between existing display ports and touching this reg. It is also the first thing done after FB PAUSE
11:09 karolherbst: and on 3 cards with empty CON tables it wasn't touched
11:10 mupuf: ah ah, sounds fun
11:12 karolherbst: maybe empting the DCB and CON table should be enough so that nvidia stops touching this
11:13 mupuf: well, do you need any hw in reator?
11:13 mupuf: hakzsam: you are done with fermi, btw?
11:14 hakzsam: mupuf, yep
11:14 mupuf: hakzsam: would the titan + 750 Ti be ok?
11:14 hakzsam: mupuf, but please keep the gm107 in reator
11:15 hakzsam: sure
11:15 karolherbst: mupuf: well, I can try out on my GPU, because at it seems this will only affect optimus systems anyway
11:15 mupuf: ack :)
11:16 karolherbst: mupuf: but keeping the titan in should be a good idea, we have many tasks for it and when I got time for them I will be happy to see the titan there :p
11:22 karolherbst: mupuf: okay, even faking the vbios with those tables disabled still keeps nvidia writing this reg :/
11:24 mupuf: correlation != causation :p
11:24 mupuf: but you may be on the right path
11:26 mupuf: karolherbst: does the blob check anything related to pdisp before the reclocking?
11:26 mupuf: it may see you have no screen plugged
11:27 karolherbst: well it touches the reg on my gpu
11:28 karolherbst: but I also have a bunch of connections declared in my vbios allthough I don't have any ports on that GPU
11:28 karolherbst: but that might be because of the MXM interface
11:29 mupuf: that is going to be fun to figure out why we need to do thi
11:29 mupuf: s
11:29 karolherbst: mupuf: but I think we might have to read it out of the hardware to know it
11:29 mupuf: yep
11:29 karolherbst: mupuf: well, we get a badf1300 from the reg on his GPU
11:30 mupuf: and does the blob read it in the trace?
11:30 karolherbst: and even unposted I get 00f0ffff
11:30 karolherbst: no
11:30 karolherbst: it is just written in the SEQ script
11:31 mupuf: well, then ask for a big nvapeek of PPFB and PFB
11:31 mupuf: and maybe it will tell us what block it is from
11:31 mupuf: and maybe we know what it belings to
11:31 mupuf: and thar should help us
11:31 karolherbst: yeah, maybe
11:31 karolherbst: mhh
11:32 karolherbst: yeah, might be a good idea actually
11:32 mupuf: maybe it is a part that is fused out
11:32 mupuf: and reading the fuse would tell us this
11:32 karolherbst: ohh it is in PDISPLAY anyway...
11:32 mupuf: or it depends on the chipset
11:32 karolherbst: why didn't I checked before :D
11:32 karolherbst: mupuf: not really
11:32 mupuf: ...
11:33 karolherbst: mupuf: there are even nve4 and nve6 without this write
11:33 karolherbst: the only thing they had in common was empty CON tables
11:33 karolherbst: but
11:33 karolherbst: I didn't check for anything else
11:34 karolherbst: well, I think I will write to everybody who is missing this write
11:34 mupuf: no, ask one for now
11:34 karolherbst: anything special I should ask? or just a peek of the PDISPLAY area?
11:35 mupuf: and then write a little program that is supposed to detect whether or not you should do the write or not
11:35 mupuf: and send it to everyone in the vbios repo that has the involved hw
11:35 mupuf: and let the results come to see how close you were
11:36 karolherbst: mhh but for this I would have to somehow now what to check for :/ empty CON table is abit too vague
11:37 karolherbst: also, we can figure this out ourselves because we also have the traces mostly.... mhh it should be in the traces, right?
11:37 karolherbst: I just hope that isn't some stupid global flag they set and only read it out like once
12:08 karolherbst: mupuf: funny, that reg is also touched on nvd9
12:08 karolherbst: but not before
12:09 karolherbst: well there is only one nvd9 trace, so no idea if that's usually the case
15:13 imirkin_: RSpliet: well, nv30 fp doesn't have control flow at all. nv30 vp is supposed to have it, but i'm pretty sure it's bogus.
15:20 mupuf: imirkin_: the joy of old hw :p
15:21 imirkin_: i mean - i think that the VP control flow emitter is bogus
15:21 imirkin_: otoh, iirc i had that thought before, but then decided it was fine
15:21 imirkin_: but i've since forgotten the details... will have a look
15:21 imirkin_: also will try to touch up NPOT textures somehow
15:40 imirkin_: rmrfchik: iirc switching from nvidia blob to nouveau leaves display messed up. boot freshly. if you're still having issues, pastebin dmesg + xorg somewhere.
15:53 Tom^: holy moly 24gb vram on next titan
15:53 Tom^: =D =D
15:54 karolherbst: meh
15:56 karolherbst: the M6000 also has 24gb
15:56 imirkin_: my NV34 has 128MB
15:57 Tom^: your nv34 is cute.
15:58 imirkin_: i can arrange a meeting :p
15:58 Tom^: :)
17:07 karolherbst: mupuf: mhhh, at least on my GPU I can simply skip the write to that reg
17:07 mupuf: that may be related to the watermarks btw
17:08 karolherbst: which means?
17:08 mupuf: ah, sorry, linebuffer
17:08 karolherbst: ahh
17:08 karolherbst: yeah
17:08 karolherbst: I also tought about the linebuffer
17:08 mupuf: the unreal demos are really beautiful
17:08 karolherbst: maybe it is only important when there is a linebuffer
17:09 mupuf: I should have run them before
17:09 mupuf:is running the effects cave
17:09 Leftmost: If I'm reading this right, the TEP is pulling position information with PFETCH, so that presumably should already work with GM, and I'll focus on the other bits.
17:10 mupuf: Leftmost: good to see you are still here!
17:10 mupuf: that is waaaaayyyy more than a lot did :D
17:10 Leftmost: Heh, yep, haven't run screaming yet.
17:10 Leftmost: Yet. :)
17:10 karolherbst: mupuf: mhh, maybe we find something related to that in the tegra source?
17:11 karolherbst: ohh wait
17:11 karolherbst: the 3d engine doesn't do the display stuff, right?
17:12 mupuf: yeah, you won't see anything on the tegra source
17:12 mupuf: or ... will you?
17:12 mupuf: actually, yeah, they may have reused the block
17:12 karolherbst: https://people.freedesktop.org/~cbrill/dri-log/?channel=nouveau&date=2012-07-30
17:12 karolherbst: :D
17:12 mupuf: the addresses won't be the same, but check it out
17:13 mupuf: karolherbst: ?
17:13 karolherbst: nah, there was a reference to the reg in that log
17:13 Leftmost: Still going to have lots of questions to ask before I get anything working, but I'm making progress.
17:13 karolherbst: but it seems it was unrelated
17:13 imirkin_: Leftmost: pulling, or pulling correctly?
17:13 imirkin_: Leftmost: tbh i don't remember all the specifics
17:14 karolherbst: mupuf: uhh, and there is also no memory reclocking on tegra like on dedicated gpus...
17:15 Leftmost: imirkin_, I'm not certain, but in the IR that I printed out with nouveau_compiler, it uses PFETCH for the position coords, so if PFETCH lowering is working correctly and is the correct thing to use there, I'd assume it's working correctly. :-P
17:15 Leftmost: Not sure how to test that, though.
17:15 imirkin_: Leftmost: who said it was working correctly?
17:16 imirkin_: the way it's handled in GP isn't necessarily the same as in TEP, which isn't necessarily the same as in TCP
17:16 imirkin_: right now it works for GP
17:16 Leftmost: Ahh, so the PFETCH lowering could presumably need to be made conditional on shader type?
17:18 imirkin_: yes
17:18 imirkin_: prog->shaderType or so? i forget exactly.
17:22 Leftmost: Okay, that answers my (oblique) question.
17:22 imirkin_: prog->getType()
17:22 imirkin_: e.g. https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp#n2155
17:22 Leftmost: Thanks.
17:26 imirkin_: there's weird logic in there to handle geometry but not other types of programs? i have no idea why
17:27 imirkin_: i suspect that hunk is just plain wrong and should be taken out
17:27 imirkin_: or alternatively needs to be done for everything :)
17:28 imirkin_: ohhhh i remember. it's done different for nv50 and nvc0... i think that's why it's there
17:30 Leftmost: Well, dang. I was hoping I could cheat a little. :)
17:30 imirkin_: imho you're approaching this incorrectly
17:31 imirkin_: step 1 should be: figure out wtf blob is doing
17:31 imirkin_: once you can intelligently explain where the blob gets all these things, you'll be 90% of the way to the impl
17:31 imirkin_: and "all these things" aren't internal codegen fake-o instruction concepts
17:32 imirkin_: here are the questions you need to answer:
17:32 imirkin_: 1. for each of tcp and tep, how does blob fetch attribute N of input vertex M
17:32 imirkin_: 2. for each of tcp and tep, how does blob do #1 in the presence of indirection (on both the attribute and the vertex)
17:33 imirkin_: 3. for tcp, how does blob *fetch* attribute N of *output* vertex M [and again, with indirection]
17:33 imirkin_: 4. for tcp, how does blob store attribute N of output vertex M
17:34 imirkin_: 5. for tcp, how does blob fetch and store per-patch output N
17:34 imirkin_: 6. for tep, how does blob fetch per-patch input N
17:34 imirkin_: and obviously add indirection to 4, 5, 6
17:34 imirkin_: since what fun is life without indirection
17:34 imirkin_: once you can answer all those questions, you're basically done.
17:34 imirkin_: until you can, you have no real business even looking at codegen code.
17:36 imirkin_: for each of these ~20 cases (once you expand out for indirection/etc), you need to write a short piglit shader test, and trace it on the blob.
17:36 imirkin_: you should then hopefully have a full picture of what's going on
18:01 Leftmost: imirkin_, I'm trying to come at it from both directions, essentially. Figuring out what the blob is doing while also trying to learn how the existing code is structured so that I can meet in the middle.
18:02 imirkin_: nice article about compilers (old-ish): http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html
18:02 imirkin_: popped up on HN
18:03 Leftmost: I'm asking more questions about codegen essentially because I understand it better and find it easier to ask questions about it. I'm still working up to the point where I feel I can intelligently ask about what's happening in the blob traces.
18:04 Leftmost: I may well be taking the wrong approach, though. It's a new space for me to work in, so I'm still finding my way.
18:04 imirkin_: well, you're feeding some programs into the blob, with which the blob is generating some program
18:04 imirkin_: i can guarantee you that there's a high correlation between the glsl you write and the instructions the blob emits
18:04 imirkin_: (unlike, say, for a4xx geometry shaders, where it was all quite a mystery for a while)
18:05 imirkin_: you need to be able to say, "yes, i understand exactly what instructions to emit for this program"
18:05 imirkin_: once you can do that, it's all a matter of modifying codegen to our collective will, which is pretty easy
18:06 Leftmost: Alright. Thanks for the guidance.
18:07 imirkin_: if you have questions about specific code sequences, i can likely help
18:08 imirkin_: since i've already stared at it all for a while
18:08 imirkin_: what i haven't done is the laborious work from above and put it all together
18:18 Leftmost: Thanks for your patience as I get my feet.
18:38 night199uk: hey, anyone understand the code in gf110_disp_intr_supervisor well?
18:40 imirkin_: no :)
18:41 night199uk: haha
18:41 night199uk: anyone that understands it better than me? ;-)
18:41 imirkin_: likely
18:41 imirkin_: skeggsb's your man
18:42 night199uk: i have some kepler code that basically reads 0x6101d4 + (HeadIndex << 11) & 0x1000
18:42 night199uk: which according to that function seems to check for some kind of supervisor interrupt?
18:42 night199uk: i need to port that back to fermi
18:43 night199uk: which I believe would result in a test against 0x610030 & (0x20 << Head)
18:43 night199uk: i think that would be the parallel operation on fermi :-)
18:44 imirkin_: so... gf110 applies to, confusingly, not gf110. it applies to gf119 and kepler
18:44 night199uk: i got my custom UEFI firmware running on maxwell, kepler and fermi now but I’m backporting some of the changes from 84.x nvidia firmware to fermi
18:44 imirkin_: (and gf117 technically, but in practice, gf117 doesn't have display)
18:44 night199uk: well, the 0x6101d4 seems common to all kepler and maxwell
18:44 imirkin_: yeah
18:44 imirkin_: so....
18:45 night199uk: in the uefi driver its done for all kepler and maxwell cards
18:45 imirkin_: it's just a different offset
18:45 imirkin_: or a different size
18:45 imirkin_: hold on
18:45 imirkin_: even i can help with THAT one ;)
18:45 night199uk: well, 0x6101d4 is a sparse register? dunno what you guys called it. it’s 0x6101d4 + (HeadIndex << 11) to calculate the mmio address
18:45 imirkin_: yeah, hold on
18:45 night199uk: whereas on fermi it seems like it’s a bitmask by head
18:46 night199uk: all in 0x610030
18:47 imirkin_: gf119_disp_intr_supervisor -
18:47 imirkin_: mask[head] = nvkm_rd32(device, 0x6101d4 + (head * 0x800));
18:47 imirkin_: like that, right?
18:47 night199uk: thats the one
18:48 imirkin_: so that's the gf119 one, which is for gf119 and kepler+
18:48 night199uk: this is tested like this
18:48 night199uk: if (!(mask[head] & 0x00001000))
18:48 night199uk: it’s that test i want to replicate on fermi
18:48 imirkin_: and for g80+, it's this:
18:48 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/disp/nv50.c#L729
18:48 imirkin_: a bit more complex than 0x20 << head, but close.
18:48 night199uk: yup
18:49 night199uk: that’s what i was looking at
18:49 night199uk: so in fermi it tests 0x20 << head AND 0x80 << HEAD
18:49 night199uk: was just wondering about the difference
18:49 imirkin_: not just fermi. all tesla too.
18:49 night199uk: and what is disp->super?
18:49 night199uk: sorry, yeah, tesla too
18:49 imirkin_: it's written by the supervisor work iirc
18:50 night199uk: what is the supervisor in nouveau speak?
18:50 imirkin_: er no
18:50 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/disp/nv50.c#L779
18:50 night199uk: i saw a reference to modesetting?
18:50 imirkin_: it's written in the intr handler
18:50 imirkin_: the idea is that when you get an interrupt, you don't want to do a lot of work
18:50 imirkin_: so you do the minimum possible and then schedule work for "later"
18:50 imirkin_: so that you don't mess up the system
18:50 night199uk: right, so this is like the top half interrupt handler?
18:50 imirkin_: that is done in a workqueue, in this case, the "supervisor" workqueue
18:50 night199uk: yup
18:50 night199uk: got it
18:51 imirkin_: so nv50_disp_intr gets called by the irq handler
18:51 night199uk: so nv50_disp_intr is the top half, and intr_supervisor is the bottom half?
18:51 imirkin_: and nv50_disp_intr_supervisor gets called from the workqueue
18:51 imirkin_: disp->super is just a value passed from the top half to the bottom half
18:51 night199uk: i got it, so the disp->super test just checks the type of interrupt that was generated perhaps to see if it was a pdisp interrupt or so?
18:52 imirkin_: something like that
18:52 night199uk: got it
18:52 night199uk: so i wonder why two tests in fermi? 0x80 and 0x20?
18:52 imirkin_: there are 2 heads and 2 crtc's
18:52 imirkin_: i think they can be wired up however you want
18:53 imirkin_: not 100% sure, but that's my quick theory ;)
18:53 night199uk: so 0x20 << Head would be one crtc and 0x80 << Head would be the other crtc?
18:53 imirkin_: for example.
18:54 imirkin_: but why it wants BOTH of them to be set ... that's odd.
18:54 imirkin_: but what do i know.
18:54 night199uk: plenty more than me apparently :-)
18:54 imirkin_: btw, note that HDMI registers also moved between gf119 and kepler.
18:54 night199uk: ahh yeah
18:55 night199uk: that i’ve dealt with
18:55 imirkin_: it mostly doesn't matter, but if you don't pay close attention you can wind up with a purple line on the side
18:55 night199uk: it’s 100% working HDMI & DVI for all cards
18:55 imirkin_: that's a bold claim.
18:55 imirkin_: have you tested on a GF119?
18:56 night199uk: okay, maybe not :-)
18:56 imirkin_: which is different than the other fermis, and different than keplers
18:56 night199uk: gts450 is a GF119?
18:56 imirkin_: unlikely
18:56 night199uk: i thought i had a GF119, hrm, sec
18:57 imirkin_: it'll usually be one of the really low end gpu's
18:57 imirkin_: like a GT 520
18:57 imirkin_: etc
18:57 imirkin_: they alternate what chip they actually stick into those
18:57 imirkin_: GF108 or GF119
18:58 night199uk: hrm, i have nothing 5xx series here
18:58 imirkin_: GT 610/620 can be it as well
18:58 imirkin_: or GT 430
18:58 night199uk: I have a GT630
18:58 imirkin_: that's usually a GF108 or GK107 or GK208
18:58 night199uk: i thought the old GTS450 was GF119 as well, which was working but i binned it
18:58 night199uk: My GT630 is GF series
18:58 imirkin_: GTS450 is most likely a GF114 or so.
18:59 night199uk: ahh yeah, that sounds right actually
18:59 night199uk: maybe i need to dig out a GF119
18:59 imirkin_: ah no. apparently either GF106 or GF116
18:59 night199uk: well, so far I’m testing on GTS450 (binned now), GT630, GTX650Ti, GTX980
18:59 night199uk: so yeah, all cards might be a bold claim :-)
19:00 night199uk: should get a GT7xx series to test shortly
19:00 imirkin_: 4 cards :)
19:00 imirkin_: that's ... like all :)
19:00 night199uk: hahaha
19:00 night199uk: alright whatever ;-)
19:00 night199uk: the uefi drivers don’t change much though
19:01 night199uk: it’s only 2d and mode setting
19:01 imirkin_: yeah, the display stuff tends to be simple-ish
19:01 night199uk: ‘only'
19:01 imirkin_: once you figure it all out
19:01 night199uk: most of it’s pretty generic
19:01 imirkin_: i'd spend some time looking over https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/engine/disp
19:01 night199uk: haha
19:01 imirkin_: there are lots of various cases... esp for DP and whatnot
19:02 night199uk: i’ve spent so much time looking over that ;-)
19:02 imirkin_: dvi/hdmi tend to be "easy"
19:02 night199uk: yeah, i just finished porting the DP code now, have to test
19:02 imirkin_: i think it's taken ben like 8 different attempts to get it right
19:02 imirkin_: still not quite there, but trending :)
19:02 night199uk: hehe
19:03 night199uk: well this is somewhat easier, as at least right now i’m just staying 1:1 with the nvidia uefi driver
19:03 imirkin_: so ... if it looks like the code does something crazy, chances are it's for a reason
19:03 night199uk: so if it’s broken it’s just find where my code differs from nvidias
19:03 imirkin_: oh, so you're just decompiling the nvidia code?
19:03 night199uk: i would say i understand only about 40-50% of what i ported
19:04 night199uk: yeah, for the most part
19:04 night199uk: once it’s done i’m looking to add features
19:04 night199uk: e.g. i’m porting the Mac OS X support from the gtx680 and other drivers back into the gtx980 drivers
19:05 night199uk: might try and implement bios configurable overclocking for nvidia cards, etc
19:05 night199uk: though not sure if this would work out yet
19:06 night199uk: so you don’t have to flash your bios every time you want to overclock, if you overclock
19:07 night199uk: and e.g. this allows you to have a GOP driver on cards that have no GOP driver at all
19:12 night199uk: boom :-)
19:12 night199uk: that worked, thanks imirkin
19:12 night199uk: now booted on fermi
19:12 imirkin_: congrats
19:16 night199uk: yeah, pretty cool
19:16 night199uk: booted gop on a card that doesn’t even have a publically available gop driver :-)
19:17 imirkin_: gop?
19:17 imirkin_: (to me, gop = group-of-pixels...)
19:17 night199uk: bios fast boot mode
19:17 night199uk: ‘windows 8 mode'
19:17 imirkin_: ah cool
19:18 night199uk: booting the card from EFI instead of legacy BIOS/CSM
19:18 imirkin_: do you need a 'special' motherboard for that?
19:18 night199uk: anything post 2008 or so
19:18 imirkin_: (e.g. one with coreboot or whatever support)
19:18 night199uk: nah
19:19 night199uk: anything commercially available after actually maybe 2010 or so based on AMI Aptio IV or V BIOS
19:19 night199uk: e.g. mode gigabyte, msi, asus you can buy off the shelf
19:19 night199uk: all modern intel boards
19:19 imirkin_: well, i bought my desktop in ~2010, but it's pre-EFI :)
19:19 night199uk: not even hybrid?
19:19 night199uk: which MB?
19:19 imirkin_: i dunno. some gigabyte mobo
19:19 imirkin_: core i7-920 cpu
19:19 night199uk: which chipset?
19:20 imirkin_: don't remember
19:20 imirkin_: (and am not in front of it)
19:20 night199uk: i thought giga had for most of their old MBs now
19:20 night199uk: they backported aptio iv to a lot of boards, I have some LGA1155 stuff with hybrid
19:21 night199uk: lga1366, hrm, might be on the cusp :-)
19:22 night199uk: actually, hrm, should have
19:22 night199uk: anyway for most users UEFI just == faster boot times
19:23 night199uk: but for hackintoshes the Apple BIOS is UEFI from day 1 so it makes life a lot easier to hackmac ;-)
20:16 karolherbst: l1k: seems like your patches work
20:17 karolherbst: can't say much about overall stability though
20:33 karolherbst: mupuf: hui, found a kernel crash when the user would poke an unknown pstate into the pstate file :)
20:33 karolherbst: but everybody is free to test my stuff for other crashes, don't want to mess up hardrives :D
20:49 karolherbst: mupuf: do you know how I could check if the gpu is currently suspended or not?
20:57 karolherbst: ah, pm_runtime_suspended :/
20:57 karolherbst: mhh
20:57 karolherbst: this is like a linux API which I shouldn't use in nvkm
21:00 l1k: karolherbst: sorry, I was briefly AFK. thanks a lot for testing.
21:01 l1k: karolherbst: if you do find any remaining runtime pm issues please let me know.
21:01 karolherbst: l1k: yep, will do
21:07 l1k: karolherbst: I'll include a Tested-by when I post this so that you get credit for your testing efforts, ok?
21:07 karolherbst: yeah, no problem
21:08 karolherbst: stupid kernel ...
21:12 karolherbst: mhh
21:13 karolherbst: memory relcoking fails after going from suspend when I switch the pstate in suspend
21:14 karolherbst: uhh
22:14 imirkin_: skeggsb: fyi, got a partial answer to the hdmi mhz thing: https://github.com/Gnurou/nouveau/issues/10
22:14 imirkin_: seems like it's still a bit off though
22:16 imirkin_: either way might be interesting
22:16 skeggsb: yeah, just been reading that :P
22:17 airlied: imirkin_: btw there were patches on dri-devel for dongle detection recently
22:17 airlied: DP++ support I think it was called
22:17 imirkin_: well, the reality is that i know ~nothing about that stuff, and don't personally have the hw for it
22:17 imirkin_: airlied: i think that was for i965
22:17 skeggsb: imirkin_: i'll tackle it in the next couple of weeks if you don't beforehand
22:18 imirkin_: skeggsb: i most likely won't... will be keeping busy with the nv34 i expect
22:18 skeggsb: what're you doing with that?
22:18 imirkin_: fixing it :)
22:18 imirkin_: and then i want to see if i can get it to expose nv20 hw
22:18 skeggsb: i don't suppose you're doing something saner re: the "compiler" ?
22:18 airlied: imirkin_: it was for the generic code as well
22:18 imirkin_: like gr classes
22:19 airlied: you'd need that code to fix the nouveau code
22:19 imirkin_: coz then i can test nouveau_vieux with it :)
22:19 imirkin_: airlied: if you say so. afaik nouveau knows nothing of dongles, they just show up as regular ol' hdmi links.
22:19 imirkin_: airlied: but perhaps if we look in the right place, it tells "hey, i plugged in a dongle"
22:20 airlied: imirkin_: that's because you don't ask the hw if a dongle is there
22:20 imirkin_: oh, i ask it. loudly. but it never answers :)
22:20 imirkin_: i've tried multiple languages, but to no avail
22:20 RSpliet: try C
22:21 mupuf: karolherbst: hey, make sure the state of run_pm does not change between the moment where you check and the moment you need it in a certain state
22:21 imirkin_: (i do remember once buying a mobo that had a fancy bios voice thing instead of post codes, and had jumper switches for english and vietnamese as the two options)
22:21 imirkin_: anyways... i don't have any nvidia hw with DP outputs, so it's all a bit moot
22:22 imirkin_: and at home, my monitor doesn't even have a HDMI input :)
22:23 RSpliet: imirkin_: I can dig through my stash if you're really really keen, but it sounds like you'd much rather dive into nv20/nv30
22:23 imirkin_: RSpliet: hm?
22:23 RSpliet: I've got one or two Fermi cards that may or may not have DP
22:24 RSpliet: not home until Wednesday
22:24 imirkin_: oh ok. well, i'm happy to let ben have at it... he has the expertise and hw
22:24 RSpliet: probably better
22:24 imirkin_: i have ... neither.
22:24 karolherbst: mupuf: funny :/
22:24 karolherbst: mupuf: maybe we should interrupt specific things while going into suspend?
22:24 karolherbst: or set the runpm use counter right
22:25 mupuf: karolherbst: well, you can always ask airlied how he planed to handle this, since he is here right now
22:25 karolherbst: well, in the end whenever we do something with the hardware, the runpm counter shouldn't be 0
22:26 karolherbst: even if we think the hardware is in use, this might change
22:26 karolherbst: even while reclocking
22:27 imirkin_: skeggsb: might also finally take care of the stupid color vs depth format thing
22:28 imirkin_: skeggsb: and, if no one objects, modify mesa to get it to report GLES2
22:28 imirkin_: skeggsb: this is the current list of fail - https://people.freedesktop.org/~imirkin/nv30-gles2.fail - mostly control flow
22:29 imirkin_: going to look into all the others in more detail
22:30 imirkin_: i guess some pretty basic things are missing, like separate rgb/alpha blend equations =/
22:38 karolherbst: skeggsb: saw my comment aout that 0x6c2000 reg?
22:38 imirkin_: karolherbst: what does envytools say about that reg?
22:38 imirkin_: karolherbst: if it's PDISPLAY+... could it be that PDISPLAY is just fused off on those chips?
22:39 karolherbst: *62c000
22:39 karolherbst: imirkin_: yeah, might be
22:39 imirkin_: we detect that already
22:39 imirkin_: and try very hard not to touch PDISPLAY
22:39 karolherbst: imirkin_: anyway, not touching that reg on my GPU doesn't make any difference
22:39 imirkin_: yeah, coz you don't have any displays hooked up :p
22:39 karolherbst: imirkin_: how can I detect if PDISPLAY is fused out?
22:39 karolherbst: :D
22:39 karolherbst: right
22:39 imirkin_: can you do a lookup on that reg?
22:39 karolherbst: I have the mmiotrace
22:40 karolherbst: ohh
22:40 karolherbst: lookup doesn't say anthing
22:40 imirkin_: it's gotta say SOMETHING
22:40 karolherbst: PDISPLAY+0x1c000
22:40 imirkin_: ok. so it's PDISPLAY :)
22:40 karolherbst: yeah
22:40 imirkin_: that's what i was looking for
22:40 karolherbst: ahh
22:40 karolherbst: okay
22:40 karolherbst: I thought you already knew
22:40 imirkin_: i guessed
22:40 karolherbst: I see
22:40 imirkin_: 6..... sounded pdislay-y
22:40 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_display.c#L496
22:41 imirkin_: we use drm->vbios.dcb.entries to determine it
22:41 imirkin_: if there are no DCB entries, then no-touch
22:41 karolherbst: ahh
22:41 karolherbst: well
22:41 imirkin_: however deeper down in the code
22:41 karolherbst: nvidia still touched it with and empty DCB and CON table
22:41 imirkin_: you could do if (drm->disp) or something
22:41 imirkin_: are you sure the DCB was empty?
22:42 karolherbst: I set the entry field to 0x0
22:42 imirkin_: well it might have a diff way of detecting whether PDISPLAY is there
22:42 karolherbst: most likely yes
22:43 karolherbst: but can I just use drm->disp in nvkm?
22:43 skeggsb: it's a register used to enable/disable display's access to memory
22:43 karolherbst: ahhh
22:43 karolherbst: that explains it
22:43 karolherbst: skeggsb: and what if there is no display?
22:44 karolherbst: for one user it caused the MC to crash completly
22:44 karolherbst: writing that reg that was
22:44 karolherbst: even if it was badf13000
22:44 karolherbst: *badf1300
22:44 skeggsb: nvkm_device_engine(device, NVKM_ENGINE_DISP) will return NULL if display has been fused off
22:45 karolherbst: okay
22:46 karolherbst: well it would had been nice if we would have this information also in rnndb, by the way ;)
22:46 skeggsb: and the "f" is a mask of heads
22:46 skeggsb: (in the writes to that reg)
22:46 karolherbst: mhh
22:46 karolherbst: on nvd9 they use 3
22:46 karolherbst: instead of f
22:46 skeggsb: yes, "head 0 + head 1"
22:46 skeggsb: gf119 only has 2 heads
22:46 karolherbst: I see
22:52 karolherbst: skeggsb: so something like that? https://github.com/karolherbst/nouveau/commit/d450101eb6d9e351733ef7a8d56f16050355c2e7