10:02bazzy: I'm having some serious trouble understanding how to deduce ID from the 0x0 PMC reg. given the envytools doc it looks like the ID could be in a number of places, but how do I properly deduce it if I don't know the family my GPU belongs to?
10:03mwk: there's a heuristic involved
10:03bazzy: I'm just trying to read it manually as an educational exercise
10:05bazzy: I'd like to at least learn how to deduce NVxx from my GPU
10:05mwk: you have to tell the formats apart
10:05mwk: the old two ones are only used for really old cards, so you could just identify those by pciid ranges
10:05mwk: there are like 4 of them total
10:05bazzy: I'm interested, my card is legacy
10:06mwk: but if you want to do it from just PCI ID, you can use the heuristic used by envytools
10:06mwk: er, from just PMC ID
10:06bazzy: i wasn't sure what bitfield to read from PMC because they are all different based on NVxx which is unknown
10:06mwk: I even documented it
10:07bazzy: oh cool thanks
10:07bazzy: good on you :)
10:08bazzy: at least now I know NV10+ lil endian
10:10bazzy: if I'm reading the doc right, there's now 3 different bitfield ranges it could be in (NV10 section on PMC 0x0)
10:11mwk: the main chipset id is always in bits 20-28
10:11bazzy: Oh whoops!
10:11mwk: on NV10+
10:11bazzy: I just noticed lol
10:12bazzy: ah, so NVAC or NV172?
10:12bazzy: that doesn't seem right
10:13mwk: NVAC sounds right
10:14mwk: is it an IGP on a 2008-era motherboard?
10:14bazzy: could be IGP, yes
10:15bazzy: ah so it is NVAC.
10:16bazzy: and it's not in the doc list?
10:16mwk: sure is
10:16mwk: it's called MCP79
10:16mwk: and has chipset id 0xac
10:17bazzy: hm. it's hard to search or? NVAC yielded nothing in the doc search bar.
10:17bazzy: Lot's of indirection and substrings X_X
10:19bazzy: MCP79 is also Tesla family?
10:21bazzy: I'm eager to learn so I can fix that bug I'm dealing with
10:24bazzy: Wow, I had no idea this was in the Tesla family that college phD use to rage about 5 years ago. Guess my laptop had the early lil taste of it
10:24bazzy: Too bad I've had to say goodbye to virtually any CUDA support
10:34bazzy: i guess my confusion stemmed from some GPU are called NVxx, but then they decided to call mine MCP79 instead of NVAC ? either that or.. :X
10:34bazzy: if you like in the Curie family they call it the NV40, but in the Tesla family it says MCP79, that kind of thing.
10:40bazzy: OK OK , well nobody's perfect. I'll work with it :D
10:47bazzy: ah so NVAC == MCP79 == G200 subfamily
11:29RSpliet: bazzy: Tesla family != Tesla range
11:30RSpliet: Tesla family is the codename used by NVIDIA for the cards between G80 all the way up to G(T(X))2xx
11:30RSpliet: Tesla range is a series of high end headless GPUs with advanced error correction and faff, designed solely for compute and off-line rendering
11:30RSpliet: (a name that is used across families)
11:32RSpliet: that's UK English for "shit" or "stuff" more politely
11:32bazzy: ah thought so
11:33RSpliet: (coincidently, also a verb)
11:33bazzy: thanks for the eye-opener
11:33RSpliet: Haha no worries
11:33RSpliet: So what's wrong with your MCP79?
11:33bazzy: not surprised there's another discrepancy to learn
11:34bazzy: oh, there's screen flicker when I use the mini DisplayPort (mDP) on my macbookpro 2009
11:34RSpliet: Ah... have you tried clocking your GPU up a bit?
11:35bazzy: Ah yes I have, to no avail. It might seem hasty, but I've done some MARK'd mmiotracing on nvidia blob and nouveau, I'm aiming to identify the issue and fix
11:37bazzy: what's even stranger is that lately, I can unplug it without it locking my system up or making my LVDS flicker. :B
11:38RSpliet: Well presumably that's intended
11:38RSpliet: We've had quite a big display rewrite (atomic modesetting) and a few bugfixes both in the process and afterwards
11:39bazzy: the result had changed while on the same version of nouveau. Unfortunately it's another unknown twist
11:39RSpliet: first thing I would say is while debugging, keep flinging new kernels at your machine. If you have a 4.14 kernel lined up give it a go. Even if it doesn't help, it rules out chasing bugs that have been solved since
11:40bazzy: I'll certainly do that
11:40bazzy: as per your recommendation :)
11:40RSpliet: that's all just very high level stuff sorry, I'm not too immersed in display code
11:42bazzy: Worth a shot
11:42RSpliet: Running those 2 monitors shouldn't require more than 650MiB/s from your DRAM subsys. Presumably your system has DDR2 at like 1066MHz?
11:43bazzy: sounds about right, d'ya know how I can check quickly?
11:44RSpliet: Oh, DDR3. Fancy
11:44bazzy: and nvidia-blob runs it fine. nouveau ran it fine one time, cause unknown.
11:45bazzy: yeah this laptop has served me very well
11:45bazzy: I did some 3rd party upgrades HDD / RAM cap
11:45RSpliet: That should definitely be able to deliver the bandwidth for those two monitors
11:45RSpliet: So... there's a couple of suspects
11:46RSpliet: 1) We might simply not be playing well with the mDP->DVI converter. Those things are notoriously buggy in HW (except a few good ones...), and poorly tested with nouveau
11:47bazzy: sounds about right
11:47bazzy: i like to think I have a good one
11:48RSpliet: 2) We're not configuring the line buffer currently, meaning that we don't efficiently shift pixels from RAM to your displays the most efficient way. On shared sysram systems this could prove a real problem because latencies could cause buffer underruns
11:48RSpliet: Can you try running the system with *just* the external monitor, and see if it still flickers if you disable the internal panel?
11:48bazzy: I thought I had tried that but I can't recall. So I will try it now. I seem to recall it flickering.
11:50bazzy: oh guess what. I think I've run into the 2nd accidental time it runs without flicker
11:50bazzy: this is running dual screen as well
11:50bazzy: i have no idea what causes it lol
11:51bazzy: it's happened twice out of about 10 serious trials
11:51bazzy: recent trials
11:52bazzy: lol, so I will have to force it to flicker at this point, by unplugging and replugging. or rebooting.
11:53bazzy: i will say this
11:53bazzy: both times that it worked without flicker, I had the computer running for hours before plugging in the mDP adapter
11:54RSpliet: Ah... so not a difference between at boot config vs. runtime config?
11:54bazzy: and perhaps 24 hours+ since the last time I plugged in the adapter
11:55bazzy: well I've experimented with having the monitor plugged in at boot, or plugging in after boot. and it flickers either case. It is something else that leads to flicker free scenario (see aforementioned variables)
11:57bazzy: well for now I'll try replugging the adapter to see if it spawns the flicker. Last time I got no flicker, I had to reboot for it to come back.
11:57bazzy: just replugged, it seems good
11:57bazzy: usually loading chrome will cause a lot of flicker, but this time all good
11:57bazzy: so then, shall I reboot and report back to you?
11:58RSpliet: You could, but this is a variable which I can do very little with... uptime is not a sensible parameter.
11:58bazzy: I think I can save the trouble and just say -- it will flicker even when the DP screen is the the only one activated. I recall correctly.
11:59RSpliet: That's an important thing to verify. If it flickers with just DP, it's likely a problem in the display code. If not, it's a problem in the fb
11:59bazzy: so the display code is at fault
12:01bazzy: but there is also this strange case when it won't flicker, that I can only seem to measure by extensive uptime before hotplug, given the meager 2 cases it has occurred and what seems to be in common
12:02bazzy: I think you are a good diagnoser
12:03bazzy: I still have a large gap until I understand the codebase I'm dealing with here
12:03bazzy: and the applicable components that relate to my issue
12:04bazzy: in the code sense
12:04bazzy: but hey, I just got 4.14.5, so I'll see what happens with that
12:13skeggsb: RSpliet: i pushed fermi mclk stuff btw
12:14skeggsb: still not complete, but branches merged together, and "perfect" for the boards i have
12:15skeggsb: i've potentially broken gt215/gk104 in minor ways, but i'll test/fix all that up further down the road
12:15skeggsb: >=gk104 will get another full look over + improvements at least, before i merge it.. potentially moving all that back to gf117 (which i think is nearly identical to gk104)
12:16skeggsb: gf119, however, is closer to fermi's code
12:20RSpliet: skeggsb: that's great news, thanks!
12:20RSpliet: I'll make sure to give them a roll and report back
12:21bazzy: I ought to thank you for your support RSpliet
12:21bazzy: Thanks :)
12:22RSpliet: bazzy: well, until your problem is fixed nothing to be too proud of ;-)
12:22skeggsb: i'd be very interested in vbios images, and traces of RM (i think i used 387.22) going from boot perflvl -> X -> glxgears -> kill glxgears -> wait for nvidia-settings to return to lowest perflvl
12:23skeggsb: (both for boards that appear to work, and ones that are broken)
12:23bazzy: 4.14.5 compiling as we speak
12:23skeggsb: oh, including "unload module" in those steps too
12:24RSpliet: skeggsb: I'm currently away from my boards until the 5th of January, be happy to test some of the boards when I get back
12:24skeggsb: no worries, i'm flying home for the xmas/nye break tomorrow also, back on the 3rd i think
12:24RSpliet: "gf117" == NVCE?
12:25skeggsb: i'll probably bring a laptop with me anyways (fiddle with volta isa reverse-engineering when i'm bored), but won't be able to do a lot from there
12:25skeggsb: i don't recall what that is, it's a weirdo laptop-only chipset right at the end of the fermi family
12:25RSpliet: Hahahaha, never giving up eh!
12:25skeggsb: i think it's the last released fermi chipset
12:25RSpliet: Ah, no then NVCE must be gf119. I had access to such a board but returned it to its owner recently
12:25skeggsb: oh, no, silly me, it's nvd7
12:26skeggsb: nvce is gf114
12:27RSpliet: I was already consulting the CodeNames wiki to correct myself
12:27skeggsb: i just had brain-fuzz for gf117/gf119, those ones are easy :P had to check for gf114 though ;)
12:29RSpliet: Which cards have you tested on?
12:29skeggsb: i don't have many fermi boards.. 2xgf100 (quadro 4000, gtx 465, both gddr5), and gf108 (quadro 600, ddr3)
12:30skeggsb: i have a gf119, but i couldn't get it to POST...
12:30skeggsb: but, like with kepler, i massively fuzzed the vbios, so hopefully most cases were caught with that
12:31RSpliet: Yeah... GF114 is an oddball though from what I recall
12:31skeggsb: hm, and a Quadro 2000 too
12:31skeggsb: think that's gf106 (also gddr5)
12:31skeggsb: i forgot to re-test that one today after i finished some final cleanups, but it worked last i checked
12:33skeggsb: RSpliet: https://github.com/skeggsb/nouveau/commit/4fd99ca578ad7ab5a155e00ba70ff53d5fe90681
12:34skeggsb: that one was fun...
12:34skeggsb: implemented a bit differently to nvidia.. they use seq opcodes 0x39/0x3a (iirc) for this
12:34skeggsb: i was lazy, and implemented it like older RM versions do for now
12:34skeggsb: (which, fortunately, helped with figuring out wtf those opcodes were for)
12:35skeggsb: looks like a hw bug to me
12:36RSpliet: WAR as in write after read?
12:36skeggsb: nvidia's name for "workaround"
12:36skeggsb: i think intel use WA
12:38skeggsb: without that, whole bunches of reg writes just seem to be ignored on my gddr5 boards
12:38skeggsb: the ddr3 one didn't seem to care, but nvidia's seq script does it still
12:39RSpliet: Ah yes those are the spurious writes sprinkled randomly over the scripts
12:39skeggsb: and that code makes us do exactly the same thing in the same places :P
12:39skeggsb: it took a while to get "right"
12:39RSpliet: Can imagine...
12:39skeggsb: where "right" means: works on my boards ;)
12:40RSpliet: Hahaha fair
12:40RSpliet: Looks like an impressive set of work. Look forward to giving it a spin
12:40skeggsb: i suspect those register ranges could use some tweaking, but we'll need more data to figure that out
12:41RSpliet: Brace yourself for the GF114 results, but I don't have direct access to that one anymore anyway
12:42RSpliet: There's an GF104 in my cupboard that I have good hopes of working straight away. Esp since I had it going to the middle perflvl without much pain ;-)
12:44RSpliet: skeggsb: Is this the final form you want to push this upstream, or do you intend to collapse patches? I might do some work on top (really on top, not interleaved) to forward-port e.g. https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/e620313d95a2b30e429692dc65475634f7ad8db3
12:45skeggsb: it'll be in approximately that form
12:45skeggsb: how certain about those names are you?
12:46RSpliet: It's the only sane explanation after comparing the values in VBIOS with the datasheets I've found
13:16bazzy: RSpliet: flicker on 4.15.5
13:16bazzy: so I have my work cut out for me
13:20bazzy: something I noticed though - mDP monitor seemed stretched in VT (not X) when it is flicker free. But, seems normal when I have flicker.
13:26bazzy: scratch that, I managed to recreate the stretch scenario (just hotplug in X rather than boot plugged in) but it's flickering anyways. so that's not a correlation
14:06feaneron: what does TMDS stands for?
14:06feaneron: stand* for, even
14:08feaneron: nevermind. searching for "tmds table" in google yells completely different results than just "tmds"
14:09feaneron: sorry for the noise
15:44bazzy: I have figured out the magic sauce that gets the flicker to disappear. it's `pm-suspend` -- for some reason, the flicker disappears after waking from `pm-suspend` Any thoughts on this? RSpliet pmoreau karolherbst imirkin imirkin_ anyone?
15:46bazzy: Note: I am currently testing from kernel 4.14.5. I believe this behavior is consistent on 4.12.12 and possibly further back.
15:53karolherbst: bazzy: mhh interesting. Do you reclock the GPU?
15:54bazzy: reclock the gpu? Can you phrase that any differently?
15:56bazzy: if you mean 'change pstate manually' then no
15:58imirkin: on resume we run the vbios scripts
15:58imirkin: on boot, we probably don't because the vbios already has
15:59imirkin: you can force it on regular boot with nouveau.config=NvForcePost=1
15:59bazzy: Ou O
15:59bazzy: I'm gonna try this!
16:00imirkin: (there's a dance to figure out whether it has or not, but in your case, it almost certainly decides that the scripts have been run)
16:01bazzy: so then perhaps it has decided incorrectly?
16:01imirkin: i'm sure they have run.
16:02imirkin: otherwise you wouldn't be getting a display
16:02imirkin: but it could be that the interpreter skimps on DP support and so some bits don't run
16:02imirkin: or it could be something else entirely
16:04imirkin: coudl also matter whether you have it plugged in on boot or not
16:11bazzy: well, so far I've tested with the force POST config setting while the monitor is plugged in on boot. and I'm not getting any flicker :) Now I'll try booting with it unplugged, and plugging it in after X has started
16:13bazzy: no flicker in that scenario as well :)
16:14imirkin: gtg. good luck
16:15bazzy: config=NvForcePost=1 has fixed the issue! not exactly sure why ^_^
16:16bazzy: I will continue testing with this configuration for some time before coming to final conclusion.
16:41karolherbst: imirkin: I have a question related to ubos, are those always stored inside c1 in fragment shaders?
16:44karolherbst: mhh, wait, that doesn't make much sense anyway
16:48karolherbst: ohh, now it makes sense
17:06karolherbst: ohhh, tgsi also does a +1 of the block constant
17:06karolherbst: I was confused, because NIR gave me 0 as the buffer_index and TGSI printed 1
17:37mslusarz: karolherbst: congrats on your new job
17:37karolherbst: mslusarz: thanks :)
18:50NSA: karolherbst: uhm
18:50NSA: so the active dp -> hdmi adapter arrived
18:51NSA: monitor actually shows receiving 4k 60hz
18:51NSA: it has some small display issues though
18:53NSA: https://files.xmpp.msg.lol/30bbd36d-2ee8-4ab6-961a-b858c8dbb6e6/BvXjBSdhRauJ-A4f3EGcdA.jpg https://files.xmpp.msg.lol/67037451-82d6-4eb8-ad8a-c722b83b8d6c/DLhElqQeRferay1rQaEESw.jpg
18:56annadane: NSA has infiltrated nouveau
18:57NSA: annadane: it's easier to list what we don't have infiltrated
19:03infinity0: RSpliet: a friend said you needed testers for this? https://github.com/skeggsb/nouveau/commits/devel-clk
19:04infinity0: but also apparently "they however do not apply cleanly to the linux kernel"
19:40karolherbst: imirkin: another thing: I noticed that with nouveau there is an export after the last emit, or rather more exports than in the shader and that's already added at the glsl level, but when I use nir I don't get those. Do you know what that is related to?
19:44NSA: karolherbst: i believe that it might be bad because of an hdmi 1.4 cable
19:45NSA: i'll borrow a 2.0 cable on the 24th to test with a good cable
19:59karolherbst: NSA: might be, yeah
19:59karolherbst: looks fun though
20:00karolherbst: does it flicker or change a little if you bend/move the cable?
20:02NSA: testing that will be some effort
20:02NSA: can't see the screen when i'm near the cables
20:49pmoreau: bazzy: Nice finding! I guess something you could try, if the force POST is indeed successful, would be to dump the content of PDISP: 1) before Nouveau is run, 2) after Nouveau when not forcing POST, 3) after Nouveau and forcing POST, to try to figure out which registers changed, and then check what the blob does for those.
22:06karolherbst: duh... inputs can be made of 64 bit components...
22:15karolherbst: and outputs
22:33pmoreau: (Yes, finally succeeded at patching my broadcom driver to compile on top of 4.15: I finally have WiFi working again!)
22:38karolherbst: pmoreau: nice
22:39karolherbst: pmoreau: are the out of tree drivers still as crapy?
22:39karolherbst: the in tree I meant
22:39pmoreau: The OSS ones do not support my chipset IIRC
22:40karolherbst: I see
22:40pmoreau: karolherbst: I pushed the fixes for loops to my branch; the second fix for the out-of-SSA pass is enough to pass my “loop_with_if” test (as well as the CTS “loop” test) but fails for the CTS “local_arg_def” one.
22:41pmoreau: Working on an improved version of the fix.
22:41karolherbst: well, you can't have everything with one patch
22:42pmoreau: It’s more like I made some assumptions with the first one, to have an easy fix, and of course that CTS test broke those assumptions :-D So I have to do a proper fix now
22:43karolherbst: well I had this situation a few times the last weeks :)
22:44pmoreau: Eh eh ;-)
22:44karolherbst: I am slowly hitting NIR bugs...
22:45karolherbst: or rather galliums nir bugs
22:45karolherbst: or wahtever
22:45pmoreau: .* bugs
22:46karolherbst: well, I am quite sure they are not my bugs directly, because I hit assert in code before even calling codegen :)
22:48karolherbst: maybe I use the wrong nir options or whatever
22:49pmoreau: Maybe, cause I would assume that Intel passes all those CTS tests, with the NIR frontend. Or do they still have a TGSI frontend?
22:50karolherbst: intel doesn't use gallium
22:51karolherbst: well gallium has it's own mesa to nir function
22:51karolherbst: and I could imagine that the gallium thing has a few bugs
22:51karolherbst: because there is no real user with high OpenGL feature requiernments and the AMD one isn't complete either
22:51karolherbst: the first bugs I encounter were in glsl-4.20 tests
22:52karolherbst: and tesselation shaders aren't working either, but this is a assert in gallium
22:52pmoreau: On a side note, I recently started a small project which uses OpenGL, and went for OpenGL 4.6, SPIR-V shaders, and all the new “bindless” API from 4.5.
22:53karolherbst: but is bindless even 4.5?
22:54karolherbst: or did you just mean bindless in general
22:55karolherbst: robclark: did you run the firstname.lastname@example.org@execution@vs_in piglit tests on freedreno at some point? I hit weird nir asserts with those
23:04pmoreau: karolherbst: I meant bindless in general, not bindless textures specifically. For example, glProgramUniform (http://docs.gl/gl4/glProgramUniform) & others
23:09feaneron: on Prime systems, is it correct/expected that the nouveau driver always spews a "Pointer to TMDS table invalid"?
23:10feaneron: the nvidia kepler GPU works just fine when something runs with DRI_PRIME=1 later on
23:12feaneron: hm, maybe that message is being fired because Kepler cards either don't have TMDS tables, or nouveau does not support them