00:10imirkin_: there's FE-CS and GPC-CS
00:28Lyude: i think nvidia had a -lot- of trouble getting clockgating on fermi working originally
00:30Lyude: did some rescans through the vbios repos, I've spotted three different different ways they did clockgating programming
00:31Lyude: if I'm guessing correctly; they originally did it by writing everything at once and that didn't work, then they started writing the eng settings followed by enabling the actual cg, then they moved it into a late init at the end of the device init
00:35Lyude: make that 4
00:38imirkin_: command streamer is actually more likely
01:06Lyude: aaaaaaaaand it looks like we might need to factor in current clock speed into the engine delays that we use (@mupuf). I think that's enough fermi research for me today :)
01:41mupuf: kepler does noyt need that IIRC
02:02Lyude: mupuf: fermi does though
02:03Lyude: at the very least it seems like it is only the main gr register
02:03Lyude: erm, s/register/engine/
02:24mupuf: kepler also changed some values, but not all of them
02:24mupuf: karolherbst also saw this happening, but the reasons were a little unclear
02:35Lyude: I wonder if the values are consistent between card vendors
02:37Lyude: and whether they're actually calculated with a formula somewhere or if there's some vbios table to look up all of the values in
02:52Lyude: i am going to need to do a lot of reading through traces next week i suppose
02:54bazzy: pmoreau: friendly ping
02:59mupuf: Lyude: yeah, gonna be a bit annoying. We need better tooling for this sort of things :s
03:00mupuf: would be good to have a real-time tool that shows you what you want to know. Well, I guess nvawatch is somewhat is tool already
03:01mupuf: anyway, bed time. I figured out why my new headphones worked in bluetooth, analog, but not with USB except on windows
03:01mupuf: turns out it advertises support for plenty of sampling rates, but only works at 48 kHz
03:01mupuf: at least, it is an easy fix
03:03Lyude: I was going to suggest tooling yeah; anyway see ya
03:53karolherbst: Lyude: what did I say?
03:53karolherbst: or saw
03:57Lyude: karolherbst: the fact that on fermi with the CG_CTRL register, that the ENG_FILTER and ENG_MANT bits look like they change alongside the clock speed https://paste.fedoraproject.org/paste/DbPbz~yM8hX9Of43tGAJpw
03:57Lyude: this also doesn't appear to be the case with kepler
03:59karolherbst: I mean I didn't look into that in detal
03:59karolherbst: I just knew that nvidia was changing them quite a lot on fermi
04:00karolherbst: afaik it shouldn't have any real functional difference on kepler except for example reducing latencies
04:00karolherbst: Lyude: just set up the lowest latencies for now I guess
04:01karolherbst: or I don't know
04:02karolherbst: or maybe the highest?
04:02karolherbst: Lyude: I guess there is some cost to make the engine work again and it might affect performance if you idle too fast or something, it might reduce perf
04:03Lyude: i'm assuming higher latency
04:04Lyude: highest might mean "prepare more data because this is how long the block will take to respond"
04:06karolherbst: I actually think it is the time it takes until the engine actually goes into "power saving mode"
04:07karolherbst: but I have actually no idea how to properly meassure this, because Nouveau could just be that bad that it doesn't matter at all
12:49pmoreau: bazzy: Pong I started and powered down my laptop, and I indeed do get the sound, as well as a visual effect. I’ll try running the NVIDIA driver to check whether it happens for them or not.
13:56pmoreau: bazzy: I am getting the same sound when running the NVIDIA driver (will do a bit more testing), so it’s possible that in order to get rid of the pop, something else than Nouveau needs to be tweaked.
14:23imirkin: pmoreau: try a pre-4.10 kernel. perhaps atomic modesetting turns something off that wasn't turned off before.
14:27imirkin: this is inconvenient.
14:27imirkin: silly nvidia. weren't you thinking of nv50_ir when you designed the maxwell isa?
14:28imirkin: hakzsam: do you remember if it's just the presence + bitsize that we need for maxwell that isn't available via the TIC?
14:28imirkin: i wonder if those are retrievable via tex queries...
14:29hakzsam: I don't remember to be honest, but yes maybe via tex queries
14:32imirkin: basically ... i was hoping to not have a "side buffer" for bindless
14:33imirkin: i guess nvidia just (sub)allocs a buffer and reads both the handle and that info out of it
14:33imirkin: that allows them to have an infinite number of handles, and not worry about tic locking
14:33imirkin: we may have to switch to that scheme eventually
14:33imirkin: but for now, i feel like being lazy.
14:33imirkin: i.e. until proven otherwise :)
14:35hakzsam: yeah, but if the number of bindless handles is high that should be good enough for now :)
14:35imirkin: i guess i could check the bound image's width. if those are 0, then nothing's there? although that would mean we'd have to clear stuff out of the memory tic table
14:35imirkin: can there be more than 2048 bindless things allocated at once?
14:37hakzsam: probably not
14:37imirkin: so we're safe :)
14:37hakzsam: I guess the nouveau implementation allows bindless handles to be re-used?
14:39imirkin: randomly, maybe
14:39imirkin: not sure what you mean
14:39imirkin: a bindless handle is a persistent tic entry
14:40imirkin: once it's free'd (texture gets deleted), a future texture could get that same tic entry
14:40hakzsam: okay, so we are safe
14:40hakzsam: 2048 handles is high
14:40imirkin: but it's handles, not *resident* handles
14:40imirkin: i.e. the tic entry remains for the lifetime of the texture
14:41imirkin: so one couldn't allocate 1000000000 textures and then make only 20 of them resident at any one time
14:41imirkin: or even 2049
14:41imirkin: (or 2048 really - since non-bindless textures also need tic slots)
14:41hakzsam: I see
16:29imirkin: do we remember what TXQ.TEXTURE_TYPE returns? i assume 1/2/3 for the number of dims?
17:46imirkin: in case someone wants to play with it... bindless for maxwell: https://github.com/imirkin/mesa/commits/bindless
17:46imirkin: note that the first commit affects non-bindless too - so testing appreciated. it would affect regular images, like imageSize() and imageSamples() calls.
18:00vedranm: imirkin: wrt https://bugs.freedesktop.org/show_bug.cgi?id=104609 shouldn't nouveau module have "number of users/processes/modules" in lsmod to be >0 when a vtcon is active, so you can't rmmod in a wrong way?
18:01imirkin: vedranm: yeah, i have no idea how this is allowed to happen
18:01imirkin: vedranm: i also have no interest in worrying about module counts
18:01imirkin: feel free to send patches
18:01imirkin: afaik every drm driver is like this
18:01imirkin: so it's not some super-trivial thing
18:02imirkin: but i could be wrong - haven't looked into it
18:02vedranm: imirkin: actually, rmmod works perfectly on a Hawaii card
18:02imirkin: on a hawaii card that has a vtcon bound to it?
18:03vedranm: imirkin: it's a headless server in both cases, should I check it?
18:03imirkin: it's the vtcon that messes everything up
18:03imirkin: no vtcon, and you're all good
18:04vedranm: imirkin: actually, it does and Hawaii rmmod works nicely
18:04vedranm: rv635 fails in the same way https://bugs.freedesktop.org/show_bug.cgi?id=104608
18:04vedranm: and it's not amdgpu vs radeon, hawaii works well with both
18:04vedranm: (rmmod wise)
18:05imirkin: well - send patches!
18:05imirkin: or follow the provided instructions when rmmod'ing
18:06vedranm: imirkin: :-)
18:06vedranm: when I learn how to do kernel programming I'll find out how Hawaii does it and then do the same for the rest
18:06vedranm: (assuming that's the issue here)
18:06imirkin: well, it has nothing to do with hawaii
18:06imirkin: my guess it's accelerated fbdev vs not
18:07imirkin: and for gcn+ it's not accelerated
18:07imirkin: or ... something
18:07vedranm: hmm, yeah, could be
18:08imirkin: rmmod is a system admin function, so ... be careful.
18:09vedranm: of course
18:09vedranm: I shouldn't expect reboot to work after this, right?
18:09imirkin: as i was planning to answer you... the chances are about as high as that reference count :)
18:10vedranm: hahaha, I see, thx
19:16Processus42: Hello guys. Since I disabled CSM in my BIOS, when the nouveau driver gets loaded, the displays goes to sleep. I have a GTX 980 graphic card.
19:17Processus42: I have two displays. One on the DVI port and one on the HDMI port.
19:18Processus42: I am running gentoo with kernel 4.9.72
19:18Processus42: Note that everything worked properly until I disabled CSM
19:20Processus42: I'm not good with the graphic stack of Linux, thus I'm a bit lost. dmesg shows no suspicious log to me. It's like everything was going fine.
19:21RSpliet: CSM? What's an CSM?
19:21Processus42: On the UEFI from AmericaTrends it's the Legacy mode
19:21Processus42: (For booting from MBR)
19:22Processus42: *American Megatrends
19:22RSpliet: Ah ok.. try booting with nouveau with erm... I think nouveau.config="NvForcePost=1" as a kernel param
19:22RSpliet: Let me double-check
19:23RSpliet: yep, that's the one
19:23Processus42: It's time for me to use a bootlader (I'm still using kernel stub efi :'D )
19:23Processus42: Okay. I'll try this.
19:24RSpliet: If that doesn't work, we'll need kernel logs
19:24Processus42: By the way. Can I just load this module with this param, or do I have to reboot ?
19:25RSpliet: you should be able to load modules with such a param with insmod... not sure about modprobe
19:25RSpliet: insmod doesn't resolve dependencies though, all a bit tedious
19:25Processus42: I know the dependencies of nouveau so it will probably be okay
19:25Processus42: I'll check if modprobe can take config
19:26RSpliet: oh modprobe seems to support parameters by now... don't know why I thought it didn't
19:26RSpliet: I don't think you should prepend the parameter with "nouveau." in that case though...
19:27Processus42: Yep, me neither. I never used its this second argument :)
19:31Processus42: Re. I got nouveau: unknown parameter 'NvForcePost' ignored on the dmesg.
19:31Processus42: (And the displays went to sleep)
19:32Processus42: Oh, wait. Did I have to keep the "config" ?
19:32Processus42: Okay my bad, I had to
19:32Processus42: I'll try again. Sorry.
19:34Processus42: Re. It worked.
19:36Processus42: I'm not good with the graphic stack. I though "vbetool post" would do the same. (I tried to load the module, start vbetool, then bind the framebuffer console. But it hanged on the vbetool step)
19:36Processus42: Maybe that vbetool doesn't works with nvidia card ?
19:39imirkin: not since the GTS 8800
19:39imirkin: i.e. G80 family
19:39imirkin: first released in ... 2006? 2008?
19:40mjg59: Also unlikely to work under CSM
19:40mjg59: Unlikely to work *without* CSM
19:40imirkin: once you kick out the bootloader-made logic, there's no way to get it back
19:40imirkin: these cards are too complicated
19:41imirkin: what's CSM?
19:41imirkin: we should be detecting whether the vbios ran or not, so ForcePost should not be required
19:41imirkin: the vbios is supposed to flip a bit when it runs, and we know not to run it again on fermi+ gpu's
19:41imirkin: (since running it a second time can lead to disaster as well)
19:43mjg59: imirkin: Compatiblity Services Module
19:43mjg59: imirkin: BIOS emulation for UEFI
19:44mjg59: Processus42: If you run vbetool on a UEFI system then it'll almost certainly fail in bizarre ways
19:44Processus42: Thus the ability to run the POST again has been implemented onto the driver itself ?
19:45Processus42: mjg59: Yes, it did. Hopefully I had no critical problem (Only a hang on the command line)
19:45imirkin: mjg59: ah ok
19:46imirkin: Processus42: well, if you're booting with efi, you should be able to use efifb before nouveau loads
19:46imirkin: once nouveau loads, it should take over from efifb
19:46imirkin: does that not happen?
19:46Processus42: efifb is already loading itself before nouveau. At least I believe so, since it is shown on a lsmod while nouveau is not.
19:47Processus42: Or maybe it wasn't. I'm curious about it now.
19:47Processus42: Would loading efifb before nouveau solve the problem as well ?
19:48imirkin: normally you build efifb into your kernel
19:49imirkin: so that it can start using efi services early on in the boot process
19:50imirkin: btw, not sure what you're trying to do
19:50imirkin: but you're not going to get a ton of utility with nouveau from your GTX 980
19:50imirkin: don't want you to waste your time
19:50Processus42: It looks like I didn't built in
19:51Processus42: Should I use the proprietary drivers from nvidia ? ;)
19:51imirkin: depends what your goal is
19:53Processus42: Currently, I am not using the GC under linux. I am using it only when I boot on Windows, for gaming purpose.
19:53imirkin: well if you're not using it, you don't need nouveau at all
19:53Processus42: I'm using it for my X, hopefully
19:53imirkin: that should be fine
19:54imirkin: lots of people have had issues with xf86-video-modesetting, i highly recommend sticking with xf86-video-nouveau
19:54Processus42: About the efifb stuff, do you recommand me to buid t it in ?
19:54imirkin: yes, i do.
19:54Processus42: *build it in
19:54Processus42: Okay. I'll do then
19:55Processus42: Sorry, but xf86-video-modesetting and xf86-video-nouveau are obscure words to me. I'm not good with the graphic stack.
19:55Processus42: Are thoses modules as well ?
19:57imirkin: software modules.
19:57imirkin: X has a pluggable architecture
19:57imirkin: the module driving the graphics card is known as a "DDX"
19:58imirkin: there's one included inside of the core X server nowadays called "modesetting"
19:58imirkin: it uses opengl to accelerate X calls
19:58imirkin: this only works well when you have a perfect opengl library
19:58imirkin: which sadly we do not
19:59imirkin: xf86-video-nouveau is the original implementation which programs the hardware in a more direct, simpler, safer manner
20:00Processus42: Thanks for the explanations :)
20:00Processus42: I want to know more about the linux graphic stack. I'll probably come back here to ask for entry points about the subject.
20:02imirkin: there's a good guide for it
20:02imirkin: hold on...
20:03imirkin: it's a little old, but still largely relevant
20:07Processus42: Thanks, I'll read
22:49RSpliet: imirkin_, skeggsb: pushed a trace alongside infinity0's bios