01:31 rhyskidd: hrrmmm, okay
02:04 imirkin: anyone happen to have a mmt trace on a recent nvidia blob handy? could be of pretty much anything - want to try to get demmt working again.
02:05 imirkin: i'm also going to try to restore its function on top of nouveau
03:31 imirkin: alrighty... making some progress on the decoding... now i have to figure out how to fit everything together.
03:31 imirkin: LOG: NV_DEVICE_V0_INFO post, version: 0, platform: 3, chipset: c1, revision: a1, family: 7, ram_size: 40000000, ram_user: 40000000, chip: GF108, name: Quadro 600
03:41 imirkin: ugh. the MTHD thing is done on object id's, not handles. and i haven't the faintest clue what the difference is.
03:45 skeggsb: imirkin: handles aren't really used on newer hw outside the display block
03:45 skeggsb: ignore them for determining structure, and use them as informational only
03:45 imirkin: skeggsb: that's of little consolation to trying to modify the demmt code :)
03:46 skeggsb: nouveau's 'object' id is used the same way as rm api's handles, but ours are 64-bit
03:46 imirkin: hm ok
03:46 imirkin: i need to make sure this keeps working with the non-nvif thing
03:49 imirkin: skeggsb: btw, can i just ignore channels? demmt tries to be clever about channels, but i'm thinking of just always using "channel 0"
03:49 imirkin: as far as objects are concerned
03:49 imirkin: or are objects logically members of a channel? (but buffers aren't i presume?)
03:51 skeggsb: if they're children of a channel, yes
03:51 skeggsb: they have no semantics other than the parent/child relationship
03:52 imirkin: what's the point of the parent/child thing?
03:52 skeggsb: userspace doesn't create channels with new interfaces yet, so there's some hacks to join them up to the old interfaces still
03:53 imirkin: by deleting the parent, do the children also go away or something?
03:53 skeggsb: yes, they do
03:53 imirkin: ok, so the idea is that you just nuke the channel and don't worry about other things?
03:53 skeggsb: yeah, you can absolutely do that
03:53 imirkin: ok. and what's all this token business?
03:54 skeggsb: it's an abitrary 64-bit number userspace can pass in, which it'll get back whenever it does an operation on an object. currently used to store pointers etc to additional data related to the object
03:55 skeggsb: not relevant for tracing really
03:55 skeggsb: has no meaning outside of the software using it
03:56 imirkin: but how does it help the software?
03:56 imirkin: or you mean you can store a token into an object
03:56 imirkin: and then retrieve it at some later date?
03:56 skeggsb: yeah, that
03:56 imirkin: ah ok, that makes sense
03:58 imirkin: skeggsb: ok, and how is the parent relationship established in nouveau, with V0_NEW?
03:59 skeggsb: every nvif ioctl is done against an object, which will be the parent when you call new
03:59 skeggsb: (object 0 is the "client" object, and always exists)
03:59 imirkin: i see. so nvif_ioctl->object is the "parent"
04:00 skeggsb: yep
04:00 imirkin: buffer.h:struct gpu_object *gpu_object_add(uint32_t fd, uint32_t cid, uint32_t parent, uint32_t handle, uint32_t class_);
04:01 imirkin: so this should really just dump the cid argument
04:01 imirkin: and make the handle 64-bit
04:01 skeggsb: why does demmt even have a "cid" for decoding nouveau?
04:01 skeggsb: we don't have that concept like nvidia do
04:01 imirkin: well, it's generic
04:02 skeggsb: for us: client == fd
04:02 imirkin: used for nouveau and nvrm
04:02 skeggsb: does demmt ever need to know the HW-side handle too? or just the object id (which is the same as handle for nvidia)
04:03 skeggsb: to be safe: i'd do: u32 cid, u64 parent, u64 object, u32 handle
04:03 skeggsb: for nvidia, object and handle will be the same thing
04:03 imirkin: what would the HW-side handle be used for?
04:03 skeggsb: when the hw wants a handle :P
04:03 skeggsb: ie. old GPUs where you pass it in instead of class id for binding to subchannels
04:03 imirkin: is that the handle you bind on object method 0?
04:03 skeggsb: or ctxdma objects
04:03 skeggsb: yes, that's the one
04:03 imirkin: ok, so it needs that
04:03 imirkin: ugh.
04:04 skeggsb: even on current GPUs, the display block still has the concept
04:04 skeggsb: the rest of the GPU doesn't
04:04 imirkin: (otherwise it won't know what's bound on a subchannel)
04:04 skeggsb: method 0 on gf100 and up take a class id instead btw
04:04 imirkin: right
04:04 skeggsb: it's only earlier gpus where it's an object handle
04:04 imirkin: looked up via RAMHT right?
04:04 skeggsb: yup
04:05 imirkin: our heads are full of totally useless knowledge
04:05 imirkin: yours even more than mine. (although i probably make up for it in other areas)
04:05 skeggsb: i still remember how horribly confusing all this seemed to me when i first started working on nv hw
04:05 skeggsb: just seems normal now after all these years :P
04:05 imirkin: still pretty confusing to me :)
04:05 imirkin: but at least the terms don't seem completely foreign
04:06 skeggsb: this stuff might have been mostly paged out by now if display didn't still work this way
04:06 imirkin: anyways, i do have demmt decoding a nvif-based stream, but it's a hack and getting lucky - i'll have to redo some stuff
04:06 imirkin: does the fifo object get created via nvif now?
04:06 skeggsb: yes, but userspace doesn't do it yet
04:07 skeggsb: it uses the old apis still
04:07 imirkin: k
04:07 imirkin: and old apis == CHANNEL_ALLOC?
04:07 skeggsb: yep
04:07 imirkin: and wtf are those subchan handles in there?
04:08 skeggsb: well..
04:08 skeggsb: that's *mostly* unused now
04:08 skeggsb: but... the kernel needed to touch user channels a lot more than it does now once upon a time
04:08 imirkin: like sticking fences onto the end?
04:08 imirkin: or something nastier?
04:08 imirkin: oh, and relocs...
04:08 skeggsb: that returned to userspace which subchannels and object classes the kernel had bound, and told userspace to try not to fuck it up
04:09 imirkin: oh wow
04:09 skeggsb: only nv4 requires such a thing now
04:09 imirkin: nv4 is basically non-existent...
04:09 imirkin: AGP-only
04:10 imirkin: my only AGP slot is in a G5, and nv4 doesn't have the BE compat stuff :)
04:10 skeggsb: we only touch user channels to emit fences now, and nv10 and up has host (PFIFO) methods that always exist (no matter what object, even none, is bound)
04:10 skeggsb: the kernel only uses those. nv4 we bind a software object class there and emulate the SET_REF method
04:10 skeggsb: when i say nv4, i also include nv5
04:10 skeggsb: but, yes
04:10 imirkin: oh
04:10 imirkin: i have one of those :)
04:11 imirkin: anyways, i'm not going to sweat demmt support for nv4/nv5
04:12 skeggsb: the only reason i can so quickly answer some of these historic questions is i had to re-learn the how/why recently, been working on newer channel/memory apis for userspace to enable vulkan/compute things
04:12 skeggsb: until i ended up in hospital :P
04:14 imirkin: hmmm https://hastebin.com/roqajejira.scala
04:14 imirkin: so the pre's "top" object == 0, but on post, that object has a value set
04:15 imirkin: does it only have significance pre and not post?
04:15 imirkin: (pre-call and post-call)
04:17 skeggsb: um, that's actually a bug, i'll fix it!
04:19 imirkin: so the "post" object id should be valid, but due to a bug, it isn't?
04:20 skeggsb: yes, depending on what exactly one is doing, it can be invalid on post currently
04:20 imirkin: anyways, i gtg sleep; going to try to beat demmt back into shape on nouveau at least
04:20 imirkin: ideally on blob too, but i'll need some traces from someone... i haven't run blob myself in quite a long while
04:20 imirkin: (years, i suspect)
04:21 skeggsb: it's very very broken atm :P
04:51 rhyskidd: imirkin: think that I fixed my bugs in PMU falcon firmware decode support in envytools
04:53 rhyskidd: looking at what appears to be proper dis now: https://paste.fedoraproject.org/paste/r6j~sljHzUzYl6abJydfKg
04:56 rhyskidd: on my card 4x ucode for PMU falcon. A PRE_OS and DEVINIT application_id, then two unique as-yet unknown application_ids
05:23 rhyskidd: at least part of this ucode appears related to "Init-From-ROM" (IFR), the initial PMU ucode loaded from VBIOS when POSTing the card
05:23 rhyskidd: IFR will run until something else is loaded onto the PMU, and does basic fan management on its own: per https://lists.freedesktop.org/archives/nouveau/2017-November/029196.html
05:24 rhyskidd: ^ mupuf
05:50 YTX67Thaxxpop: THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
05:50 YTX67Thaxxpop: THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
05:50 YTX67Thaxxpop: THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
05:50 YTX67Thaxxpop: THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
05:50 YTX67Thaxxpop: THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
05:50 YTX67Thaxxpop: Q-Master^Work Distjubo kbidarka_ theMaze Pri iterati prg318 rperier IdleGandalf ggherdov` perfinion juri_ yaspoon Guest22540 PaulePanter paulk-gagarine peterhoeg NSA towo^work ohama chithead gnustomp enyc udoprog Tom^ glennk specing karlmag FLHerne CME kb9vqf austriancoder Onionnion rashed snkcld SolarAquarion Jonimus Lyude nbtenney SXX glisse Thev00d00 schmidtm musca` Yardanico OhGodAGirl APTX sem2peie alexxy Jaga ccaione yusukesuzuki Armad
07:13 mupuf: rhyskidd: yes, we know that, but we have no control over it and if we replace it with our version, we lose fan management
08:31 pmoreau: skeggsb: Damn! I hope you are doing alright! :-)
11:00 RSpliet: skeggsb: Hope you get better soon man...
12:41 karolherbst: imirkin: what is ISET.BF?
12:45 karolherbst: or maybe I just found an annoying bug inside the gk110 emiter
12:53 rhyskidd: mupuf: thanks. i'll push the envytools code for review now
12:55 rhyskidd: skeggsb: get better soon
12:58 karolherbst: rhyskidd: how does that work out on maxwell2+/
12:58 karolherbst: ?
12:58 karolherbst: or are those signed in that case?
12:58 rhyskidd: well it's been dumping my Pascal ucode fine
12:58 karolherbst: or is there some magic way to control the fan?
12:59 karolherbst: well, I am wondering if they actually are able to control the fans with that
13:00 rhyskidd: have a look at the nouveau ML link i reference above from November 2017
13:00 rhyskidd: aritger from nv indicated the IFR ucode does do basic fan management
13:01 rhyskidd: at the moment both the blob and nouveau replace IFR ucode on the PMU with the full firmware shortly after loading the driver though
13:01 karolherbst: right
13:01 karolherbst: but
13:01 karolherbst: the problem is
13:01 karolherbst: with the means we know, we can't control the fans
13:02 rhyskidd: yup, so at least now we can take a look at the ucode :)
13:02 karolherbst: right, but, that's why I was asking
13:02 karolherbst: maybe it doesn't change the fan speed
13:02 rhyskidd: not the neatly packaged solution, but on the path
13:02 karolherbst: huh?
13:02 karolherbst: it's on the GPU, no?
13:02 rhyskidd: sorry, wasn't clear
13:02 rhyskidd: tl;dr: more work needed in this area
13:02 karolherbst: but that wasn't my point really. If there is a different way on controling the fans we could use, then we could just code it
13:03 karolherbst: and don't need th use that firmware
13:03 rhyskidd: yup
13:03 karolherbst: isn't that firmware actually loaded pre driver gets loaded?
13:04 rhyskidd: yes, during POSTing the card
13:04 karolherbst: mhh
13:04 karolherbst: then I doubt it can control the fan speeds
13:04 karolherbst: or maybe there is a reg to set "default" fan spee
13:04 karolherbst: d
13:04 rhyskidd: yes, at the moment we don't understand just how "basic" the IFR ucode fan management is
13:04 karolherbst: well, would be interesting to look into
13:05 rhyskidd: could be 1%, could be 4%, could be 10% of the flexibility that we'd like
13:05 rhyskidd: not sure yet
13:06 rhyskidd: yes :)
13:06 rhyskidd: that's the next task
13:06 karolherbst: mupuf: do you know anything about this?
13:12 karolherbst: imirkin: .BF is set when we have F32 dest and !float src
13:37 rhyskidd: anyway, gtg now. will be back later on
13:37 pendingchaos: imirkin: here's a bunch of traces I made with the 390.25 driver: https://drive.google.com/file/d/1D7fOcQwxlGpHeejC1H3Ss3ePomZpiqRU/view?usp=sharing
13:37 pendingchaos: (the 390.25 driver does not seem to work with demmt)
13:41 imirkin: karolherbst: not 100% sure that ISET.BF is legal. however it probably is. BF = boolean float.
13:41 karolherbst: imirkin: ahhhh
13:41 imirkin: pendingchaos: thanks!
13:41 imirkin: (boolean float = 0.0 / 1.0)
13:41 karolherbst: yeah
13:41 karolherbst: mesa set that bit
13:41 imirkin: pendingchaos: downloaded
13:41 karolherbst: and the shader works in most cases, just a few where I get wrong results
13:41 karolherbst: it is for a 64 bit div
13:42 karolherbst: and I just noticed that envydis reported unknown bits
13:42 imirkin: yeah, i mean there could be any number of issues. not sure that ISET.BF is it.
13:42 imirkin: also the gk110 envydis thing is sadly not 100% complete
13:42 karolherbst: yeah
13:42 karolherbst: I added the carry in for one set form :)
13:42 karolherbst: another missing bit
13:43 karolherbst: mhh, the TGSI shader doesn't use set.bf
13:43 imirkin: this stuff only comes in with optimizations
13:43 imirkin: does it work if you nuke opts?
13:43 karolherbst: it fails even more....
13:43 imirkin: could be that my thing to determine when i can set BF is wrong
13:44 karolherbst: mhh
13:44 imirkin: basically when i see SET + AND 0x3f800000 i flip it to SET.BF
13:44 karolherbst: we don't end up with set.bf without opts
13:44 karolherbst: so I doubt that this is the issue
13:44 karolherbst: probably some 64 bit handling which is simply wrong
13:44 imirkin: yeah
13:44 imirkin: i could imagine that - i tested it very little
13:44 imirkin: although the most testing it got was on gk110
13:44 imirkin: (well, gk208)
13:45 karolherbst: mhh
13:45 imirkin: diff emitters could be differently messed up too
13:45 imirkin: ;)
13:45 karolherbst: just div fails for int64
13:45 imirkin: enjoy!
13:45 karolherbst: :D
13:45 imirkin: well, div is a monster operation
13:45 karolherbst: yeah, those shaders are brutal
13:45 imirkin: gotta run, see ya
13:45 karolherbst: well it works for TGSI
13:45 karolherbst: yeah, cu
15:32 karolherbst: imirkin: ahhhhh... the issue was a loadImm(getSSA(8), 0) in a 64 bit sub and it ends up doing loading 32 bits into a 64 bit value :(
15:32 karolherbst: I could cry
15:32 karolherbst: :D
15:36 karolherbst: now it works with opt=0, but opt=1 shows other issues, wondering if this is also some silly bug like this
15:55 imirkin_: karolherbst: yeah, that stuff is a bit fiddly
15:57 karolherbst: getting 0x2fffe65e5 vs 0x2511e65e5 in one case...
15:57 karolherbst: I don't really look forward in backtracking the cause of this missvalue :D
15:58 imirkin_: looks like a shift signedness issue
15:58 karolherbst: kind of
15:58 imirkin_: (just a random guess)
16:00 karolherbst: a shader debugger would be a nice thing to have....
16:01 karolherbst: mhhh
16:04 karolherbst: in the other case 0xffffffff0001db3c vs 0xfffffffffe81db3c
16:06 karolherbst: imirkin_: fun thing is, that with this kind of stuff, the nir lowering code could be also simply wrong :(
16:07 karolherbst: allthough on intel it passes
16:07 karolherbst: but so does it on maxwell
16:09 karolherbst: imirkin_: does a "join mov" implicitly jumps to the BB set by the last joinat operation?
16:09 karolherbst: (I guess there is an internal stack even)
16:11 karolherbst: this is the shader by the way, I don't see anything wrong here anymore and it is the same as the maxwell one: https://gist.githubusercontent.com/karolherbst/e4a0b5f2740bceb7e11127270ba6af1c/raw/fd9ebdc2cfd6929e7f1ebd770532280ec87ddeab/gistfile1.txt
16:11 karolherbst: except those join BB:X vs join op things
16:14 karolherbst: uhm
16:15 karolherbst: "shl u32 $r7 s64 $r2 $r7 $r3" this looks wrong
16:15 karolherbst: uhh wait
16:15 karolherbst: $r2 $r3 is the 64 bit value...
16:15 karolherbst: this always confuses me
16:15 mupuf: karolherbst, rhyskidd: No, I never checked what the vbios-provided pdaemon does
16:16 karolherbst: mupuf: mhh. I see
16:16 mupuf: I took Andy's message for it
16:16 mupuf: but I like rhyskidd's message: we should reload the bios-provided pdaemon to guarantee fan management is working
16:17 mupuf: not ideal, but better than the current situation
16:17 karolherbst: mupuf: when should we reload it, after doing secboot?
16:17 mupuf: karolherbst: probably, yes. And after suspend
16:17 karolherbst: makes sense
16:17 mupuf: but after suspend, we need to do secboot anyway
16:17 karolherbst: not really
16:18 karolherbst: we wait until we need a context
16:18 mupuf: right, fair-enough
16:18 karolherbst: which usually happens
16:18 karolherbst: except you drive only a display
16:18 karolherbst: like prime offloaded
16:18 karolherbst: which you could also do in theory on a desktop
16:19 karolherbst: or maybe a graph context is started in that case?
16:19 karolherbst: not quite sure
16:19 karolherbst: anyway, desktop, runs on intel, you have nvidia GPU in it -> no context
16:21 karolherbst: mupuf: or we could just upload ours if there is anything usefull in it
16:24 mupuf: karolherbst: won't happen any time soon
16:24 karolherbst: mupuf: uhhmm with my reclocking patches you actually can enable reclocking on maxwell2
16:25 mupuf: karolherbst: oh, right, fair point!
16:25 mupuf: but maxwell2 is not the problem, pascal is...
16:25 karolherbst: but maybe we could upload the bios one after doing reclocking for fan management :D
16:25 karolherbst: yeah, pascal is more of an issue
16:27 mupuf: karolherbst: haha
16:27 karolherbst: but then again
16:27 karolherbst: if the bios firmware can do fan management, we should be able to do so as well
16:28 karolherbst: mhh
16:28 karolherbst: maybe this could also explain some secboot issues after runtime suspend
16:28 karolherbst: and we actually have to upload those firmwares once
16:28 karolherbst: to get the GPU into whatever state
16:29 mupuf: karolherbst: ?? no, it is signed unlike our
16:43 karolherbst: mupuf: are you sure?
16:43 karolherbst: so they perform secboot through the vbios?
16:44 mupuf: karolherbst: how could it access the fan registers otherwise? :o
16:44 karolherbst: why do you think I talk about a different way of doing stuff?
16:45 karolherbst: mupuf: and if they do secboot there, they also need all the other firmwares, like the bootloader and the secboot HS image and everything
16:45 karolherbst: maybe they don't control the fan anymore there? maybe they have a reg which tells the GPU to do 50% fan speed or whatever
16:45 karolherbst: who knows
16:46 karolherbst: but I think it is unlikely they do a full secboot thing there
16:46 karolherbst: anyway, gtg
16:47 mupuf: karolherbst: why are you talking about secboot? This is only the pmu. the uploading process should not be too hard and is a requirement for secboot
16:47 mupuf: so... not sure we understand each other :D
17:26 imirkin_: karolherbst: i think that's the SHF.L op, which is a 64-bit-ish op. wasn't sure how to represent it ;)
21:47 pmoreau: I am having some issues getting sddm/KDE/bare X server + xterm to show up: I have a GP102 (with two screens attached) and a GM206 (no screens); TTYs display fine on the screen, but starting an X server, nothing displays and the screen go back to sleep. Switching back to TTY and they display the TTY fine.
21:48 pmoreau: dmesg: https://hastebin.com/alufeyitub.go and Xorg.0.log: https://hastebin.com/qefogobahi.scala
21:50 pmoreau: In the Xorg log file, everything seems fine, detecting both cards and retrieving the EDIDs from the two screens, but...
21:50 imirkin_: pmoreau: GM206 is treated as primary screen
21:50 imirkin_: probably because it's configured as such in the bios
21:52 pmoreau: It should be the GP102. Before I wouldn’t even get the TTY displayed, it would only display when connecting the screens to the GM206, until I messed with the BIOS.
21:52 imirkin_: pmoreau: which one is PCI:*(0:3:0:0) 10de:1401:1458:368e ?
21:53 pmoreau: GM206 is the 3:0
21:53 imirkin_: the one with the *
21:53 imirkin_: that's the primary one.
21:53 imirkin_: check the boot_vga thing
21:53 pmoreau: What is that?
21:53 imirkin_: grep . /sys/class/drm/card?/device/boot_vga
21:55 pmoreau: It’s the GM206 which has boot_vga set to 1
21:55 imirkin_: like i said.
21:56 pmoreau: WTH, so I messed enough to get the screens to display the TTY when connected to the GP102, but not enough still? --"
21:57 imirkin_: anyways
21:57 imirkin_: you can force X to use the GP102 as the primary
21:57 imirkin_: just have to add a device section
21:57 imirkin_: with the appropriate BusID
21:57 imirkin_: or whatever it is, i forget precisely
21:59 pmoreau: I’ll continue messing with the BIOS, and try forcing it for X otherwise.
21:59 imirkin_: basically boot_vga indicates which device VGA I/O space writes go to
22:00 imirkin_: and X uses that as a hint of which device to use as primary
22:00 imirkin_: which seems like a pretty reasonable guess
22:00 pmoreau: Makes sense
22:01 imirkin_: i think you can flip it with vga_switcheroo at runtime
22:01 imirkin_: not 100% sure
22:01 imirkin_: maybe you can just echo into that file
22:02 pmoreau: I am not sure how I ended up with having only the boot process and the TTY show up, but not the rest. Whereas before I would get nothing at all to show up on those screens.
22:18 imirkin_: pmoreau: there might be a vgaarb cmdline param you can set too
22:18 imirkin_: https://01.org/linuxgraphics/gfx-docs/drm/gpu/vgaarbiter.html
22:21 pmoreau: Ah thanks, I might try that after testing all possible combinations of primary GPUs in the BIOS
22:24 mupuf: rhyskidd: excellent work with the bit p parsing!
22:25 mupuf: you went overboard in splitting the work, but this was very easy to review
22:25 mupuf: I did not check with the docs from nvidia
22:25 mupuf: ship it!
23:22 pmoreau: I’m giving up on dual-GPUs for now. I’ll re-try flashing the VBIOS tomorrow.
23:28 mupuf: pmoreau: why the vbios? It is the bios you need to flash quite likely