09:12 Tomin: RSpliet: great, can I have a look?
09:12 RSpliet: Tomin: https://github.com/RSpliet/kernel-nouveau-nv50-pm/commits/master
09:12 RSpliet: don't bother just compile-and-run it
09:12 RSpliet: it'll just lock up your machine (at best)
09:13 Tomin: ok
10:25 factor: I was running Nvidia's binary driver , now using Nouveau and two of my four monitors are not working. I moved the xorg.conf file to my new system but does not work. What is needed to get Nouveau to recognize my second Nvidia card?
10:28 factor: Will test out ZaphodHeads thing
10:34 factor: restarting X and trying again.
11:36 nailyk: Hi. At work i use some power g5 (ppc64) with debian. Since debian 8 the kernel pagesize setting had been changed. This new setting break the nouveau driver. I see on the https://nouveau.freedesktop.org/wiki/ToDo/ it is a work in progress.
11:37 nailyk: Is a page on a bugtracker open for that? I would help to debug this. I'm not a dev but i can compile, and make tests.
12:04 pmoreau: nailyk: There has been some work to get power g5 working with Nouveau, and I think at least part of it has already been merged.
12:10 pmoreau: nailyk: You could follow this bug report https://bugs.freedesktop.org/show_bug.cgi?id=94757
12:10 pmoreau: imirkin_ knows more about it
12:11 nailyk: pmoreau: Many thanks! Can i help in some way?
12:12 pmoreau: I think the main bottleneck is time and developers to patch the code, not necessarily testing, but I could be wrong.
12:13 pmoreau: imirkin_ and skeggsb should be able to tell you more about it when they are around.
12:14 pmoreau: In the mean time, you could try one of the images here https://nouveau.pmoreau.org/ with the Nouveau entry, to see if the latest version fixes it or not.
12:16 nailyk: i will check that. For now i'm running a self compiled kernel with modified pagesize. I will report back asap.
12:17 nailyk: Thanks a lot.
12:24 karolherbst_work: pmoreau: I doubt he will be able to user your images though :p
12:24 karolherbst_work: *use
12:25 pmoreau: Oh, yeah… I forgot about that…
12:26 pmoreau: nailyk: I forgot the images aren’t powerpc ones… So you’ll have to compile the latest version of Nouveau yourself.
12:35 nailyk: saw that. i'm looking for a nouveau compiling guide :)
12:45 pmoreau: The most up-to-date Nouveau repo is https://github.com/skeggsb/nouveau. Since it is an out-of-tree kernel, you will need the kernel sources and a compiled kernel somewhere. Then, just run `cd drm && LINUXDIR=path_to_your_kernel_sources make`.
12:46 pmoreau: That will give you the `nouveau.ko` in `drm/nouveau`
12:53 nailyk: perfect, i will try that
14:00 vedranm: came across a Dell XPS 14z with a VGA compatible controller: NVIDIA Corporation GF119M [GeForce GT 520M] (rev a1)
14:01 vedranm: DRI_PRIME=1 glxgears works out of the box
14:01 vedranm: kudos
14:09 NanoSector: nice
15:04 vedranm: and GL 4.3 even once I upgraded to Mesa 12 and Linux 4.6
15:04 vedranm: thx guys
15:22 RSpliet: http://www.realworldtech.com/tile-based-rasterization-nvidia-gpus/
15:24 karolherbst_work: RSpliet: yeah, mupuf already told me about this :)
15:24 RSpliet: ah yes, I didn't see that yet
15:25 RSpliet: love how robclark chimes in on the discussion ;-)
15:25 mupuf: RSpliet: pretty nice that they got oportunistic tiling, yeah
15:25 karolherbst_work: but I would assume you could see the same think on kepler2
15:25 RSpliet: why?
15:25 robclark: :-P
15:25 karolherbst_work: because they added a crapload of stuff under the hood in kepler2
15:26 karolherbst_work: dynamic parelleism and hyper-q stuff to name two things
15:27 RSpliet: meh, more terms for me to learn
15:29 karolherbst_work: well, it will never stop!
15:29 karolherbst_work: ohh crap, have to write that thing for xdc and I wanted to do that on the weekend...
15:29 karolherbst_work: well, I still have time :D
15:31 mupuf: oh yeah, I should probably send a reminder tomorrow, one week before the deadline
15:31 mupuf: and I need to write my abstract too :D
15:32 karolherbst_work: mupuf: I was thinking of doing this in the talk: 1. REed turbo boost stuff (mainly to talk about the vbios tables and how the policies work if all put together) 2. what is still missing to have a complete implementation (aka sw overheat protection, power budgets) 3. some extra fun aka prototypes for awesome user features
15:32 karolherbst_work: mupuf: deadline is 17th
15:33 mupuf: oh, I have been generous :D
15:33 karolherbst_work: :D
15:33 karolherbst_work: seems that way
15:33 mupuf: karolherbst_work: demo?
15:33 karolherbst_work: sure
15:33 mupuf: and maybe also the work left for dyn reclocking
15:33 karolherbst_work: ahh right
15:33 karolherbst_work: I could show my friggin awesome tool! :D
15:33 mupuf: which is?
15:33 mupuf: ah, yes!
15:33 karolherbst_work: nv_cmp_volt
15:33 mupuf: definitely!
15:33 karolherbst_work: :D
15:33 mupuf: this is definitely a must
15:34 karolherbst_work: 2. is what is still missing though
15:34 mupuf:does not get why ben does not want to merge it
15:34 karolherbst_work: oh well
15:34 karolherbst_work: I could add all that display crap
15:34 karolherbst_work: but that is way out of the topic
15:34 mupuf: is it? COmputing the watermarks is definitely not out of topic for memory reclocking
15:35 karolherbst_work: well, turboboost isn't memory related at all
15:35 karolherbst_work: maybe with pascal it is now
15:35 mupuf:doubts so
15:35 karolherbst_work: well
15:35 karolherbst_work: the memory clock is stable
15:35 karolherbst_work: doesn't change at all, except for the pstates
15:36 karolherbst_work: I think with pascal the memory clock is boosted now
15:36 mupuf: oh, you can also make some experiments on the power usage in idle, to show that even with static PM, it still helps
15:36 karolherbst_work: not quite sure though, never got time to look into that yet
15:36 karolherbst_work: ahh right
15:36 karolherbst_work: I have my clock gating stuff working, right
15:36 karolherbst_work: or what did you mean?
15:36 mupuf: oh, yeah, that too
15:36 mupuf: well, just downclocking
15:36 karolherbst_work: ahh
15:36 karolherbst_work: on full idle?
15:36 mupuf: yeah
15:36 karolherbst_work: k
15:36 karolherbst_work: yeah
15:36 karolherbst_work: that makes a huge difference
15:37 karolherbst_work: 10W vs 18W for me
15:37 mupuf: not bad
15:37 karolherbst_work: well, more like 9W
15:37 karolherbst_work: yeah, and this is _with_ clock gating
15:37 karolherbst_work: clock gating alone saves up to 3W on 0f idle or so
15:39 karolherbst_work: I just hope my GPU doesn'T crash then :D
15:39 mupuf: demos at the end :D
15:39 mupuf: if it crashes, then it is OK
15:39 karolherbst_work: and then I will be like, that never happened to me before
15:39 karolherbst_work: and everybody is like "sure, because nouveau is like rock stable" :p
15:39 mupuf: hehe
15:40 karolherbst_work: right, demos at the end, but I was more thinking about the reclocking stuff
15:40 karolherbst_work: especially, because I may have to switch to nvidia on the fly
15:40 karolherbst_work: ...
15:40 mupuf: can you do that without rebooting your xserver?
15:40 karolherbst_work: sometimes unloading nouveau doesn't work out at all
15:40 karolherbst_work: sure
15:40 mupuf: nice
15:40 karolherbst_work: yeah
15:41 karolherbst_work: dummy ddx driver to the rescue!
15:41 mupuf: only for dri3 though, right?
15:41 karolherbst_work: yes
15:41 karolherbst_work: but I have all my ports on the intel gpu
15:41 karolherbst_work: so I really don't care
15:42 mupuf:is losing his mind, trying to trace a multi-context, multi-screen DRI3 issue
15:42 karolherbst_work: uhhh
15:42 mlankhorst: :-D
15:42 karolherbst_work: those are the best
15:42 mupuf: the problem is the multiscreen here
15:42 mupuf: I do not even get why it works with DRI2
15:42 karolherbst_work: you can spend weeks on them and nobody complains :D
15:42 mlankhorst: mupuf: maybe in dri2 it does a page filp on the whole screen?
15:43 mupuf: I mean, they all share textures
15:43 mupuf: but they do not use the displaylist :s
15:44 karolherbst_work: the fun part in the talk will be to explain how we found out those friggin factors for the volt map table
15:44 mupuf: and when referencing a texture by its ID, it is looked up in a hashtable stored in the shared data (display list), but it is not shared at all
15:44 karolherbst_work: those were so painful
15:44 mupuf: hell, they don't even share the same X connection
15:45 mupuf: ah ah ah, yeah, but don't spend too long on this :)
15:45 karolherbst_work: :D
15:45 mupuf: but it is good to document the methods
15:45 karolherbst_work: with RE live demo!
15:45 mupuf: AHAHA, what could go right? :D
15:45 karolherbst_work: I think I spend like 3 full days just on those factors
15:46 karolherbst_work: anyway, will go now, cu later
16:36 kloofy: http://envytools.readthedocs.io/en/latest/hw/memory/g80-vram.html#tag-memory-addressing is the information how the tag is composed as for current pc introduced somewhere in some howto?
16:42 kloofy: http://www.cs.cmu.edu/afs/cs/academic/class/15745-s07/www/papers/presentations/gpu.pdf it should be round about so..but not enough knoweldge to document it
16:56 kloofy: 2 in power of 18 gives 262,144 kb that is bit too large for a cache size of l1 perhaps i mean at least for cellBE
16:58 kloofy: i mean back to this spammy scheduler stuff, that is one way again http://www.google.com.gt/patents/US6629188
16:58 kloofy: looks as if tag is matched to identify a cache hit
16:59 kloofy: and index and offset is automatically tied to tag in the circuit, so it can service them
17:21 kloofy: i mean it looks easy, but sure there are complications, needs some knowledge of kernel memory management and memory controller
17:22 kloofy: it is something in my reportoire that is the most complex part
17:26 kloofy: it's then so that you encode the memory map from kernel, as tag index and offset where index=opcode and offset=mask, allocate memory in such way
17:27 kloofy: and the unused mamory should go for defragmentation in the kernel somehow
17:29 kloofy: it looks very easy and may be very easy, but to be honest, it's one of the rearest things that i do not know how things work my own in the kernel...
17:33 kloofy: in that sense whoever is up to this with knowledge raise hands, cause i do not know enough how to make this, it's probably the most effective cause circuit in hw keeps masks for free in such way, it's definitely doable but could be quite hard
17:36 kloofy: actually i remember from ancient logs on the web that benh is actually pretty good probably in memory management world
17:52 kloofy: in other words the patent describes how tag is matched against cache lines, and FIFO services the index and offset of the tag in case of miss, where things will be fetched from memory
17:53 kloofy: in that sense if you have proper memory map in pagetebles somewhere, this masked execution comes for free, and is defintely more secure then the current map, but very easy to hack still
18:17 kloofy: http://lxr.free-electrons.com/source/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c amd has this stuff, as a matter of fact i can program it , it seems with the help of such feature
18:55 kloofy: http://www.ertl.jp/~shinpei/papers/pro13.pdf
18:58 kloofy: i dunno i am starting to getonto people nerves again, but looks as if pretty easily doable with nouveau too, if it ever supports indirection of shaders, which it probably does
20:01 RSpliet: mupuf: what's the length of a presentation?
20:02 mupuf: an hour ... unless we start lacking time
20:02 RSpliet: yugh, that's way too long for me
20:02 mupuf: ok, then make it 30 minutes long
20:03 mupuf: and say it is :)
20:03 RSpliet: 20mins presentation, 5 mins question, 5 minute coffee/tea sounds more like it :-P
20:03 RSpliet: but yes
20:06 mupuf: :)
20:09 karolherbst: mupuf: should I target 30 minutes for the stuff?
20:09 mupuf: target for an hour. If you finish early, that's more coffee for people
20:09 karolherbst: k
20:10 karolherbst: never had an hour long talk alone though, but I guess it should be fine
20:10 mupuf: well, you could get help for the general state of nouveau
20:11 karolherbst: ahh, so we do one big talk, not multiple ones
20:11 karolherbst: ohh wait
20:12 karolherbst: k, understood :D
20:12 karolherbst: no, it isn't a problem by itself, I already did a 1.5 h talk with another person, never in english though
20:12 mupuf: :)
20:13 mupuf:'s longest talk was ... 4h
20:13 karolherbst: :D
20:13 mupuf: that was getting tough in the end :D
20:13 mupuf: sorry, was 3h
20:14 mupuf: but then, I taught many classes for 4h in a row (with coffe breaks)
20:14 karolherbst: but the stuff we talked about today helps me already, I always just leave things out, which are somehow important, but never important enough for me...
20:14 karolherbst: mhh
20:15 karolherbst: does anybody know what is missing on the display side for memory reclocking?
20:15 karolherbst: I am kind of aware, but couldn't really talk about it
20:17 karolherbst: mupuf: while running glxgears at 60 fps: 10.25W on 07 and 20.95W at 0f
20:17 RSpliet: imho, if you need an hour, you're telling too much :-P
20:17 karolherbst: 17.01W at 0a
20:17 karolherbst: so
20:18 RSpliet: or actually
20:18 RSpliet: imnsho
20:18 karolherbst: memory from 1.6 to 4 GHz draws like 4W more power
20:19 karolherbst: dropping clocks (867 -> 705 @ 0.98 -> 0.89V) does reduce power consumption by 2.6W
20:20 karolherbst: enabling clock gating at 0f: 21W -> 19.20W
20:20 karolherbst: 17.13W with 705 clock
20:20 karolherbst: mupuf: just to give you some data ;)
20:20 RSpliet: karolherbst: keep in mind DRAM has some power-down modes that save power when idle
20:21 karolherbst: I am at idle
20:21 RSpliet: or more precisely, that the memory controller can use to save power when idle
20:21 karolherbst: mhhh
20:21 karolherbst: well, I am sure we miss stuff out
20:21 RSpliet: glxgears is not a very demanding workload on DRAM, so your measurements might not mean what you think they do
20:21 mupuf: RSpliet: the goal is more like 30-40 minutes of presentation, a lot of time for questions and coffee then we start again on time
20:22 karolherbst: RSpliet: I have runpm enabled, so I just wanted to run _something_
20:22 karolherbst: I get the same numbers on full idle
20:22 karolherbst: and that's what I am interessted int
20:22 RSpliet: karolherbst: merely commenting on your conclusion of "karolherbst: memory from 1.6 to 4 GHz draws like 4W more power" :-)
20:22 karolherbst: *in
20:23 karolherbst: right, I upclocked memory, and I just wanted to messure the static power consumption of the memory+mc by itself
20:25 karolherbst: RSpliet: wanna say anything about the state of fermi? I doubt it, but I ask anyway
20:25 karolherbst: but I guess this is more like general talk about nouveau stuff
20:25 RSpliet: karolherbst: I don't think there'll be any major breakthroughs between now and XDC
20:26 karolherbst: k
20:36 karolherbst: mupuf: by the way, what did you mean by "COmputing the watermarks"?
20:38 karolherbst: that would be my plan somewhat, allthough I am unsure about the order: https://gist.github.com/karolherbst/1d65a06abb9fb5faec96eb952861b902
20:48 karolherbst: mupuf: wanna say something about power management stuff? You actually did a lot regarding this, I think.
20:48 mupuf: well, not sure what I could say aside from what should be done
20:49 karolherbst: mhh
20:49 karolherbst: I think you messured sometihng about static power consumption once or the stuff you did in your papre
20:49 mupuf: and some things that could be done will be covered by my ezbench talk
20:49 karolherbst: ahh, I see
20:49 mupuf: sure, but this is not something relevant for the conference :)
20:49 karolherbst: hehe
20:50 mupuf: the plan looks good
20:50 mupuf: the linebuffer == watermarks
20:50 karolherbst: I think I would like to have a second machine for the talk though. Really don't want to have the system crash while I unload nouveau, or I just plan it in a way, where I never need to unload it
20:50 karolherbst: ahh
20:51 mupuf: but you would need two projectors?
20:51 karolherbst: mhh
20:51 mupuf: I guess it is possible, since we would have one for IRC
20:51 karolherbst: maybe
20:51 karolherbst: I would like to have one display for showing stuff
20:51 karolherbst: and another for monitoring
20:51 karolherbst: like I would like to have ksysguard running to show voltage/temp/power consumption of the gpu or something
20:52 karolherbst: or something else
20:52 mupuf: ah ah
20:52 mupuf: gallium hud?
20:52 karolherbst: well
20:52 karolherbst: that would only work with appropiate applications
20:53 karolherbst: but showing static power consumption would be tricky
20:53 mupuf: for this, you only need to poll the power consumption
20:53 karolherbst: mhh right
20:53 mupuf: a while loop is enough :D
20:53 karolherbst: damn you :p
20:53 karolherbst: well I could also just use a tiled window manager for the talk or so
20:54 karolherbst: I will come up with something nice
20:59 mupuf: hehe
21:00 karolherbst: another issue is, that I think my firmware of my laptop is pretty much messed up, so it would be a good idea to have a spare system ready for the case something happens :/ my machine just randomly crashes/reezes like once a month or so
21:03 karolherbst: it will be most likely fine though
21:03 karolherbst: otherwise I use the time to answer questions :p
21:32 pmoreau: karolherbst: If needed, you could use my laptop. It has a Kepler card that reclock just fine with your branch
21:36 karolherbst: pmoreau: 750m, was it?
21:37 karolherbst: well, I am sure it will be fine, it would be just good to have something as a backup
21:39 pmoreau: it is indeed
21:40 karolherbst: my mbp from work also has a 750m
22:58 NanoSector: pmoreau, considering yours reclocks fine and my 750M doesn't, is there anything we could compare?
22:59 NanoSector: pmoreau, or is yours a GDDR5 too?
23:42 kloofy: src/gallium/drivers/radeonsi/si_debug.c has the most info , as noone comments I'm still not entirely sure if shader could be splitted across IB's
23:42 kloofy: fprintf(f, "\nNote: The holes represent memory not used by the IB.\n"
23:42 kloofy: " Other buffers can still be allocated there.\n\n");
23:43 kloofy: though it says that holes not used by IB, can be allocated for other types of buffers
23:49 kloofy: agd5f: maybe you can comment on you'r code if the ib_get pointer makes also sense to parse the same shader across two or more separate IB buffer splits?