00:32 rhyskidd: karolherbst, imirkin: i presume our falcon fuc5 disassembler has known missing opcodes for Maxwell or Pascal?
00:33 rhyskidd: trying to ascertain if the miss rate on a piece of binary blob is expected, or if i miss set some of the envydis tunables
00:40 imirkin: unexpected
00:40 imirkin: how are you running envydis?
02:05 rhyskidd: dumped the fuc from vbios. ran $ ./envydis/envydis -m falcon -V fuc5 < ../ucode-bootloader.txt
02:07 rhyskidd: based off this series plus a local patch: https://github.com/envytools/envytools/compare/master...Echelon9:feature/BIT-p-pmu-falcon-data
02:09 rhyskidd: there is an IMEM (bootloader), IMEM (sec ucode) and the data in DMEM
02:14 rhyskidd: i would *expect* the Falcon ISA has moved on a bit for the latest families
02:44 rhyskidd: first unknown opcode is:
02:44 rhyskidd: e8 f4 0f 32 ??? $r4 $r15 0x320f [unknown: 08 00 00 00] [unknown instruction]
02:45 rhyskidd: e8 appears to sit between two fuc4 opcodes, "extr" and "ins"
03:16 rhyskidd: mwk: Looks like you may have discussed with Switchbrew crew the fuc ISA "f5" instruction. See bottom of http://switchbrew.org/index.php?title=TSEC
03:17 rhyskidd: i'm also seeing it on a Pascal. any tips to RE the instruction. see if it really is crypto related?
03:26 annadane: hmm i wonder which packages in debian actually correspond to the nouveau graphics
03:33 gnarface: just the one xorg package, plus the kernel and all the mesa packages
03:46 annadane: yeah i don't have mesa
03:46 annadane: but yeah xorg + kernel makes sense
03:46 gnarface: you'd only need mesa if you're using opengl
03:47 annadane: xserver-xorg-video-nouveau/unstable,now 1:1.0.15-2 amd64 [installed,automatic]
03:47 gnarface: (which might be more likely than you'd expect, these days, with it being the default for firefox rendering and compositing in several desktop environments)
03:57 imirkin: rhyskidd: note that iirc you might have data in the middle of that stream. also, i think mwk had a way to get falcon processor to execute one op at a time
03:58 rhyskidd: hrmm, so might not all be a contiguous block of code
03:58 rhyskidd: ok
03:58 imirkin: right, you have to RTFS to work it out.
03:58 imirkin: can you pastebin the larger block?
04:04 rhyskidd: here's the patch: https://paste.fedoraproject.org/paste/MeIvIyzFgtHpImG2gbxVAA
04:04 imirkin: i meant the decoded thing
04:04 rhyskidd: and here's the IMEM bootloader: https://paste.fedoraproject.org/paste/OST0iyTdTyE8tC4QXe6-gQ
04:06 imirkin: what about the decoded thing? (i'm quite lazy)
04:08 rhyskidd: decoded https://paste.fedoraproject.org/paste/pgW3NV9ZDpDCD4ysgYRJWw
04:10 imirkin: hm yeah, that's definitely an unknown op
04:11 imirkin: that said i dunno if the whole thing makes sense in the first place
04:11 imirkin: 00000000: d0 59 66 58 c3 mov $r0 0xc3586659
04:11 imirkin: 00000005: f6 c5 10 iowr I[$r12+0x40] $r5
04:11 imirkin: r12/r5 are undefined...
04:12 imirkin: so i think it's just bogus.
04:12 rhyskidd: maybe an as yet unknown header / checksum bytes up top
04:13 imirkin: yeah, let me poke around a bit
04:14 rhyskidd: here's the start of decoded IMEM "sec": https://paste.fedoraproject.org/paste/l~LZZWCAYKMARCavxnt7Dg
04:14 rhyskidd: which is after the bootloader
04:14 imirkin: yeah, again, seems quesitonable
04:19 rhyskidd: ok
04:22 imirkin:wonders what the initial state is
04:22 imirkin: what makes you think this is code?
04:39 rhyskidd: contextually, because it's parsed like so in another implementation: https://paste.fedoraproject.org/paste/-zxt1kDu0icK7VxAoI2eTw
04:41 rhyskidd: so am dumping contents of ucode->bootloader and ucode->ucode and ucode->dmem (each for their respective size)
04:41 rhyskidd: dmem is most likely data
11:39 pmoreau: Was anyone thinking of replying to Anusha on the ML, about GSoC? karolherbst, mupuf?
11:40 pmoreau: I was thinking of doing a small reply, but I won’t be able to do any mentoring.
11:41 karolherbst: hum.. I thought somebody talked about this...
11:56 pmoreau: karolherbst: There was another person interested in GSoC that came by here and talked with imirkin, but it was not about working on Vulkan IIRC, so I think it was a different person.
11:59 karolherbst: ahh
12:00 karolherbst: might be, yes
12:39 mupuf: karolherbst: please answer to the student, I would not mentor that
12:40 mupuf: if you can't mentor, then let's get the project out
12:44 karolherbst: mupuf: I think I would be able to mentor it, just a matter of how big we set the scope here though
12:46 mupuf: karolherbst: then go discuss with him ;)
12:49 karolherbst: yeah
14:02 vliaskov: hi, I use 2 nouveau cards (based on nv108 & nv117, one monitor on each card) with gnome-shell. mesa-dri-nouveau segfaults often. Is this 2-gpu 2-monitor setup expected to work? Details here: https://pastebin.com/zzpAPhhF
14:03 vliaskov: using 1 card and 2 monitors seems to work
14:04 imirkin: nouveau_scratch_data dying ... that shouldn't happen.
14:04 imirkin: i wonder if we're allowing a leak somehow
14:04 imirkin: anyways, i doubt that's in any way related to having 2 gpu's vs 1
14:04 imirkin: i dunno what the situation on wayland is, but on X this should work moderately fine
14:05 vliaskov: thanks. i can file a bug at https://bugs.freedesktop.org/ then
14:06 imirkin: sure. if you want me to look into it though, it'll be important that i'm able to reproduce
14:07 imirkin: (and i have zero interest in installing gnome or kde or whatever)
14:10 vliaskov: ok understood. I 'll see if i can have a minimal test that crashes.
14:16 vliaskov: i assume the buffer objects can be tracked back to their gpu. The gpus are different as mentioned, maybe that's a wrinkle? Are there multi-gpu tests for nouveau (e.g. in piglit)?
14:54 imirkin_: only one gpu does rendering in such scenarios
18:31 disdi: @karolherbst:
18:35 disdi: @karolherbst hi
18:36 disdi: this is regarding Nouveau Vulkan driver GSOC project
18:36 disdi: I would like some guidance as to how to get started with this task
18:36 disdi: also wanted to know about what all hardware we would be targetting
18:36 disdi: maxwell, pascal ot volta chips
18:36 disdi: ?
18:38 annadane: i'm not sure some people get highlighted with @ with their irc clients
18:38 annadane: you're probably better off just using just their name
18:38 disdi: annadane ohh thanks... I hope this way it works
18:38 pmoreau: disdi: Welcome here :-)
18:39 annadane: karolherbst, ^
18:39 karolherbst: yeah, I am thinking
18:39 karolherbst: disdi: hardware wise I would start with fermi+
18:39 annadane:pokes karolherbst with a stick until they answer
18:39 annadane: :)
18:39 disdi: pmoreau hi... thanks for the welcome :)
18:40 karolherbst: disdi: I think, how I would go with it is to try to get basic vulkan examples working for now, allthough basics also means like rather big examples
18:40 karolherbst: mhh
18:40 karolherbst: disdi: any experience with C programming?
18:40 disdi: karolherbst yes C programming with linux device drivers
18:41 pmoreau: disdi: I was wondering whether you had any experiences with Vulkan already (and/or other graphics APIs)
18:41 pmoreau: karolherbst: Planning to write it in C over C++? :-)
18:42 karolherbst: wait
18:42 karolherbst: I have a first task
18:42 karolherbst: extracting the compiler bits
18:42 karolherbst: right
18:42 disdi: pmoreau I have experience with OpenGL and Vulkan is new .... so I have some basic understanding
18:43 disdi: karolherbst little more explanation would help on "extracting compiler bits"
18:43 karolherbst: disdi: src/gallium/drivers/nouveau/codegen/ -> src/nouveau/codegen
18:43 karolherbst: the compiler should be free of any bits from src/gallium
18:43 karolherbst: basically moving code and making sure it still compiles
18:43 pmoreau: disdi: Okay, good :-)
18:43 karolherbst: pmoreau: I let people convince me what is better :p
18:44 pmoreau: src/nouveau/codegen or src/compiler/nvir? Or are you planning to move everything from codegen to that new location?
18:44 karolherbst: disdi: first step might be to add separate build targets
18:44 disdi: karolherbst I have some experince with mesa but on intel platform
18:45 karolherbst: called libcodegen maybe
18:45 karolherbst: and remove the dep to libgallium, etc
18:45 karolherbst: disdi: ahh, this should come in handy
18:45 karolherbst: disdi: so you already have patches upstream?
18:46 pmoreau: karolherbst: And I would personally go with C++, but I am fine with C as well.
18:46 karolherbst: pmoreau: I think we basically have to implement an internal vulkan driver API, no?
18:46 karolherbst: I don't know how much of the vulkan runtime actually does
18:46 karolherbst: *-of
18:46 karolherbst: I assume nothing at all
18:46 karolherbst: but mhh
18:47 disdi: karolherbst : I was part of the team which was developing mesa drivers but it was propriotory
18:47 karolherbst: ahhh
18:47 disdi: dont know if they plan to opensource it in future
18:47 pmoreau: clover implements OpenCL while still using C++ for the implementation ;-) Though you might want to do some things differently from clover.
18:47 karolherbst: interesting though
18:48 karolherbst: pmoreau: yeah :D for sure
18:49 disdi: pmoreau clover is specific to intel how much would remain same for something on nvidia platform if the same activity is taken
18:50 disdi: I mean is there an abstraction layer or we are too much tied to hardware/platform
18:50 pmoreau: disdi: clover is not specific to Intel, they don’t even use it. :-) Only radeon and radeonsi use clover currently (with ongoing work for Nouveau)
18:50 pmoreau: *Nouveau and freedreno
18:50 disdi: pmoreau ok my bad
18:50 archer1010: Hey. X freezes after using mpv for a while, and it happens when you go out of fullscreen. Audio still plays, but you can't do anything in X. I have to kill the X session and restart it for it to work again. Any ideas? Running Arch and Nouveau. Asked in #mpv first, was told it was probably due to nouveau rather than mpv
18:51 karolherbst: disdi: mhh, okay, I was asking because the reqs from Xorg are that you have to show us you are able to work in an open community
18:51 disdi: karolherbst: so I should get started on this cleanup task
18:51 karolherbst: and this means having a patch merged
18:52 disdi: karolherbst: mesa contributions would get counted ,,,so if I get this cleanup patch ready
18:52 karolherbst: yeah
18:52 karolherbst: I think
18:52 disdi: I should be eligible
18:52 karolherbst: for the first patch we do something smaller though
18:52 disdi: karolherbst: great
18:52 karolherbst: just add the build system target libcodegen
18:52 pmoreau: archer1010: Hello. Do you happen to have a Xorg.0.log and the output of dmesg you could link us to please?
18:52 imirkin_: archer1010: that's right. my recommendation is to use mplayer.
18:52 karolherbst: in automake and meson
18:52 karolherbst: just the target alone is fine
18:52 karolherbst: codegen/* -> libcodegen or libnouveau_codegen or whatever
18:52 disdi: karolherbst: thanks :)
18:52 karolherbst: anything else stays where it is
18:53 disdi: karolherbst: sure
18:53 archer1010: pmoreau: Not right now but I can get it in a bit if necessary
18:53 archer1010: imirkin_: For what reason?
18:53 karolherbst: disdi: if you have questions, ask here
18:53 disdi: karolherbst: sure
18:54 disdi: pmoreau: what all I need for vulkan driver
18:54 disdi: like you mentioned C++ is preferred
18:55 disdi: pmoreau: I have only theory knowledge of Vulkan not written any vulkan driver yet
18:55 orbea: archer1010: I was getting similar issues, but they might have gone away when updating to a newer git master build a little while ago
18:55 orbea: I mean a newer mpv
18:55 orbea: unfortunately this also requires a git version of ffmpeg too
18:56 archer1010: orbea: I could try that, thanks. Though this mean it's a problem with mpv and not with nouveau?
18:56 orbea: i think its probably both at this point
18:56 archer1010: Unfortunate :P
18:57 Moiman: archer1010: Do you use fancy scaling filter?
18:57 orbea: to be honest mpv devs seem to code how they think hardware and hardware drivers should work as opposed to how they really work
18:57 archer1010: Moiman: I don't know what that is so I'm assuming no!
18:57 orbea: i've heard bad things from intel users too
18:57 orbea: and amd...
18:58 pmoreau: disdi: I haven’t played much with Vulkan yet, so I don’t really know what you’ll need to do either, (plus Karol is the one going to mentor you, not me).
18:59 disdi: pmoreau: who would be the right person for Vulkan related querries here
18:59 pmoreau: No one has really played with Vulkan I think
19:00 disdi: pmoreau: :(
19:00 pmoreau: disdi: There is some non-upstreamed work you will need at some point, in the kernel for pinning buffers at a specific location (IIRC), and converting SPIR-V -> NVIR (via NIR for example, which Karol has been working on)
19:00 orbea: it's probably faster to buy amd than wait for nouveau to implement vulkan :)
19:01 pmoreau: I want to look more into Vulkan, but I haven’t had the time, and I’m definitely not going to have the time before another month. (plus I have OpenCL to focus on)
19:01 pmoreau: orbea: That’s not how you do a GSoC though :-p
19:01 orbea: heh
19:02 disdi: pmoreau: thanks for the tips
19:02 disdi: karolherbst: I currently have maxwell chip with me
19:03 karolherbst: disdi: should be fine
19:03 disdi: karolherbst: great
19:03 imirkin_: disdi: just fyi, step 1 of any vulkan impl on nouveau would be to add a way to place a bo at a specific VA. this is a kernel change.
19:05 disdi: imirkin_ : hi ....great ....would love to look into this too
19:05 disdi: imirkin_ : I have seen kernel related bo changes in nouveau
19:06 disdi: imirkin_ : generally it is for a new architecture... how is it different for vulkan
19:08 imirkin_: the API ahs to change
19:08 imirkin_: right now you allocate a bo, and are given a VA
19:08 imirkin_: new api is needed to create a bo at a specific VA
19:10 disdi: imirkin_ : so this VA would be different for Vulkan APIs
19:10 disdi: with the newly created bo
19:11 imirkin_: do you know what a "VA" is?
19:11 pmoreau: (I guess VA here is Virtual Address, not Vertex Array.)
19:11 disdi: VA is virtual address
19:11 imirkin_: thanks pmoreau :p
19:11 imirkin_: so have a look at how vulkan allocations work
19:11 imirkin_: first you create an area
19:11 imirkin_: and then you "place" objects into it
19:12 imirkin_: in order for that to work, you have to be able to create a bo at a specific VA
19:12 imirkin_: the current userspace api doesn't allow that.
19:13 disdi: imirkin_ : exactly that is the question I had.... so how is this VA predefined?
19:14 imirkin_: well, it's defined at "area creation time", so to speak
19:14 imirkin_: i forget the exact api calls
19:14 imirkin_: er, vulkan api clals
19:14 karolherbst: I think skeggsb would do the kernel bits here anyway though?
19:15 imirkin_: hehehe
19:15 imirkin_: i've been asking him ever since vulkan came out.
19:15 disdi: imirkin_ : I can take that up....with a little help
19:15 karolherbst: oh well
19:16 karolherbst: I might be able to help out with certain bits as well
19:16 disdi: karolherbst: great thanks
19:16 imirkin_: i won't be able to help
19:16 karolherbst: imirkin_: we want to have vulkan anyway, so...
19:18 disdi: karolherbst: I would get started with cleanup task and exploring about kernel changes needed for vulkan as imirkin_ explained
19:19 karolherbst: yeah, whatever works for you. The goal here isn't to have a fully working vulkan driver anyway. Just enough code to get started implementing stuff would be awesome already.
19:21 disdi: karolherbst: sure.
19:21 disdi: thanks everyone for thier inputs
20:46 mardekas: the list of people is large/big on #nouveau , logged on to this channel, i bet cause of the missing humanity and keen to utterly deal with wrong things, the stack is somewhat unstable still, even if the more omplex parts were given and handled years ago
20:56 mardekas: as a result i no longer even remember what fixes i tried to do for nouveau, i did some multithreading research which did not look entirely scary, anyhow i still hope you follow some internets material and manage to fix the stack at some point, imo it's quite possible
21:03 mardekas: as a final sentence i have thought those poor comments towards (person who only tried to help) not only some memory issues of me manifesting as dropouts, feels like the aging kicks in with a multiplier inbetween, generally not a good feeling to have, looks like not even in position to help anymore
21:03 mardekas: bye
21:23 pendingchaos: Is valgrind-mmt known to work with the 390.25 nvidia driver and Fedora 27 with a GP106? I seem to be getting an empty trace
21:27 imirkin_: don't think so
21:27 imirkin_: i haven't used any of the tracing stuff in such a long time =/
21:28 imirkin_: what are you trying to track down?
21:33 pendingchaos: i'm currently just figuring out how to use it and some related tools
21:34 imirkin_: you might have to pass it a lot of options
21:34 imirkin_: how are you running it?
21:35 pendingchaos: with "valgrind --tool=mmt --mmt-trace-nvidia-ioctls --log-file=nv126_glxgears.mmt glxgears"
21:36 imirkin_: right, i don't think that's enough
21:36 imirkin_: i think you also need ...
21:36 imirkin_: something to point at /dev/nvidia*
21:36 imirkin_: also the specific list of nvidia* has changed over the eons
21:36 imirkin_: right. --mmt-trace-file=/dev/nvidiactl, etc
21:37 imirkin_: or --mmt-trace-all-files :)
21:37 imirkin_: (what could possibly go wrong)
21:37 imirkin_: btw, GP106 is nv136, not nv126
21:37 imirkin_: not that the filename really matters...
21:38 pendingchaos: doesn't --mmt-trace-nvidia-ioctls trace /dev/nvidiactl and /dev/nvidia0
21:38 pendingchaos: also --mmt-trace-all-files seems to not show much
21:38 imirkin_: it might, it might not. iirc i had to pass those in explicitly
21:38 imirkin_: (esp when i've had multiple GPUs :) )
21:39 imirkin_: also i think some additional files may have been added to the mix
21:39 pendingchaos: just a small amount of stuff on ~/.nv/GLCache
21:39 imirkin_: i mean /dev/nvidia*
21:40 imirkin_: can you pastebin the output of 'strace -f -e open glxgears'
21:40 pendingchaos: https://pastebin.com/ZCC9u3VU
21:41 imirkin_: uhhhhhhhhhhh
21:41 imirkin_: rly?
21:41 imirkin_: strace -f -e file glxgears
21:41 imirkin_: (maybe it's something dumb like openat)
21:42 pendingchaos: https://pastebin.com/qW71PBxs
21:42 imirkin_: openat(AT_FDCWD, "/dev/nvidiactl", O_RDWR) = 4
21:42 imirkin_: ha!
21:42 imirkin_: who called it!
22:03 pendingchaos: having mmt treat openat as open and ignoring the first argument seems to fix it though demmt fails with "nvrm.c:259: nvrm_get_pb_pointer_found: Assertion `dev' failed."
22:04 imirkin_: right
22:04 imirkin_: that's ... fixable
22:05 imirkin_: let's see if i remember how
22:05 imirkin_: oh wait. no. that's not fixable :)
22:05 imirkin_: you may need to run with -m nv136 or something
22:06 imirkin_: i think the chipset detection broke on nvrm
22:10 pendingchaos: adding "-m nv136" does not seem to fix it (I also changed the trace filename to start with nv136_)
22:12 imirkin_: yeah, my guess is that the ioctl's diverged too much
22:12 imirkin_: and this all needs to be re-re'd
22:16 pmoreau: imirkin_: We looked into the chipset detection some time ago. The structure passed in needed to have an additional field, or something like that.
22:17 pmoreau: You had a fix that worked on the Maxwell Titan (or maybe it was the Pascal one?), but I don’t know if it was upstreamed or not.
22:20 imirkin_: pmoreau: for chipset detection the ioctl is slightly different
22:20 imirkin_: the change has to go into mmt itself
22:23 pmoreau: Right, like “01:54 imirkin: dboyan: yeah, so... need to send it an extra uint in nvrm_mthd.h::nvrm_mthd_subdevice_get_chipset” https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2017-03-13
22:24 imirkin_: i have so little recollection of this... from a year ago. sigh.
22:24 imirkin_: (in a week...)
22:24 pmoreau: Starting at 21:44: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2017-03-12
22:24 pmoreau: That is when we “debugged” it.
22:25 imirkin_: and polygon offset still fails, doesn't it :)
22:25 pmoreau: It seemed way older than a year ago to me, but apparently not :-D
22:25 pmoreau: Maybe?
22:25 imirkin_: some day i'll get a GM200+ board and get HDMI 2.0 going and a few other things.
22:26 pmoreau: I haven’t tried in a while
22:26 pmoreau: Was that on Maxwell for the polygon thing?
22:27 pmoreau: Looks like it: I still have a file named gm206_polygon_offset.demmt file on my piglit folder. :-D
22:28 imirkin_: gm200+ for some reason it fails
22:28 imirkin_: https://trello.com/c/Pf84d8a2/147-gm200-polygon-offset-fails
22:28 pmoreau: Negative clamp is still failing on my GM206 with 17.3.6
22:30 imirkin_: no changes in that area
22:40 pendingchaos: Should I open a pull request for github.com/envytools/valgrind with https://pastebin.com/j2PSC2zZ? I'm not sure if it's too hackish or not
22:40 pendingchaos: *https://pastebin.com/j2PSC2zZ
22:59 imirkin_: seems reasonable, assuming that real info isn't lost
23:07 pendingchaos: I think the argument being ignored is just used for resolving the filename and I don't think it is relevant whether open or openat is being used
23:07 pendingchaos: so I think it's fine
23:08 imirkin_: go ahead. in theory joi "owns" that code, but he hasn't touched it in a while (and doesn't seem to be here atm... not sure when i spoke to him last)
23:08 imirkin_: oh wait, no, he's here. mslusarz --^
23:39 imirkin_: pendingchaos: are you trying to do anything in particular btw? (most people don't randomly play with valgrind-mmt...)
23:53 pendingchaos: I'm interested in contributing to nouveau/mesa
23:54 imirkin_: very cool
23:54 imirkin_: anything in particular, or just a general desire?
23:59 pendingchaos: probably starting off with the conservative rasterization card (assuming no one is already working on it): https://trello.com/c/Zjm7vs5h/149-gm200-nvconservativeraster