09:12 ask6155: hello
09:17 ask6155: karolherbst told me I could help fix the problem I have https://gitlab.freedesktop.org/drm/nouveau/-/issues/88 If I could recompile the kernel...
09:18 ask6155: I found on the arch wiki that to just patch a module I can just compile the module and replace it... if that is the case then I can compile the module I just don't know which lines I have to edit to fix the bug
09:20 karolherbst: yeah, I've spoken with skeggsb about the issue and there was something we could do about it, but can't really remember what the actualy fix was. You could always increase the sleep period inside that one function.. but let me see...
09:21 karolherbst: RSpliet also did some test and it didn't appear to really help
09:24 ask6155: I can still test it out... I have the kernel source. which line do I have to edit?
09:25 karolherbst: https://gitlab.freedesktop.org/drm/nouveau/-/blob/master/drivers/gpu/drm/nouveau/dispnv50/base507c.c#L155 inside base507c_ntfy_wait_begun
09:26 karolherbst: and change it to something like usleep_range(1000, 10000);
09:51 ask6155: okay module has been compiled. I should have asked this before but I'd like to add a print statement at the initialization stage of the module to identify that it is patched (for debugging) since I'm overwriting the module for the first time. in which file can I add a print statement?
09:51 ask6155: I have ccache so I think I won't have to compile it again?
09:54 karolherbst: ohh, if you just change one file you don't have to compile from scratch anyway
09:55 karolherbst: and a good place would be nouveau_drm_probe inside drivers/gpu/drm/nouveau/nouveau_drm.c
10:11 ask6155: success?
10:14 karolherbst: ask6155: so is it better now or still the same?
10:15 ask6155: better(?)
10:16 ask6155: https://imgur.com/FKmnmLF
10:16 ask6155: perf report
10:16 karolherbst: well, at least no nouveau
10:16 karolherbst: not sure what the swapper is doing
10:17 ask6155: does it have anything to do with swapiness?
10:17 karolherbst: could be
10:17 karolherbst: maybe wait a bit and do it again and see what changes
10:18 ask6155: okay
10:18 karolherbst: ohh wait no
10:18 karolherbst: swapper is the "idle" task
10:18 karolherbst: so that means your kernel isn't doing anything really
10:18 karolherbst: just check with htop/top your overall CPU load
10:18 karolherbst: if that's a one digit number you are good
10:19 karolherbst: perf doesn't care about CPU load
10:19 karolherbst: so even if your system isn't doing anything, it sums up to 100%
10:20 ask6155: 2 cores add up to 15%
10:20 karolherbst: what are they busy with?
10:21 ask6155: X compositor and window manager
10:21 karolherbst: okay
10:22 karolherbst: then I guess it's "better" indeed, your system is just busy with other things
10:22 karolherbst: or your compositor is doing more stuff than actually needed
10:22 karolherbst: okay..
10:22 karolherbst: but I guess without that patch, nouveau/the kernel were using more CPU time overall?
10:23 ask6155: well compositor needs to be configured better. I run picom and there is still screen tearing and I have to look into how to stop that... There are also glitches ;(
10:23 ask6155: yeah I think they were using more gpu
10:23 ask6155: *cpu
10:23 karolherbst: ahh yeah...
10:24 karolherbst: usually it's better to just use a compositor from a normal desktop. They are also tuned to use as few CPU cycles as possible
10:24 karolherbst: or use something like compton
10:24 karolherbst: but yeah...
10:24 ask6155: compton is dead I think
10:24 karolherbst: ahh
10:24 ask6155: so I switched to picom
10:24 karolherbst: I am just using what the desktop gives me as this usually works best
10:25 karolherbst: and with wayland you don't have much of a choice anyway :p
10:25 orbea: karolherbst: picom is the continuation of comptom
10:25 karolherbst: I see...
10:25 karolherbst: why does it tear then? :D
10:25 karolherbst: and why does it use so much CPU?
10:25 orbea: you need special arguments to get it to stop tearing with nouveau
10:25 ask6155: they say there is a secret set of options in picom which will stop screen tearing... I don't know them
10:25 orbea: the arch wiki might have them?
10:25 karolherbst: orbea: ahh could be as we have no workarounds inside the DDX
10:25 orbea: under the nvidia section
10:26 karolherbst: tearing under X is a lost cause anyway
10:26 ask6155: no... the ones given there are for compton and anyway don't work for me ;(
10:26 orbea: i know I have seen it work before, but I have amd plugged in right now
10:26 ask6155: proprietary drivers don't have screen tearing
10:27 ask6155: maybe there is a setting to fix it...
10:33 ask6155: I think you can take this as a fix?
10:33 karolherbst: not sure
10:34 karolherbst: I think there is a reason the sleep is so low...
10:34 karolherbst: but...
10:34 karolherbst: not sure what the disadvantage here is
10:35 karolherbst: but at least we know it's indeed this wait causing issues
10:36 karolherbst: I think skeggsb has some ideas here.. but...
10:36 ask6155: is the swapper an issue or is that normal behaviour?
10:37 karolherbst: normal
10:37 karolherbst: it's essentially a "the kernel doesn't have anything better to do" task
10:37 karolherbst: and it handles the CPU freq stuff and so on
10:37 karolherbst: afaik
10:38 ask6155: okay
10:38 ask6155: what does the sleep *do*?
10:39 karolherbst: waiting
10:39 karolherbst: or well
10:39 karolherbst: nothing
10:39 ask6155: what does the range do then?
10:39 karolherbst: it's essentially a hint to the scheduler that the task has nothing to do for a given period of time
10:39 karolherbst: it's a min/max range
10:40 karolherbst: so if the CPU is woken up anyway, and your task slept already for the min amount, your task get scheduled
10:40 karolherbst: if nothing woke the CPU up until the max count, the timer triggers
10:40 ask6155: aah
10:40 karolherbst: yeah, it's some nice power saving feature :D
10:40 karolherbst: apple also has something similiar within their OS
10:40 ask6155: and what does it do when it wakes up?
10:41 karolherbst: well, the task continues working on stuff
10:42 ask6155: so I guess there is a performance hit then since it sleeps for longer?
10:42 karolherbst: not necassarily
10:42 karolherbst: it might hurt responsiveness
10:43 karolherbst: usually if it comes to displays, you want low latency stuff and such.. so maybe you can get dropped frames or so? dunno
10:47 ask6155: I think there is?
10:53 ask6155: I got 250 on unigine valley on high
10:53 ask6155: I used to get 300+ I think
10:54 ask6155: I'll take a control test to confirm
11:09 ask6155: um this is awkward
11:10 karolherbst: ask6155: benchmarking is hard
11:10 ask6155: the control and the patch got the same score
11:10 karolherbst: yeah
11:10 ask6155: but the thing is... now I'm on the control and the cpu usage is the same as the patch
11:11 karolherbst: :/
11:11 karolherbst: mhhh
11:11 karolherbst: maybe it's just some random state the GPU is somtimes in?
11:11 karolherbst: or maybe it gets worse over time?
11:11 ask6155: I did update the kernel so that the module could be loaded in since it needs to be the same version
11:12 karolherbst: that could have changed something... but maybe it's just a coincidence
11:12 karolherbst: sometimes those issues are also a bit random :/
11:12 karolherbst: hardware being hardware and all that
11:13 ask6155: I was on 5.10.24-lts when I took the perf screenshot in the issue
11:13 ask6155: now i'm on 31
11:14 karolherbst: well if you can reliably reproduce it with the older kernel that might give us a better idea
11:14 karolherbst: but chances are it won't reproduce
11:14 ask6155: I'll try that
11:18 ask6155: um
11:19 ask6155: well now kworker is using 40-60% of the cpu
11:19 ask6155: it is the kernel
11:20 ask6155: I guess it is *fixed*?
11:25 karolherbst: mhhh
11:25 karolherbst: sample size 1 is always... .. open for errors, but yeah
11:25 karolherbst: maybe some patch fixed it
11:25 karolherbst: RSpliet mentioned having the issue as well
11:25 karolherbst: not sure what kernel was tested
11:27 ask6155: I saw the fosdem talk on nouveau and I felt I've seen that name... It was you! :D
11:29 ask6155: it was pretty good...
11:34 karolherbst: ask6155: thanks
11:35 ask6155: this is weird...
11:35 ask6155: the high kworker usage happens on both kernel version
11:35 ask6155: BUT
11:35 ask6155: it only happens when I run picom
11:36 ask6155: when I kill it it goes away
11:36 karolherbst: ahh
11:36 karolherbst: that makes sense
11:36 karolherbst: picom probably makes use of the atomic kms API
11:36 karolherbst: and that triggers it
11:36 karolherbst: without using that, there is no point doing all the stuff I guess
11:36 karolherbst: I am not an expert in this area, so just making wild assumptions :p
11:37 ask6155: so is picom at fault here or the driver?
11:37 ask6155: I'm on control
11:38 karolherbst: the driver
11:38 karolherbst: probably
11:38 karolherbst: it might be that picom just using an API way too often
11:38 karolherbst: *is
11:38 ask6155: but then why is it not counted as it's cpu usage?
11:39 karolherbst: like... imagine it tries to page flip 1000 a second
11:39 karolherbst: ask6155: because what picom is doing is probably very cheap
11:39 karolherbst: and kernel space is counted extra
11:39 karolherbst: that's always the issue with IPC
11:39 karolherbst: attribution is hard
11:40 ask6155: maybe I can try different picom flags
11:40 karolherbst: yeah...
11:40 karolherbst: my assumption is, if you get rid of the tearing and get proper vsyinc
11:40 karolherbst: it might fix the CPU issue as well
11:40 karolherbst: *vsync
11:42 ask6155: okay I've figured stuff out
11:42 ask6155: when picom uses glx as the backend the problem occurs
11:43 ask6155: and it puts a warning that might be related
11:43 ask6155: GLX_EXT_buffer_age not supported by your driver,`use-damage` has to be disabled
11:45 karolherbst: ufff
11:46 karolherbst: ask6155: ahh.. you need dri3 emabled
11:46 karolherbst: *enabled
11:46 karolherbst: check your X logs
11:46 karolherbst: but I assume you will have to use the modesetting driver for that
11:47 karolherbst: dunno if the nouveau ddx even supports dri3
11:49 ask6155: I found something
11:49 ask6155: on the wiki
11:50 ask6155: glFinish, glClientWaitSync, etc. use busy waiting, causing high CPU usage in the client
11:50 karolherbst: yeah well.. that's a picom bug then
11:50 ask6155: also it has a number of other quirks
11:50 karolherbst: but for that you have the damage extension in X
11:50 karolherbst: using dri3 is really not optional anymore
11:51 karolherbst: and everybody saying anything else has no clue :p
11:51 karolherbst: ehh
11:51 karolherbst: present extension actually
11:51 ask6155: Doesn't implement the Present extension, or DRI3.
11:51 ask6155: also given on page
11:51 karolherbst: picom?
11:51 ask6155: yeah
11:51 karolherbst: okay, use something else then :D
11:52 ask6155: i dunno if that means picom or the drivers
11:52 karolherbst: well, mesa supports it
11:52 karolherbst: as long as your xorg server enables it
11:52 karolherbst: this all works with other compositors
11:52 ask6155: how do I check that
11:52 karolherbst: the X log should contain something about dri3
11:52 ask6155: it contains nothing
11:52 karolherbst: "(II) Initializing extension DRI3" e.g.
11:53 ask6155: wait no
11:53 ask6155: it says that
11:53 karolherbst: mhh
11:53 karolherbst: weird
11:53 karolherbst: mind sharing your entire current Xorg log?
11:54 ask6155: this is the running log I think
11:54 ask6155: http://ix.io/2WQl
11:54 karolherbst: "Allowed maximum DRI level 2." :/
11:55 karolherbst: I think dri3 might needs to be enabled explicitly...
11:55 ask6155: what is it?
11:56 karolherbst: it will give you GLX_EXT_buffer_age
11:56 karolherbst: but with dri3 all the tearing stuff is... less worse
11:56 karolherbst: so compositors usually make use of that
11:56 ask6155: sign me up!
11:56 karolherbst: with dri2 it's all... broken and workarounds involve using a lot of CPU
11:57 ask6155: how do I enable it?
11:57 karolherbst: yeah.. I don't know how to enable that with the nouveau ddx except using modesetting :/
11:57 karolherbst: or well... I prefer to just use wayland and ignore X completely as it's not really worth the effort :p...
11:58 ask6155: isn't modesetting like adding a kernel parameter?
11:58 karolherbst: but I think there was an option inside xorg.conf
11:58 karolherbst: ask6155: there is also an x driver
11:58 karolherbst: but some people hate it
11:58 ask6155: I found this page
11:58 ask6155: https://github.com/yshui/picom/wiki/Xorg-Rants
11:58 karolherbst: ask6155: maybe like this? https://gist.githubusercontent.com/karolherbst/eb7f7668ca4b5acd6ddd423180f434a0/raw/d15b356ddab9866fbf81c0efd3d3d69f885ab02b/gistfile1.txt
12:00 karolherbst: ask6155: you also want "--experimental-backends" as it seems
12:00 karolherbst: ask6155: https://github.com/yshui/picom/wiki/Vsync-Situation
12:04 RSpliet: karolherbst: RE high CPU utilisation: I was on 5.11.12. I now have a 5.14 with increaed usleep ranges, but to no avail - still reproducible
12:04 karolherbst: RSpliet: it seems like the issue is the compositor doing on a CPU wasting spree
12:04 RSpliet: Wayland, F33, Gnome Shell/Mutter
12:04 karolherbst: ahhh
12:05 ask6155: why is dri3 no enabled by default
12:06 ask6155: *not
12:06 karolherbst: no clue
12:06 karolherbst: ask6155: did the snippet help?
12:06 ask6155: yeah
12:06 karolherbst: cool
12:06 karolherbst: also with the tearing?
12:06 ask6155: glx backend doesn't use high cpu now
12:06 karolherbst: nice
12:07 ask6155: the tearing is there
12:07 karolherbst: ahh sad :/
12:07 karolherbst: mind sharing your new x log though?
12:07 karolherbst: just wanting to confirm some stuff
12:07 RSpliet: karolherbst: sorry, I mean 5.11.14 ofcourse. 5.14 is non-existing
12:12 ask6155: did u get the link?
12:12 karolherbst: nope
12:12 ask6155: http://ix.io/2WQr
12:12 ask6155: I think the client glitched
12:12 ask6155: irc client that is
12:13 karolherbst: ask6155: ahh yeah, seems everything is in order
12:13 karolherbst: you might have to follow those picom instructions to get rid of tearing
12:14 ask6155: experimental yeah
12:14 ask6155: *experimental backend and vsync = true fixes it
12:14 karolherbst: cool
12:14 karolherbst: still low CPU usage?
12:16 ask6155: well the perf report says ioread32 has gone down to 4.9%
12:17 karolherbst: okay.. I guess that's good enough
12:17 ask6155: I was reading the xorg rants page and it was not pretty
12:17 ask6155: is wayland viable?
12:17 karolherbst: well, using it for over a year now
12:17 karolherbst: seems good enough
12:18 karolherbst: there are some caveats
12:18 ask6155: I mean...
12:18 ask6155: do things just werk?
12:18 karolherbst: like if you use chrome/chromium you might not want to use wayland yet unless you except that on 4k the window is a bit blurry
12:18 karolherbst: ahh, yeah, mostly
12:18 karolherbst: X applications are limited
12:18 ask6155: what consists of x applications?
12:18 karolherbst: like steam has tons of X only features which you can't really fake that easily
12:19 karolherbst: closed source games are mostly X
12:19 karolherbst: stuff like stadia doens't really work well if chromium uses the experimental wayland backend
12:19 karolherbst: random stuff nobody cares about
12:19 karolherbst: as long as you simply use your desktop it's fine
12:19 karolherbst: even playing games usually works
12:20 karolherbst: there are just some niche features being broken
12:20 karolherbst: like steam does some gamepad emulation stuff
12:20 ask6155: what do you consider as *games*?
12:20 karolherbst: well.. games :D
12:20 karolherbst: they only target X
12:20 karolherbst: but that's not an issue directly
12:20 ask6155: I really only care about minecraft and wine
12:20 karolherbst: ahh...
12:21 karolherbst: that should be fine.... I think
12:21 karolherbst: you can always try and see how it works, but usually there is not that huge benefit unless you have a system not supported by X
12:21 karolherbst: like mixed DPI display setups
12:21 ask6155: also I use bspwm and I've customized it to be /comfy/ I don't think bspwm can do wayland
12:21 karolherbst: mixing a FHD and 4K screen just doesn't work in X
12:22 karolherbst: yeah. probably not
12:22 karolherbst: the mixed DPI display setup was my reason to finally move over
12:22 karolherbst: as this is really not berable with X
12:22 karolherbst: *bearable
12:22 ask6155: I've never had a monitor higher than 1366x768
12:22 karolherbst: okay... sad
12:23 karolherbst: and I am like "I won't use anything below 4k anymore" :D
12:23 ask6155: I think for a monitor 1080p is more than enough...
12:23 karolherbst: depends on the size
12:23 karolherbst: but you really see the difference
12:24 karolherbst: for a 13" one, yeah, probablye 1080p is enough
12:24 karolherbst: but I have a 27" one here
12:24 karolherbst: and there you clearly see the difference
12:24 ask6155: for a tv 4K maybe worth it
12:24 karolherbst: the biggest advantage is not really having more pixels, but you font doesn't need to be as big to be still readable
12:24 karolherbst: *the
12:25 karolherbst: so smaller font sizes still work just as good
12:25 karolherbst: and for gaming it makes a _huge_ difference actually :D
12:25 karolherbst: but without the GPU it's all useless anyway
12:26 karolherbst: using 2x SS was always so much better than 8x MSAA or whatever other options you had
12:26 karolherbst: but with 4k it's even better
12:27 ask6155: I'm more of the 'ugly games can be good too' category
12:27 karolherbst: ohh, sure
12:27 karolherbst: not arguing that
12:27 karolherbst: but if I can make the games look even better :p
12:27 karolherbst: last new game I tried was everspace 2
12:27 karolherbst: that's... ui.... it just looks so awesome :D
12:27 ask6155: 'a 60GB game is too big'
12:28 karolherbst: it's worth it
12:28 karolherbst: sometimes
12:28 karolherbst: for everspace 2 I gladly sacrifize 50GB of space
12:28 karolherbst: just look at the pictures :D
12:29 karolherbst:big fan of space shooter games
12:29 karolherbst: but yeah, there are also a lot of garbabe game their only positive aspect is to look good
12:30 karolherbst: soo...
12:30 karolherbst: I also have a tons of 2d games I really like
12:30 ask6155: due to my low resources I've been looking into no graphics games like dwarf fortress, nethack...
12:30 karolherbst: dwarf fortress is "fun" :3
12:31 ask6155: _haha_
12:31 ask6155: text based games have a special charm...
12:32 karolherbst: yeah, they have
12:32 ask6155: I mostly look at games at this website: osgameclones.com
12:33 ask6155: anyways I guess my *that* issue is fixed...
12:33 karolherbst: cool
12:34 ask6155: I'll come back with different ones soon
12:34 karolherbst: yeah.. not sure why dri3 isn't enabled by default
12:34 karolherbst: maybe we should look into on how to do it
12:34 karolherbst: but I fear the answer is "not that simple" :/
12:35 ask6155: there are random errors which popup is dmesg, minecraft 1.12 doesn't work with mods, etc etc
12:36 karolherbst: yeah.. minecraft is hitting a bigger issue I am working on a fix atm
12:36 karolherbst: it's just a lot of work
12:36 karolherbst: well.. the fix itself not so much, but not regressing anything is
12:36 ask6155: but maybe my pc issue will be fixed and I can switch back to nvidia drivers >:)
12:38 karolherbst: maybe
12:38 karolherbst: but probably not as you are already on a legacy branch, no?
12:41 me_: well the whole pc froze
12:43 ask6155: this issue is complicated and for now I'm using nouveau drivers because there are more 'configurable'
12:43 ask6155: *they
12:44 ask6155: I'm on the main branch
12:44 ask6155: the issue is unrelated to the driver
12:45 karolherbst: ohh right.. you had a kepler2 GPU...
12:46 karolherbst: imirkin: is there a way to default to dri3?
12:46 karolherbst: mhh.. actually there should be because modesetting is doing this as well
12:47 ask6155: I thought he sleeps at this time?
12:47 karolherbst: sure, but might see it in the backlog :D
12:48 ask6155: also the minecraft modding problems gets fixed in 1.13 or a higher version... somehow
12:50 ask6155: i guess I'm done here for today... thank you
12:50 karolherbst: yw
15:43 imirkin: karolherbst: dri3 is the default.
15:52 karolherbst: imirkin: mhhh... why did a user had to explicitly enable dri3 then?
15:53 karolherbst: downstream patches or sw too old?
15:53 imirkin: karolherbst: oh, in the nouveau ddx?
15:54 karolherbst: yes
15:54 imirkin: sorry, i'm like half-asleep
15:54 imirkin: dri3 is the default in mesa
15:54 karolherbst: in mesa, sure
15:54 imirkin: nouveau ddx does not expose dri3 by default
15:54 karolherbst: any reason why?
15:54 imirkin: dri3 + exa = sometimes fail
15:54 karolherbst: ohh, I remember :/ ufff
15:54 imirkin: not usually
15:54 imirkin: but sometimes
15:54 karolherbst: that's... bad :/
15:55 karolherbst: we really should default to dri3 though
15:55 imirkin: iirc it was only kde that was triggering the badness
15:55 imirkin: yeah, i could consider flipping it
15:55 imirkin: and/or adding a compile option for the default
15:55 karolherbst: I'd just flip it and work out the bugs
15:55 imirkin: er, s/compile/configure/
15:55 imirkin: the bugs are unfixable
15:55 karolherbst: ahh, reasonable
15:55 imirkin: they are architectural-level
15:55 karolherbst: imirkin: yeah, well, X is unfixable, so yeah
15:55 imirkin: that's ... not what i'm talking about
15:55 imirkin: dri3 is incompatible with exa's architecture. as i understand it, at least.
15:56 imirkin: X is the definition of perfection, and thus does not require fixing ;)
15:56 karolherbst: sure
15:57 karolherbst: imirkin: worst case, we add some stupid workaround? dunno :/
15:57 karolherbst: having to use dri2 is not.. great
15:57 imirkin: i'll be honest - i'm weak on the details of what's broken about it
15:58 imirkin: MrCooper is the only person i'm aware of who could explain what's wrong
15:58 karolherbst: but some might argue if you run KDE you can also just use modesetting anyway :D
15:58 imirkin: coz of full-page compositor?
15:58 imirkin: that's probably fair
16:00 karolherbst: yeah
16:00 karolherbst: you run 20 GL applications anyway, so one more won't matter much
19:19 pmoreau: Nice, tls could end up under-allocated due to how tls_size was computed.
20:31 pmoreau: Does someone know how l[] addressing works? I was under the impression that the shader would have something like l[0x0] and the hardware would automatically compute an offset added to that so that each thread ends up accessing their own private data.
20:31 pmoreau: But I am getting confused by the description of LOCAL_WARPS_LOG_ALLOC: “number of bits in l[] addressing used for warp number”.
20:32 imirkin: i don't know anything about that, fwiw
20:32 imirkin: maybe you can hit other threads' private data by messing with the address?
20:33 pmoreau: How come you don’t know everything single bit of information about the hardware! :-D
20:33 pmoreau: No worries
20:33 imirkin: because i'm not mwk
20:33 imirkin: i know every other bit :)
20:33 pmoreau: ;-)
20:33 imirkin: this one appears to have gotten skipped
20:34 pmoreau: Only going for the odd or even ones?
20:34 imirkin: ("every other", i.e. "half", not "N-1")
20:34 imirkin: nah, i try to have a more sophisticated scheme for partitioning integers into 2
20:34 pmoreau: I see
20:35 imirkin: odds/evens is just so boring
20:35 pmoreau: True
20:36 pmoreau: I’ll need to do some experimenting with a simple shader. I am a bit confused why the current compute code adds a 65536 offset to the TLS bo address, when the graphics code does no such thing.
20:36 imirkin: oh
20:36 imirkin: that's unrelated
20:36 imirkin: i'm guessing it's so that they don't step over each other? dunno
20:37 RSpliet: pmoreau: you probably need to tell it how many warps fit in a work-group, so that they split the allocation evenly
20:37 imirkin: pmoreau: btw, 50c0 docs are published
20:37 pmoreau: 👀
20:37 imirkin: https://nvidia.github.io/open-gpu-doc/classes/compute/
20:37 RSpliet: I suspect they don't just clip the memory in equal chunks, but they interleave data from different warps using some magical mapping to reduce the chance for bank conflicts.
20:37 imirkin: ok, maybe not *docs*
20:38 imirkin: but at least class method names
20:38 imirkin: which are bettert than UNK0360
20:38 imirkin: (it's not a high bar)
20:38 pmoreau: RSpliet: That’s a good point
20:41 mwk: pmoreau: for G80, I've got it basically figured out
20:41 mwk: or... had, at least; I'm not sure it's actually written down
20:41 imirkin: still all in your head, presumably, assuming you've been wearing ear plugs?
20:42 pmoreau: If you have pointers to the information or remember it, I would gladly read/hear it. :-)
20:42 mwk: anyway, this is exactly what it says on the tin; determines how many bits of address correspond to warp id
20:42 RSpliet: pmoreau: from the name I'd say set it to the log2 of the number of warps in a WG, rounded up to the nearest integer. (or round up the number of warps to the nearest POT, whatever you fancy :-P)
20:42 imirkin: [so that it doesn't spill out]
20:42 mwk: which directly influences how many warps can be used at once
20:42 mwk: ie. if you set it to 3, only warps 0-7 can ever become active on a given MP
20:43 mwk: so you can reduce memory usage but it costs you parallelism
20:43 mwk: (and lowers max group size)
20:44 mwk: there is also the "LOCAL_WARPS_NO_CLAMP" switch, which explicitely tells it to use fewer bits for addressing, but *ignore* the limit, meaning that some warps will walk over each others' data
20:46 pmoreau: Ooh I think I had missed the bit: when you say “how many bits of address correspond to warp id”, you are talking about the final addressing done by the GPU so that each threads can access its own region, not the address specified in the load/store to local mem instruction, right?
20:46 mwk: yes
20:46 pmoreau: That makes a lot more sense!
20:46 pmoreau: Thank you :-)
20:48 pmoreau: And the limit of local memory one thread can access is 64KiB?
20:49 mwk: it is any power of two between 16 bytes and 64kiB, as determined by LOCAL_SIZE_LOG
20:50 pmoreau: Gotcha
20:51 pmoreau: I was going to say: why isn’t 8 bytes the minimum since the size is only divided by 8 in the formula, but the result still need to be a power of 2, so 16 it is.
20:51 mwk: because the minimum non-0 value of the log is 1
20:52 mwk: 0 just disables local storage entirely
20:52 pmoreau: Oh right
20:52 pmoreau: Does it have any impact (disabling it)?