16:01 Antoine-: Hello, I have a thinkpad W530 with an nvidia k2000m and I use nouveau on kubuntu 20.04. I use Blender and I can't see my graphic card in the CUDA settings. Would you know why?
16:16 kwizart: Antoine-, there is no CUDA support with nouveau, eventually opencl at some point, but still WIP
20:38 Lyude: ugh, I could spend the rest of my life staring at drivers/gpu/drm/nouveau/include/nvif/push.h and still not understand what these macro parameters actually do
20:39 Lyude: #define PUSH_1(X,f,ds,n,c,o,p,s,mA,dA) do { \
20:39 Lyude:sighs
20:39 karolherbst: :D
20:39 karolherbst: Lyude: what's wrong with that? :p
20:40 Lyude: karolherbst: what do any of those parameters mean
20:40 Lyude: you're welcome to look at the full definition
20:40 Lyude: i could only figure out a few
20:40 karolherbst: yeah.. I know :p
20:40 Lyude: karolherbst: well, there's the problem :S
20:40 Lyude: i'm trying to figure out how to convert these over to be used in igt-gpu-tools and that's pretty hard when I can't figure out how the heck these even work
20:41 karolherbst: Lyude: mhh, those are pretty magic like and just wrap around more macro magic in order to be able to use nvidia headers
20:41 Lyude: karolherbst: yeah, which is exactly what I need for igt :P, but we can't just copy/paste the macros by hand because not all of those are magic nvidia stuf
20:42 karolherbst: btw
20:42 Lyude: like, the PUSH* need to be modified to use libdrm in order to use them
20:42 karolherbst: p = pointer
20:42 karolherbst: m = method
20:42 karolherbst: d = data
20:43 karolherbst: s is size
20:43 karolherbst: o is PUSH_##o
20:43 karolherbst: uhm.. meaning operation
20:43 karolherbst: c is class
20:44 jcline:mumbles about writing such things down in a permanent way
20:44 Lyude: jcline: yes.
20:44 karolherbst: mhh n is weird
20:44 Lyude: see
20:44 karolherbst: as it gets added to c
20:44 Lyude: _see_
20:44 Lyude:waves hands in air
20:44 karolherbst: seems to be 0 always
20:45 karolherbst: I guess there are reasons to overwrite it
20:45 Lyude: jcline: i will certainly write some patches up for documenting this with kdocs this when we figure this out
20:45 karolherbst: but yeah
20:45 karolherbst: I don't like that stuff either :p
20:46 jcline: Lyude, sounds good :) - I'm about to send out a RFCv2 for the kernel doc page
20:46 karolherbst: I think we should bring nouveau away from the bus factor of 1 :p
20:46 Lyude: karolherbst: feel free to cc me
20:46 Lyude: karolherbst: pardon?
20:46 Lyude: oh oops, *jcline feel free to cc me
20:46 karolherbst: you don't know what the bus factor is?
20:46 Lyude: nope
20:46 karolherbst: "The "bus factor" is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel."
20:46 karolherbst: e.g. if they are hit by a bus or something
20:46 Lyude: god. ok. yes. that is a problem i'm getting a bit sick of
20:47 jcline: I prefer to think of it as lottery factor since I'd much rather win a lottery than get hit by a bus
20:47 karolherbst: bus factor is a well known term :p
20:47 karolherbst: https://en.wikipedia.org/wiki/Bus_factor
20:47 Lyude: karolherbst: with how I learned the skills I use today it's not terribly surprising I haven't heard it before
20:47 karolherbst: :D
20:47 jcline: Yeah, just internally. It's much nicer to think "I'll write some docs so that when I win the lottery tomorrow no one will mind"
20:48 karolherbst: heh :D
20:48 karolherbst:would continue working on nouveau/mesa even if he would win the lottery
20:49 Lyude: karolherbst: also there's no d, did you mean ds?
20:49 karolherbst: Lyude: yes, but s is an index
20:50 karolherbst: like it seems you can supply multiple m/d pairs
20:50 karolherbst: check PUSH_2 etc...
20:58 Lyude: then what does ds stand for
20:59 karolherbst: data
20:59 karolherbst: ohh
20:59 karolherbst: the first one
20:59 karolherbst: heh
20:59 karolherbst: let's see
20:59 Lyude: normally i don't have this much trouble reading macros but these are just wild
21:02 karolherbst: ufff
21:02 Lyude: jcline: you didn't happen to document any of these pushbuffer macros when you were writing docs did you?
21:02 jcline: Lyude, I did not :(
21:03 karolherbst: ehhh
21:03 jcline: I decided to start with the CRC stuff since I explored that quite a bit
21:03 karolherbst: that can't possible work...
21:04 karolherbst: ohh wait...
21:04 karolherbst: soo
21:04 karolherbst: -> method_name f
21:04 karolherbst: and f is ds
21:04 karolherbst: and it gets a %08x prefix...
21:04 karolherbst: mhhh
21:05 karolherbst: this is just annoying
21:05 Lyude: yeah
21:05 karolherbst: can we tell Ben to just write it in readable? :D
21:05 Lyude: that's basically where i've been most of today :)
21:05 Lyude: karolherbst: where is he anyway?
21:05 karolherbst: no clue
21:06 karolherbst: but it's not hard to write macros yourself
21:06 karolherbst: I at least understood the ones Ben added to mesa
21:06 Lyude: yeah, i was originally going to use those but I'd rather just start on nvidia's headers
21:07 karolherbst: the macros are mostly there to deal with the magic enums and stuff
21:07 Lyude: karolherbst: yeah-that's the big thing I want :)
21:07 karolherbst: and I guess also if you have the same names across archs but different offsets
21:07 karolherbst: and then you can do some magic
21:17 Lyude: honestly almost tempted to just work on something else for now
21:21 jcline: alright, I've sent out a v2 for the kernel docs
21:22 jcline: karolherbst, was there anything you needed from me for https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/13?
21:22 karolherbst: I granted you commit access to the repo :p
21:23 Lyude: jcline: thanks for all your work on all of this so far btw
21:23 karolherbst: ehh..I need to ping daniels again for the migration :p
21:23 jcline: I did see that, but usually I like to see an explicit approval from someone else before I merge my own work
21:23 karolherbst: I did approve of the MR, no?
21:24 karolherbst: mhh, but I guess that's not really as visible on gitlab
21:24 karolherbst: maybe I should also just have an avatar :D
21:24 karolherbst: wait.. I have a nice one
21:24 jcline: Lyude, I'm happy to contribute :)
21:25 jcline: karolherbst, ah you're right
21:25 karolherbst: ehhh
21:25 karolherbst: I think the gitlab image picker is broken :D
21:28 karolherbst: ehh
21:28 karolherbst: is the image picker broken for everybody or just me?
21:29 karolherbst: ahhh
21:29 karolherbst: it's the dark mode which is broken
21:29 karolherbst: how could they!
21:30 karolherbst: done
21:30 jcline: I spent like 5 minutes looking around for the merge button before I realized it was hidden behind the "rebase" button
21:31 karolherbst: mhhh
21:31 karolherbst: the avatar besides the approval stuff is really small
21:31 jcline: On all the old fedora projects I worked on we used this bot that auto-rebased and merged on CI success when the review criteria was met
21:32 karolherbst: we more or less have something similiar for mesa
21:32 karolherbst: but that's not really worth the effort when you can just rebase and say "merge when CI is done"
21:32 jcline: So I'm really used to assuming an open request is one that needs some attention
21:32 Lyude: (as it should be)
21:34 jcline: Okay, I've got to go cook dinner, have a good one folks!
21:34 karolherbst: jcline: well.. we could add some bots to the wiki project
21:34 karolherbst: I just have no idea where to run them :p
21:34 karolherbst: and what to use
22:05 rowbee: https://i.imgur.com/hXvPFIB.png i don't think this was supposed to happen...
22:05 rowbee: cookie clicker uses canvas to render which probably uses 2d acceleration
22:07 rowbee: resizing the page fixed it but i wonder what the heck caused that
22:07 rowbee: can't reproduce
22:14 Lyude: i like how nvidia documented various classes like dma-copy, but neglected to document how to initialize any of them
22:17 karolherbst: well :p
22:18 karolherbst: you just allocate them, duh :p
22:18 karolherbst: or not at all
22:18 karolherbst: on newer hardware those are just there
22:19 karolherbst: there isn't really anything specific you need to do. Except you mean like high level init stuff in order to use other methods and stuff
22:20 karolherbst: but that requires a proper documentation of those things anyway
22:20 Lyude: karolherbst: all of the references to using these engines implies you allocate the channel, then fire off a small sequence to init it, and then you have the channel. which is fine, it's just, i was hoping to find some nvidia header that documents the register being written here so I could use that instead of hardcoding it
22:20 Lyude: erm, not register
22:20 Lyude: method
22:20 Lyude: if I say register assume I meant to say method
22:21 karolherbst: it's the same for mesa, no?
22:21 karolherbst: but yeah..
22:22 karolherbst: I guess getting the channel stuff itself documented would be nice
22:22 karolherbst: the main channel you get on a context is there for all the subchannel operations
22:22 karolherbst: and you essentially bind stuff with NV01_SUBCHAN_OBJECT
22:23 Lyude: oh ok
22:23 Lyude: i found the register in their docs!
22:23 karolherbst: I think Ben even told me that the subchan -> class mapping is fixed
22:23 karolherbst: not sure if that's true for priviliged channgels
22:23 karolherbst: *channels
22:23 karolherbst: or how any of that works outside of the context of userspace :p
22:24 karolherbst: Lyude: where is it btw?
22:24 Lyude: karolherbst: yeah mesa is the same but I mean, skeggsb isn't really planning on writing stuff like that in the future and instead is going to be using the nvidia headers for vulkan and other stuff, so I figure it'd be less confusing if we just follow suite in mesa
22:24 Lyude: karolherbst: I _THINK_ it's (in open-gpu-docs) classes/host/cla06f.h
22:24 Lyude: not sure which of those goes to which gpu tbh
22:25 Lyude: but that's the closest to cla05b.h so I'm assuming it's the right one
22:25 karolherbst: mhhh
22:25 Lyude: oh also, sorry, *follow suite in igt
22:26 Lyude: i'm not planning on fixing the mesa code to change it over to nv's register definitions, I don't have time for that right now :)
22:26 karolherbst: mhh
22:26 karolherbst: the parrent is NOUVEAU_FIFO_CHANNEL_CLASS in mesa
22:26 Lyude: that's the nvif object though, you still need to program the subchan method on it through the pushbuffer afterwards if I'm understanding this all correctly
22:27 karolherbst: sure
22:27 karolherbst: but you need something to operate under
22:27 karolherbst: so you create your main channel
22:27 karolherbst: create the client object
22:27 karolherbst: and create your push buffer
22:27 Lyude: karolherbst: already have all of that stuff
22:27 Lyude: i'm really just trying to figure out the right headers to use now :P
22:27 karolherbst: ahh
22:28 Lyude:already has a pretty good idea of how using this thing works
22:28 karolherbst: I don't think we have all which we need for that
22:28 karolherbst: ohh
22:28 karolherbst: dma-copy actually is the copy stuff
22:28 Lyude: karolherbst: actually the open-gpu--yeah
22:29 Lyude: karolherbst: also, I discovered we actually used the fermi one in igt at some point lol
22:29 karolherbst: and you need to use the correct subchan
22:29 Lyude: karolherbst: yep-that's what I'm looking for the registers for now
22:29 karolherbst: so copy goes to subchan 4
22:29 Lyude: (I gave up on the fancy pushbuffer macros, I'll just get skeggsb to explain and document those later)
22:30 karolherbst: Lyude: you specify the subchan in the method header
22:30 karolherbst: so you have 4 as the subchan in the header
22:30 karolherbst: and use the NV01_SUBCHAN_OBJECT to bind it
22:30 karolherbst: wait..
22:30 Lyude: karolherbst: i'm aware :), like I said I'm just trying to find the actual reg files nvidia intended for us to use for this since the method for NV01_subcha-
22:30 karolherbst: I might have some dumps
22:31 karolherbst: ehh mhh
22:31 karolherbst: I don't think this one is documented
22:31 Lyude: basically the method that you call to set the subchan (even though we know it's 0x0, and the data is 0x4) isn't in the dma-copy file
22:31 karolherbst: yeah, because it's common to all subchannels
22:35 Lyude: i think the macro I mentioned before is actually the right one, I'm just not sure which file we should be using since there's no translation between which GPU uses which host class (e.g. something like what's in class/disp/README.txt). just gonna hardcode to 0x0 for now and figure out the header later
22:35 karolherbst: Lyude: I mean... if you want to have those things we can ask Nvidia to publich that
22:35 karolherbst: but I think we mainly focus on interesting bits
22:35 Lyude: karolherbst: i just want to be consistent with the header files and not use our own mthd definitions tbh
22:35 karolherbst: Lyude: the class id encodes the chipset though
22:35 Lyude: karolherbst: oh-I didn't realize that
22:36 karolherbst: yeah
22:36 karolherbst: 0xff00 == chipset
22:36 karolherbst: 0x00ff == class
22:36 karolherbst: 0x90 is tesla? nhh
22:36 karolherbst: or fermi :D
22:36 karolherbst: yeah
22:36 karolherbst: 0x9000 == GF100_DMA_COPY
22:36 karolherbst: 0xc7 is ampere
22:36 Lyude: ok, then I might be able to use this headers then :)
22:36 karolherbst: etc..
22:36 karolherbst: the headers usually tell you
22:37 karolherbst: "#define VOLTA_DMA_COPY_A (0x0000C3B5)"
22:37 Lyude: oh duh, yes they do
22:37 karolherbst: :)
22:37 Lyude: completely skimmed over that
22:37 karolherbst: the chipset ids are the same across all classes
22:37 karolherbst: so 0xc3XX are all Volta classes
22:37 karolherbst: heh
22:38 karolherbst: 0xc6 is ampere_a and 0xc7 is ampere_b
22:38 karolherbst: a is probably A100
22:38 karolherbst: and b is everything else
22:38 karolherbst: we had the same with pascal
22:38 Lyude: anyway-I -think- that should be everything for now :), and then I just can move over to the fancy push macros later
22:39 Lyude: let's see if I can copy some bos today
22:40 karolherbst: :)
22:40 karolherbst: in doubt I can give you a decoded pushbuffer dump from mesa :p
22:40 karolherbst: also, I still have https://github.com/envytools/envytools/pull/203 :D
22:41 Lyude: karolherbst: it actually won't be doing this the same way as mesa since we're just using the CE (from what I could tell mesa never actually uses this, the only two examples I found were the nouveau ddx and the old igt prime test which only like half counts as an example)
22:41 karolherbst: Lyude: I think this file probably explains most of the layout in one file
22:42 karolherbst: yeah...
22:42 karolherbst: I guess CE might go to its own subchan?
22:42 karolherbst: no clue
22:42 Lyude: karolherbst: it does
22:42 karolherbst: I guess it's 5 or something? :D
22:42 karolherbst: no clue really
22:42 Lyude: mthd 0x0 0x4
22:42 Lyude: i mentioned it before :P
22:42 karolherbst: ehh
22:42 karolherbst: so it's the same as we the one we use inside mesa :p
22:43 Lyude: wait i think that is the wrong one
22:43 Lyude: oh hah you're right
22:43 Lyude: except, wait
22:43 karolherbst: which class are you intending to use?
22:43 karolherbst: 0x00b5?
22:43 karolherbst: we already use it in mesa
22:44 karolherbst: just kepler+
22:44 karolherbst: and that goes to subchan 4, yes
22:44 Lyude: karolherbst: dma-copy
22:44 karolherbst: yep
22:44 karolherbst: that one we use in mesa
22:45 Lyude: oh that's why I'm having trouble finding it that's nv30 not nvc0
22:45 karolherbst: nve4+ uses copy :)
22:45 Lyude: ah cool
22:45 karolherbst: anyway, looking at the depushbuf.c file would tell you this as well :P
22:45 karolherbst: I have a nifty table here: https://github.com/envytools/envytools/pull/203/files#diff-5464c2dca31dadf55912db98d5f9e40dR146
22:45 karolherbst: "table"
22:46 karolherbst: so lowest for Copy is 0xa0b5 which is kepler_a :)
22:46 karolherbst: I'd really wish we would have a common place.. like libdrm to have those engine + chipset -> class mappings somewhere
22:47 karolherbst: ahh m2mf/p2mf is subchan 2 :)
22:49 Lyude: i thought imirkin had pointed out that m2mf was different from ce
22:50 karolherbst: yeah, it is
22:50 karolherbst: that's why it's on subchan 2
22:50 karolherbst: not 4
22:51 karolherbst: mhhh
22:51 Lyude: karolherbst: yeah 4 was definitely the one I wanted, finally found the code it's from: M2MF/P2MF is 2, 2D is 3, COPY is 4, NVSW is 5
22:51 karolherbst: Lyude: we actually have m2mf docs
22:51 karolherbst: but not p2mf...
22:52 Lyude: xf86-video-nouveau/src/nvc0_accel.h
22:52 karolherbst: :)
22:52 karolherbst: well
22:52 karolherbst: yeah..
22:52 karolherbst: as I said: I'd like to have that stuff in libdrm do be common for everything :p
22:52 karolherbst: now it's just spread around
22:53 Lyude: yeah, same...
22:53 Lyude: or at least, make libdrm use nvidia's headers and make those canonical
22:53 karolherbst: yeah..
22:54 karolherbst: but we still don't have all we need
22:54 karolherbst: especially the 3d stuff
22:57 Lyude: i don't think I've ever had this many different projects opened in vim at once
22:58 Lyude: (kernel, igt, libdrm, mesa, xf86-video-nouveau)
23:00 RSpliet: Lyude: I know right, it's damn near impossible to close vim. I think it's :q once you're out of edit mode
23:01 Lyude: RSpliet: hah
23:01 RSpliet: that joke is about as old as emacs :-P
23:30 Lyude: karolherbst: am I right in assuming DMA_COPY_A, DMA_COPY_B, etc. are just redundant copy channels?
23:33 karolherbst: no
23:33 karolherbst: B is newer than A
23:33 Lyude: gotcha
23:33 karolherbst: depends on the arch
23:33 karolherbst: but for pascal it's gp100 vs gp102+
23:33 karolherbst: for kepler it B was gk110+
23:34 karolherbst: etc...
23:34 Lyude: https://nouveau.freedesktop.org/wiki/CodeNames/#NVC0 gp100?
23:34 Lyude: or is it just missing from there for some reason
23:34 karolherbst: yeah.. it's not listed
23:34 karolherbst: gp100 is tesla/grid only
23:34 karolherbst: "P100 GPU" is a gp100
23:35 karolherbst: ohh, seems like there is a quadro GP100 as well
23:35 karolherbst: Lyude: I guess no user has those :p
23:35 karolherbst: as you have to pay big bucks
23:36 karolherbst: ahh yeah, the quadro one is like 2 grand or more
23:36 karolherbst: used
23:36 karolherbst: nnew it's like 7 grand :D