08:29 pmoreau: karolherbst: Got some ROM for you! :-) What’s the strap value again? I know it’s something like 0x1001000
08:29 pmoreau: Sovereign# nvapeek 1001000
08:29 pmoreau: 01001000: RRRRRRRR
08:29 pmoreau: WTH! How can it return 'R's? o.O
08:32 pmoreau: karolherbst: https://phabricator.pmoreau.org/F84100
08:34 pmoreau: gnurou: I hadn’t realise GM20B was missing from the previous versions. Are there other chipsets missing from this one?
08:34 pmoreau: Oh!! PMU firmware! I had missed that part… --"
08:34 gnurou: pmoreau: yeah, this is just the low-secure PMU firmware
08:35 gnurou: I know gm20b is not interesting for most people here, but it is an excuse to slip the basics of the PMU message format
08:35 gnurou: ... that we will hopefully use to do more fancy things like fan control on dGPU... once the corresponding firmware is available, of course :/
08:35 pmoreau:handwaves "This are not the chipsets we want to see firmwares for!" :-p
08:36 pmoreau: *These
08:36 pmoreau: Cool to get the basics at l(e)ast.
08:36 gnurou: again, sorry ; but this code is required for dGPU as well, Tegra at least allows us to release and hopefully merge it ahead of the firmware
08:37 gnurou:hates to use Tegra as an excuse, it deserves more than that >_<
08:38 pmoreau: So, IIRC, v3 and previous version added support for handling PMU firmwares, but were lacking the "loading" part, i.e. the glue in the code to make Nouveau initialise the PMU engine using the signed firmware?
08:38 pmoreau: Which is what is being added in this v4
08:38 Yoshimo: pmoreau: keep in mind that the force only works for the weak minded ;)
08:40 karolherbst: pmoreau: 101000
08:40 pmoreau: Yoshimo: True…
08:40 karolherbst: pmoreau: RRRRRRRR is out of range
08:40 pmoreau: Ah, ok :-D
08:40 pmoreau: The strap is in the comment
08:41 karolherbst: gnurou: meh :p
08:41 gnurou: pmoreau: correct, this patchset is "complete" in the sense that PMU firmware is loaded by ACR and runs (and accepts commands) after secure boot is completed
08:41 karolherbst: gnurou: could we use it on gm20x though?
08:42 gnurou: karolherbst: yes, that's the goal - you need signed PMU firmware though, and the message format may slightly vary
08:42 pmoreau: gnurou: Ok, thanks for the explanation. :-)
08:42 gnurou: karolherbst: of course I will cover the variations as we release said firmware
08:44 pmoreau: gnurou: Speaking of firmwares, any news about gr firmwares for GP102/4/6? IIRC, only GP100 was released.
08:44 gnurou: pmoreau: working on that as well... no ETA, but will come someday
08:44 pmoreau: K
08:44 gnurou: (along with its own acr_rxxx.c, yippee)
08:45 pmoreau: :-D --"
08:45 Yoshimo: gnurou: do you know if maxwell and pascal firmware should come together or are they independent in terms of a date?
08:45 karolherbst: gnurou: I meant the gm20b pmu on the desktop ones
08:46 gnurou: Yoshimo: they are independant, and I have no idea which release order they will follow
08:46 gnurou: karolherbst: ah - gm20b's PMU firmware will be absolutely useless on dGPU. I don't even think it will pass signature verification
08:48 karolherbst: gnurou: I see
08:49 karolherbst: gnurou: hacking up the interface will be fun
08:50 gnurou: karolherbst: you mean the PMU interface?
08:50 karolherbst: gnurou: do you think it might be possible to get the API for the dynamic reclocking things already, before I hack too much on that?
08:50 karolherbst: gnurou: yes
08:52 gnurou: karolherbst: I don't know. What happens on the PMU side is very opaque to me, and the only thing I know is that features will be released veeeery slowly if things follow the current plan
08:52 gnurou: trying to boost it, but this is not under my power :(
08:55 karolherbst: gnurou: well thing is, we plan to adjust our current code to the same interface to make it less painful in the driver
08:55 karolherbst: so documentation about the interface is kind of required
08:56 gnurou: well the basics is the queue thing and the fact that messages are larger than 2 shorts... if we can agree on these basics, things should go smoothly
08:58 karolherbst: mhh messages are larger than 2 shorts already
08:58 karolherbst: or you mean the ids?
08:59 karolherbst: well we can rework everything and actually wanted to write that stuff in C anyway
08:59 karolherbst: mwk: any plans when the llvm thing for fuc will be finished? Or should somebody else finish it, because you want to do something else?
10:19 karolherbst: pmoreau: mind adding it to the repository or should I?
10:19 karolherbst: the vbios
10:28 pmoreau: karolherbst: I don’t have access to the repo at the moment, so please do. :-)
10:34 karolherbst: well I don't have access as well
11:14 karolherbst: gnurou: I guess with your rework it should be possible now to simply reset the pmu and upload our own image?
11:30 karolherbst: okay
11:30 karolherbst: so nvbios is broken for pascal vbios files
11:30 karolherbst: splendid
11:30 karolherbst: have to port the stuff skeggsb done for nouveau
11:33 mupuf: karolherbst: oh, finally got one?
11:59 Yoshimo: i had it crash on maxwell in the early days to
12:36 karolherbst: mupuf: well I hade one before, but I couldn't get it parsed by nvbios
13:51 gnurou: karolherbst: not any more than before I expect, signed ucode is still required
14:15 waltercool: woah, lot of patches today from Alexandre
14:20 Yoshimo: indeed
14:21 karolherbst: gnurou: but now the infrastructure is there to use the pmu after performing secboot, this will help
14:49 gnurou: karolherbst: correct. You just will need to use the firmware NVIDIA provides. Let's hope it comes with enough features to be useful beyond GR falcons reboot... That's what scares me the most.
14:49 vita_cell: hi, I have in desktop nvidia and intel gpu, VGA wired to Intel (mobo), nvidia card doesn't work properly with bumblebee, optirun, primusrun. I generate xorg.conf with "nvidia-xconf", but system won't start (startx and lightdm) after generated /etc/X11/xorg.conf. So I need xorg.conf generated by nvidia-xconf, but system won't start
14:49 vita_cell: has someone any idea?
14:54 imirkin: vita_cell: sounds like you're trying to get support for nvidia's blob driver. this is the wrong place for that.
14:55 waltercool: vita_cell: Nouveu != Nvidia
14:55 waltercool: nouveau*
14:55 waltercool: for nouveau you don't need to use bumblebee "hack"
14:56 vita_cell: ok thanks!
14:57 vita_cell: yeah, nouveau+DRI_PRIME worked fine
14:58 imirkin: vita_cell: you can try #nvidia, although i don't know if anyone's had much success with that, or try their online forums.
14:58 imirkin: i believe those are the only "unpaid" support channels they provide
14:59 imirkin: i'm sure if you bought a few thousand of their high-end tesla gpu's, they'd get you something a little more official.
15:00 vita_cell: imirkin, sorry for trying to get support for blob in wrong place, karolherbst already helped me a lot with Nouveau, thanks anyway
15:00 vita_cell: and I agree with you
15:00 imirkin: no worries - we just don't know that much about blob stuff, and have no great way to debug it.
15:18 karolherbst: imirkin: no idea what you mean, mmiotraces are great :O
15:19 karolherbst: gnurou: reset the PMU to load the nouveau image instead :P
15:19 imirkin: that's for analysis of what the blob does to the hw, not of how to configure their X/etc components
15:20 karolherbst: mmiotraces help with everything
15:20 imirkin: hehehe
16:11 waltercool: Guys, if you need some testing, I can do "tests" with my GM204M (If you want to test something about PMU)
16:13 Yoshimo: last attempts to grab that for maxwell weren't successfull though
16:16 waltercool: do you mean with the previous blobs or the new ones?
16:16 waltercool: I can manually start fans in case of something bad happens
16:16 Yoshimo: there are no PMU blobs for maxwell, neither before today nor now
16:18 waltercool: Oh, this is only for the Tegra?
16:22 karolherbst: yes
16:23 waltercool: I see, because the X1 is the same arch, I hope the "better-than-nothing" blobs would be close to be released also for maxwell
16:25 Yoshimo: i guess it wouldn't be worth the time to try to extract them from what we have karol?
16:27 Lekensteyn: Any known issues with MSI and power management?
16:27 karolherbst: many
16:28 karolherbst: uhh you mean MSI
16:28 Lekensteyn: message signalled interrupts
16:28 Lekensteyn: not the brand (sigh, makes searching more difficult..)
16:28 karolherbst: uhh
16:28 karolherbst: no clue
16:28 karolherbst: maybe
16:30 Lekensteyn: ok, I have compared two traces of pci register read/writes, one where it fails to power on a power resource, one where it works fine. There are few differences, writing to the MSI capability registers is one of them
16:30 karolherbst: well
16:30 karolherbst: I bet there are ton differences
16:31 Lekensteyn: two, not "tons" :P
16:32 Lekensteyn: first half (working, without nouveau, relying on pcie port pm) http://sprunge.us/ehii second half (broken, using nouveau runtime PM) http://sprunge.us/WbBB
16:32 Lekensteyn:rebooting for tests
16:56 karolherbst: Lekensteyn: yo, dropped a crazy comment, duh :p
17:33 orbea: any ideas with this GLES3 blackscreen with glupen64? It appears to be related to EXT_buffer_storage so llvmpipe which doesn't support it doesn't have any issues. I dont have any other mesa drivers that support it to try though. It will crash in apitrace, but here is thet trace anyways. http://ks392457.kimsufi.com/orbea/stuff/trace/libretro/glupen64-gles3-crash2.trace.xz and the issue report:
17:33 orbea: https://github.com/GLupeN64/GLupeN64/issues/107
17:34 imirkin_: orbea: https://github.com/GLupeN64/GLupeN64/issues/88
17:34 imirkin_: should help making a trace
17:35 orbea: yea, its built with DEBUG=1, crashes apitrace either way.
17:35 imirkin_: ah, too bad
17:35 orbea: seems the crash is only gles3
17:36 imirkin_: i'm not surprised ... we have unspecified synchronization issues in vertex processing
17:36 imirkin_: glamor used to hit them, i never figured out what was wrong
17:36 imirkin_: but eventually something in glamor changed and the problem magically went away
17:36 orbea: ah..
17:37 imirkin_: (glamor used unsychronized mappings as i recall)
17:37 orbea: itd be nice to find out if an intel or amd driver with that function also does it or not...
18:02 orbea: something else from Logan that may help provide details I missed... "You should mention that this only happens with GLES3, works with full OpenGL, and it looks like the call to glBufferStorage is being skipped in the apitrace."
18:03 imirkin_: if it's skipped in the apitrace, it's skipped in reality as well
18:03 imirkin_: perhaps he's forgetting to call glBufferStorage in that case
18:04 imirkin_: https://github.com/GLupeN64/GLupeN64/blob/4a6f0637b8883358e866a583005aa596de47cc59/custom/glsm/glsm.c#L904
18:04 imirkin_: that looks problematic
18:04 imirkin_: it should be glBufferStorageEXT
18:05 orbea: let me try that
18:15 orbea: no difference, crashes in apitrace and blackscreens without
18:15 imirkin_: k
18:16 imirkin_: and presumably running with MESA_EXTENSION_OVERRIDE=-GL_EXT_buffer_storage fixes everything?
18:18 orbea: yes, that fixes it entirely, no black screen or crash
18:18 imirkin_: k
18:18 imirkin_: sorry, i don't really have time to look at this
18:18 orbea: thanks anyways :)
18:18 imirkin_: if you send me an email with instructions on how to reproduce, i can give it a shot
18:19 imirkin_: but not right now
18:19 imirkin_: and perhaps not soon
18:19 orbea: sure, I can send it in a bit.
18:36 karolherbst: funny, I thought if I run something qtwebkit based on top of plasma5 with nouveau, it should crash like immediatly
18:36 imirkin_: i think they added a blacklist for nouveau somewhere? not sure
18:36 orbea: the qt jackd frontend froze up xorg for me immediately, maybe it will do that for you too?
18:36 karolherbst: imirkin_: mhh true, but even my chromium works just fine
18:37 karolherbst: wait, there was a way to enable it
18:37 imirkin_: chrome has always worked fine for me...
18:37 karolherbst: is there a qtwebkig based web browser for plasma?
19:01 waltercool: karolherbst: Qupzilla
19:01 waltercool: It crash a lot for me using nouveau at least, but I'm using qtwebengine (similar to qtwebkit, because this one was deprecated)
19:23 karolherbst: imirkin_: can you imagine in which situation glXQueryExtensionsString might not return GLX_EXT_texture_from_pixmap ?
19:25 karolherbst: glxinfo: https://gist.github.com/karolherbst/3b4f4b2a81f46c493594fb9a2cc51adc
19:25 karolherbst: it isn't in the last list
19:26 karolherbst: mhhh
19:26 karolherbst: and with intel it is in all three
19:26 karolherbst: interesting
19:32 imirkin_: karolherbst: yours, apparently
19:34 imirkin_: that's odd though
19:34 imirkin_: if it's in both the client and server lists, it should be in the main list. i thought.
19:36 karolherbst: imirkin_: maybe prime offloading?
19:37 karolherbst: anyway, so it is time to read also mesa source code
21:18 ZeekHuge: ;
21:18 ZeekHuge: cin >> a>> b >>d ;
21:18 ZeekHuge: oops..
21:50 karolherbst: skeggsb: mind helping me with getting those pascal vbios to work in nvbios?
22:06 rektide_: was the PMU stuff blocking for Tegra X1 support? are there other things still blocking?
22:18 rektide_: i'm curious what the road to 3d on X1 looks like
22:23 imirkin_: largely untested, but should mostly work i believe
22:24 imirkin_: afaik no one has one except gnurou, so it's a little academic
22:27 karolherbst: rektide_: I am curious about that myself