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