07:50inglor: According to archlinux wiki to enable power management in nouveau I have to add the "nouveau.pstate=1" to the "module configuration". That module configuration is the /etc/modprobe.d/nouveau.conf right ?
07:53pmoreau: inglor: nouveau.pstate was prior to kernel 4.5. Since kernel 4.5, you do not need that option.
07:53inglor: right so it automatically adjust to the different profiles my card has
07:54pmoreau: You can put it in /etc/modprobe.d/nouveau.conf, /etc/modprobe.d/somerandomefilename.conf, or directly on the kernel command line
07:54inglor: cheers :)
07:54pmoreau: No, it let’s you modify switch between them
07:54pmoreau: Automatic reclocking is only available on one of Karol’s branch
07:55inglor: yeah I'm about to try it out
07:55pmoreau: But I have no idea which branch it is
07:55inglor: stable_reclocking_kepler_v5 branch
07:55pmoreau: It doesn’t reclock automatically
07:56pmoreau: Or, at least, I have never seen my laptop automatically reclock while using that branch
07:57pmoreau: dynamic_reclocking is most likely the one with dynamic reclocking :-D
07:58inglor: you do have a point there..
07:59pmoreau: Changing perf levels is quite easy though, so you can simply bump to highest before playing, and go back to lowest or second lowest afterwards.
08:00inglor: I want lowest to not hear the sound of the fan
08:01inglor: how do I check the current profile in nouveau?
08:01pmoreau: Which kernel version do you have?
08:01pmoreau: Then, it’s `cat /sys/kernel/debug/dri/0/pstate`
08:02pmoreau: Or 1, depending if you have an integrated, and which one ends up being 1 or 0
08:02pmoreau: (As root of course)
08:02pmoreau: And you need debugfs to be mounted
08:03pmoreau: If you want to change to another level, just echo the corresponding level (03, 07, 0a, 0f, etc.) to that file
08:03inglor: ok got the various profiles..
08:05inglor: How do I know which one is active now? https://ptpb.pw/J1qo
08:05pmoreau: AC shows the current clocks
08:05inglor: so it's already at lowest..
08:06pmoreau: You should be able to get the fan speed and GPU temp using `sensors`
08:06inglor: that's 5C more than when using nvidia drivers
08:06inglor: and fan spins about ~200 RPM more..
08:07inglor: I bet it's the stupid specific card! 690
08:07inglor: who had this great idea of putting 2 cores into 1 card and have only 1 fan!
08:07pmoreau: 200 rpm more isn’t much. Is the sound difference noticeable?
08:08pmoreau: My GM206 (960 IIRC) has one core and three fans
08:09inglor: it is. I'll leave it running and come back after work to check out the temps and stuff. Usually the card "stuck" to higher profile after some time I think it has to do something with monitor sleep.
08:09pmoreau: At which percentage is it from max? It could be a bug in Nouveau
08:09inglor: also I'll give a go to the dynamic profiles branch once again
08:10pmoreau: Well, current_speed/max_speed*100
08:10inglor: 324/1202 * 100
08:11pmoreau: Well, should be more like (current_speed-min_speed)/(max_speed-min_speed)*100, but well
08:11karolherbst_work: pmoreau: mhh odd, you found the branch, and it was to well hidden
08:11inglor: haha @ karolherbst_work
08:11inglor: you gave me wrong branch!
08:12pmoreau: karolherbst_work: It’s like the second branch in the active section on your repo! :-p
08:12inglor: I can do some testing with the various branches on this card
08:12inglor: but compared to 4.4 kernel the new nouveau drivers are relatively quiter
08:13karolherbst_work: inglor: nouveau misses some power saving stuff
08:13inglor: yeah let's fix that! :D
08:13karolherbst_work: well, I know how to fix it partly on chips where stuff is already configured
08:13karolherbst_work: but usually those are mobile chips
08:13inglor: power reported from sensors are: 17W x2
08:14karolherbst_work: should be wrong
08:14inglor: haha such trust on the code..
08:14karolherbst_work: you need this patch: https://github.com/karolherbst/nouveau/commit/ad52418a53a8196605650e38829c01989ac7e0f8
08:15inglor: ok I need to run now. I'll keep note and apply the patch on top of the kepler stable branch
08:15inglor: you gave me
08:15karolherbst_work: pmoreau: well, I prepared for XDC :D
08:15inglor: (i hope it merges with no conflicts)
08:15karolherbst_work: nvidia guys are giving us useless information, have to show them what our situation is actually :D
08:16inglor: we can possibly decrease the voltage
08:16inglor: GPU core: +0.99 V (min = +0.79 V, max = +1.18 V)
08:16karolherbst_work: with my patches we volt exactly as nividia
08:16inglor: still - i don't have the patch so this info might be wrong
08:16inglor: yeah I figured after i posted the above :D
08:17karolherbst_work: stock clock have usually higher voltages than actually needed
08:17karolherbst_work: so a reclock to 07 might lower it
08:18karolherbst_work: the dynamic_reclocking branch is highly experimental and could crash your card within seconds
08:19inglor: yay! \o/
08:19pmoreau: Maybe even twice faster, since you have twice the cores :-)
08:20karolherbst_work: inglor: well you should use the stable_reclocking_kepler_v5 branch if you don't mind to reclock yourself
08:20inglor: I am
08:20inglor: works ok so far
08:20karolherbst_work: did you reclock to 07?
08:20inglor: I just patched with the new patch you gave me
08:20karolherbst_work: it should lower the voltage
08:20inglor: (it didn't)
08:20karolherbst_work: I see
08:21karolherbst_work: on my gpu it lowers it by 0.05V
08:23inglor: no difference in sensors after the patch.
08:24karolherbst_work: this is odd
08:25karolherbst_work: are you sure you installed it correctly?
08:28karolherbst_work: allthough, maybe 17W idle is fine :/
08:28karolherbst_work: it's a bit low
08:57asdf_: hi, i hope someone can help me. I'm running windows 10 and my GTX 660Ti is stuck at 2.5GT/s x1 even under load
08:57asdf_: I'm using lspci to look at the device capabilities
08:58asdf_: I think i have figured out which registers to change to enable 5GT/s, but it appears the registers are read only...
08:59asdf_: in gk104.c, it has under gk104_pcie_set_lnkctl_speed, register a8 sets the lnkctl speed
08:59asdf_: but when I use setpci to set the register, then read it back, it hasn't changed.
09:01asdf_: someone said I can change the registers on the fly and see the link speed change. Are these registers (lnkcap, lnkctl and link speed) read only? or can they only be changed in a pre boot environment?
09:07karolherbst_work: they can be written
09:07karolherbst_work: no clue how that works out on windows
12:01inglor: karolherbst_work: I copied the .ko file on the /usr/lib/modules/`uname`/kernel/driver/gpu/drm/nouveau/ previous files were renamed to nouveau-old.ko.gz (should I remove those from the path?)
12:08pmoreau: inglor: Renaming it should be enough
12:09pmoreau: But, you might need to regenerate the initramfs
12:12karolherbst_work: inglor: did you regenerate initramfs?
12:12karolherbst_work: and yeah, you should remove old files
12:12karolherbst_work: maybe next time I read what was written before commenting :D
12:14inglor: haha ok ok I got it. Also your version is there anyway to make sure it's loaded? My dmesg | grep -i nouveau is like this: https://ptpb.pw/z-me
12:14inglor: Does it output a dev version number or something?
12:15pmoreau: I think there is a version number for the kernel module, but it never gets bumped, no matter what. :-D
12:16inglor: fail.. how do you know which version of nouveau you use? It's only from kernel version?
12:17karolherbst_work: pmoreau: it gets bumped from time to time :O
12:17inglor: The module should debug print it at least..
12:17inglor: in load
12:17karolherbst_work: the think is
12:17karolherbst_work: the same Makefiles are used as within the kernel
12:17karolherbst_work: makes stuff a bit complicated
12:18inglor: but but I am talking about runtime.
12:18pmoreau: Really? Interesting. I should follow that a bit more
12:18inglor: not build time
12:18karolherbst_work: pmoreau: yeah, for interface changes
12:18karolherbst_work: 1.3 was this new syscall stuff
12:18karolherbst_work: or something
12:18inglor: ah I think we are talking for different things..
12:18pmoreau: Makes sense
12:19inglor: you both refering to the API changes internally
12:19inglor: I was more looking for something like commit version.
12:20inglor: wait I will rethink what I am saying..
12:20inglor: your initial answers seems more like an actual answer now..
12:21inglor: I think you cannot unless you use git-submodules or something
12:21inglor: and kernel won't change for that :D
12:22karolherbst_work: you missunderstood
12:22pmoreau: If you want to be sure you loaded the correct module, you could add a printk in `nouveau_drm_init()` (nouveau_drm.c), or load the module manually using insmod and the absolute path
12:22karolherbst_work: the drm/nouveau directory can placed inside kernel/.../drm
12:23inglor: pmoreau: I think I will probably use the printk approach for my sanity
12:24pmoreau: The second option is not that hard :-) But the first one is quite easy :-D
12:24inglor: karolherbst_work: that would make sense if I had the kernel source - then I could link the drm directory instead of the 4.6.x source drm.
12:24inglor: I'm not that comfortable with insmod etc. but editing a .c file and recompile seems easier
12:36karolherbst_work: all the work :/
12:36karolherbst_work: will be funny to deal when we know that one subdev is used by multiple nouveau devices at once
14:15RSpliet: mupuf, karolherbst_work: no feel free to redirect people to me with questions about this stuff
14:15mupuf: RSpliet: no feel free? :D
14:18RSpliet: imirkin: IMHO preemptive kernel execution, despite its high projected cost, can still be justified in the context of hard real-time systems. I might try and explain/justify my view on that at XDC in october by means of a small presentation
14:18RSpliet: mupuf: "no, feel free"
14:19mupuf: I already did, yesterday :)
14:19RSpliet: ah okay
14:19mupuf: and what does "no" refer to?
14:19RSpliet: "karolherbst: allthough I guess RSpliet might have a hard time now :/ "
14:20mupuf: so, what GPU are you doing full preemption on?
14:30karolherbst_work: RSpliet: but I hope otherwise it is still everything alright on your end?
14:31imirkin_: RSpliet: hard RT justifies a lot of silliness :)
14:49imirkin_: mupuf: do let me know if you get that nv40 up and running on blob
14:51mupuf: imirkin_: yop
14:51imirkin_: but also don't kill yourself over it :)
14:51mupuf:got stuck on CHIP yesterday. I ordered most of the components I will need for making the new wtrpm (in prevision for more machines that I will install)
14:51imirkin_: i'm sure i'm like the last person with a pre-nv50 and up-to-date distro
14:52mupuf: and... that will include an external watchdog
14:52mupuf: because piglit does kill the machines sometimes
14:52imirkin_: you mean ... sometimes piglit doesn't kill the machine?
14:52mupuf: depends on the machine :p
14:53imirkin_: depends on whether -1 is used or not
14:53mupuf: yeah, I use it
14:53mupuf: we are working on image validation now over here. It would be done if only rendering did not change every time we re-render a frame
14:54mupuf: only a few benchmarks suffer from this though :s
14:54imirkin_: i assume most do
14:54imirkin_: they include a time-based component
14:54mupuf: only valley so far, and not on all mesa versions
14:54mupuf: volplosion is pixel accurate
14:54imirkin_: so depending on system load and phase of the moon, things might show up a little differently
14:54mupuf: so much that we decided to just hash the image
14:55mupuf: so, suddenly, you need to quantify the variance
14:55imirkin_: with an apitrace that shouldn't happen though
14:55mupuf: we came up with something, we'll see how it turns out
14:55mupuf: nope, it still does :D
14:55imirkin_: then you're in serious trouble
14:55mupuf: well, that means you need to have an adaptable threshold ... like performance
14:56mupuf: we used an internal tool to generate trimmed traces
14:56mupuf: so we got one frame per scene for the major benchmarks
14:56imirkin_: no, it means your rendering has serious issues
14:57imirkin_: afaik it should be deterministic
14:57mupuf: well, with image load store and atomics, the order of the execution of threads starts being important
14:57imirkin_: ok yeah, that's annoying
14:57mupuf: blending could yield the same issue before
14:58imirkin_: i thought that was deterministic
14:58mupuf: well, depends if the ordering of the vertices is constant or not
14:58mupuf: but on some architectures, like nvidia, there is a crossbar to distribute the load
14:58imirkin_: in an apitrace it should be :)
14:58mupuf: I was talking about the hw :p
14:58imirkin_: anyways, i guess i dunno
14:59imirkin_: i thought it was supposed to be deterministic
14:59mupuf: but yeah, we are not talking about enormous differences
14:59mupuf: but they are present
15:00imirkin_: btw, apitrace has a diff-images mode
15:00imirkin_: you can see what it does
15:00imirkin_: and how it computes similarity
15:00mupuf: something like 20 pixels with about a difference of 3 on one or more components
15:00mupuf: Sure, IIRC, it was doing RMSE
15:00mupuf: it is quite standard
15:00imirkin_: E? error?
15:00mupuf: we are still using the internal tool for now
15:01imirkin_: i've only heard it referred to as "rms"
15:01mupuf: Root Mean Squared Error
15:01mupuf: when we have a good architecture, I will add support for apitrace
15:01imirkin_: yea. i guess "error" is kind of implicit :p
15:01mupuf: but since triming is ... lacking...
15:01mupuf: it is almost useless
15:02mupuf: but I can use the internal tool to trim the traces and then apitrace the result
15:02imirkin_: yeah, would be cool if someone would fix apitrace trim
15:02mupuf: or I can use the C-file writer
15:02imirkin_: will require someone with solid GL knowledge
15:02mupuf: and just delete the frames I do not want
15:02imirkin_: you can do that with trim
15:02imirkin_: the issue is hwat happens when the frames have things later frames need
15:02mupuf: yeah, except it never works, even when there are no dependencies
15:03mupuf: at least, I never got it to work :s
15:03imirkin_: k, wtvr
15:03imirkin_: i probably wanted it more, since i didn't have some clever internal tool to fall back on
15:03mupuf: what benchmarks did you use? That could be a good case study?
15:03imirkin_: none... it was for trimming random traces from various bugs
15:04imirkin_: so that i didn't have to wait 10 minutes before knowing if i'd fixed it or not
15:04mupuf: right :D
15:04imirkin_:is lazy and impatient
15:04mupuf: well, if you have such traces, I would love to get holds of them
15:04mupuf: that could be used for regression testing
15:05imirkin_: the whole apitrace diff-images thing is pretty great
15:05imirkin_: coz it runs 2 glretraces with diff parameters
15:05imirkin_: and then compares the images in-memory
15:05imirkin_: no need to do the expensive disk write
15:05mupuf: oh, yeah, sweet
15:05imirkin_: and only writes stuff out when there's a difference
15:05imirkin_: er, it's not called diff-images
15:05imirkin_: hold on
15:07mupuf: https://github.com/apitrace/apitrace/commit/661f2cfe53303dd60676e7fd0b25440be80d6644 ---> yeepee! That means I can render images using GBM!
15:08mupuf: very good!
15:08mupuf: so, what parameters can you change for the diff?
15:08mupuf: using two different mesa versions?
15:08imirkin_: i just stick a LD_LIBRARY_PATH in for one of them
15:08imirkin_: there's a "src" and "ref", and you can do --src-env and --ref-env
15:09mupuf: nice :)
15:09imirkin_: you can also pass in diff glretrace params, but i've yet to find that useful
15:09imirkin_: normally i pass in DRI_PRIME for one, to compare nv50 and nvc0 :)
15:09imirkin_: that's how i discovered the alphatest issue
15:10mupuf: I see :)
15:10mupuf: Yeah, I do not have anything to compare between GENs
15:10imirkin_: or rather ... that it mattered in practice
15:10mupuf: or chuipsets
15:10imirkin_: i think i knew about it before - piglits failed and whatnot
15:10imirkin_: but i had kinda forgotten about it
15:10imirkin_: and alphatest is a legacy feature, gone in core
15:11mupuf: yeah, sooooooo useful :D
15:11imirkin_: so it was very surprising to see talos use it, with a R16G16 rt no less
15:12mupuf: ok, have to leave now. Be back later!
15:12imirkin_: see ya
16:13JosefR: Hi, any Tegra experts here?
16:13imirkin_: probably gnurou
16:14imirkin_: if you have specific questions, you should just ask them though
16:15JosefR: OK. I have some problems getting Nouvau and Mesa running with the Tegra K1: "gbm: Last dlopen error: /usr/lib/dri/tegra_dri.so"
16:15imirkin_: ln -s tegra_dri.so nouveau_dri.so
16:15imirkin_: (or vice-versa)
16:16JosefR: I tried this, but this runs into "failed to bind extensions"
16:16imirkin_: are you sure you're passing the right device to gbm?
16:17imirkin_: if you're passing /dev/dri/card0, that won't go well
16:17JosefR: How can I do this? Environmen variable?
16:17imirkin_: how are you using gbm?
16:18JosefR: I am just running the kmscube example from command line.
16:18imirkin_: ok, so kmscube is the user...
16:18imirkin_: that probably won't work out of the box
16:18imirkin_: since it wants to display and to render
16:18imirkin_: which is done with different devices on a TK1
16:19JosefR: can I define the display so gbm uses the right one?
16:19imirkin_: robclark: --^
16:20imirkin_: looks like it always wants to render with the display device
16:20imirkin_: which isn't going to work here
16:21imirkin_: iirc tagr_ had patches to hack around this situation by creating a fake-o "tegra" drm driver which redirected stuff to nouveau
16:21imirkin_: er, fake-o tegra *dri* driver, my bad
16:26JosefR: I am still a bit confused about the Tegra implementation. There is a libdrm_tegra but no tegra_dri. I also tried the libdrm_nouveau but this failed.
16:27imirkin_: there are two separate entirely unrelated GPUs on there
16:27imirkin_: one called "tegra", the other called "nouveau"
16:27imirkin_: the tegra one has a display attached to it, but no render capabilities
16:27imirkin_: the nouveau one has no displays attached to it, but does have render capabilities
16:28imirkin_: so you have to render one one but display on the other
16:31robclark: JosefR, imirkin, someone (tagr?) might have a kmscube already fixed up for separate gpu/display arrangement.. but basically you need to pass a different fd to gbm_create_device()..
16:32robclark: right now it tries to pass the display device fd to gbm_create_device(), which ofc won't work on tegra..
16:33JosefR: OK, I would be great if I could get some sample code for this
16:35imirkin_: probably https://github.com/thierryreding/kmscube
16:36JosefR: Thanks, I will try this.
17:01JosefR: What should I use for the drmOpen() call for the tegra k1? "tegra"?
17:06JosefR: Because with the modified kmscube I still get "failed to bind extensions" when using "tegra" and when using "nouveau" I get "trying to load module nouveau...success." but the drmModeGetConnector() call fails.
17:11dmj_s76: imirkin_: can you think of how the modesetting/vga mode handling differs between bios and uefi?
17:11imirkin_: some stupid vgaarb thing?
17:33ajax: presumably bios leaves the output at a dos-compatible 720x400, uefi leaves it at something like the native resolution, and either way the firmware has set up watermarks etc to just fit what was set
17:35dmj_s76: So it has different behavior booting off live image than during first boot.
17:36aaronp: ajax, it's a little more complicated than that. The GOP driver exposes a list of the available modes, and the UEFI firmware picks one "somehow". Other UEFI stuff can change the mode until someone calls ExitBootServices.
17:37aaronp: The legacy VBIOS also picks a mode "somehow", but you don't have any control over it during boot.
17:37aaronp: well, other than doing VBE modesets after the fact.
17:37dmj_s76: In bios mode, the splash screen shows 'ubuntu 16.04' as text, then the screen goes blank unless a vga mode has been set, and then you get graphical splash followed by the graphical installer/desktop.
17:37ajax: aaronp: i don't think grub normally makes any effort to pick a different mode, but yeah
17:38aaronp: What I think is funny is that the legacy boot code, which runs in x86 real mode and has serious size constraints, goes out of its way to enumerate DP 1.2 MST topology and program the port in MST mode, while the GOP driver just punts and puts it in SST mode.
17:39ajax: hah, nice
18:16rhn: hi! how to get my card chipset number?
18:17rhn: I'm trying to confirm that I'm looking at the right thing in rnndb
18:17imirkin_: lspci -nn -d 10de:
18:21rhn: thanks. what's the "value" field in nvchipsets.xml?
18:21imirkin_: give me an example? (i'm lazy and don't feel like looking)
18:22rhn: <value value="0x134" name="GP104"/>
18:22imirkin_: right. that's the value of the chipset field in mmio register 0
18:22imirkin_: which is a thing on all nv10+ gpu's
18:22imirkin_: (so, since GeForce 256)
18:23rhn: got it. it's been a while since I looked at this
18:24imirkin_: the CHIPSET field in there
18:28rhn: okay, let's see if I still remember how to get valgrind dumps :)
18:29imirkin_: search for "valgrind-mmt"
18:29rhn: I've got it downloaded
18:30imirkin_: explains how to run it
18:30imirkin_: demmt might need some adjustments to properly decode GPxxx traces
18:31imirkin_: if you provide a trace, i could have a look at some point
18:31imirkin_: but it should also be trivial to do yourself
18:31rhn: now that I think of it, I had a clone with some GK registers that I figured out a while ago... is it useful if I publish it?
18:31karolherbst: depends on the registers I guess :p
18:31imirkin_: rhn: usually yes
18:31rhn: thanks, but I will keep this work to myself :)
18:32rhn: okay, I will check if it's actually registers and not something useless and link it up
18:32rhn: I mean I'll keep the demmt adjustments :)
18:34rhn: nvm, language is difficult
18:35karolherbst: well, any help is usually welcomed
18:35karolherbst: and with usually I mean like always
18:35imirkin_: karolherbst: i think he's saying that he'll do the demmt work himself and then share it with us if he comes up with anything useful.
18:35imirkin_: and yes, language is difficult.
18:35rhn: yes, thank you
18:36karolherbst: I thought he was talking about regs he found out and source adjustments to demmt
18:37rhn: not at all - I will put it on github unless I remembered wrong and it's useless
18:37karolherbst: well useless is stuff we found out already, but everything new is important
18:38karolherbst: even if the reg itself is useless
18:38karolherbst: but knowing what is for, means we actually _know_ it is useless
18:38rhn: a lot of registers were discovered by others in parallel to me. also these were basic compute tests
18:39inglor: Just to confirm mornings checks. Running the branch stable_reclocking_kepler_v5 with the extra commit for registors correctly (ad52418a53a8196605650e38829c01989ac7e0f8) and the sensors still reports a voltage of 0.99 (on both cores) and a power of 16.76W and 17.07W (with a variable of 0.35 W).
18:40karolherbst: rhn: well even then it depends on the details, maybe one bit is interpreted differently
18:40karolherbst: inglor: mhh well, maybe 17W is fine
18:40karolherbst: inglor: it actually depends if that is 17W for one, or for both
18:41karolherbst: allthough a titan also goes way below 20W
18:41inglor: hmm the sensors reports 2 power1
18:41karolherbst: but I thought that having two cores makes a difference
18:41inglor: but different values
18:41karolherbst: because each device gets its own hwmon entries
18:41inglor: Temperature is still around 41-44 C
18:42karolherbst: inglor: do you have envytools installed
18:42inglor: no but I can do
18:43karolherbst: mhh, well doesnt matter, because I am sure it wont work anyway
18:43karolherbst: when I or mupuf find some time, we may look into reducing power consumption a little on idle gpus
18:43inglor: installing.. (building from git)
18:43inglor: k done.
18:47karolherbst: inglor: try nvapoke -c0 0x20200 0x60 27722455
18:47karolherbst: and with -c1
18:47karolherbst: and see if that changes anything
18:48inglor: as root i suppose
18:49inglor: that reduced one of them to 15
18:49inglor: yeah 15.13W and 15.48W
18:49inglor: the rest are ok
18:49inglor: ok == the same
18:50karolherbst: mupuf: ^^ seems like it does indeed work on some desktop gpus
18:50karolherbst: inglor: well, the temperature should fall by a bit
18:50inglor: yeah in some minutes
18:51karolherbst: inglor: nvapoke -c1 0x20200 0x60 27722400 disables that power saving feature completly
18:51inglor: yeah already 2 degrees now
18:51karolherbst: and with -c0
18:51inglor: so some GPUs are better without the power saving?
18:52karolherbst: no clue
18:52inglor: cat /sys/kernel/debug/dri/0/pstate still reports the same profiles and active the 07
18:53karolherbst: this feature disables clocks for gpu engines if those engines aren't in use currently
18:53karolherbst: it's part of the power/clock gating stuff
18:53karolherbst: on fermi nvidia does a lot with this reg
18:53inglor: that makes sense on the 2x core card such as mine? (or I missunderstood the gpu engines) ?
18:53karolherbst: but on kepler it seems trivial
18:54karolherbst: inglor: it does only affects if something is not in use
18:54karolherbst: and then there is a delay on activating the clock signal again
18:54karolherbst: from my tests I could not find any perf differences though
18:54karolherbst: but this is highly untested
18:54inglor: but since I just use the gpu for gnome at least 1 core can be disabled
18:54karolherbst: except by me, who has this turned on all the time
18:54karolherbst: this is not about disabling cores
18:55inglor: (i missunderstoof the gpu engines)
18:55karolherbst: well with power gating you might be able to really disables parts of the gpus for real
18:55karolherbst: but somebody would have to investigate it further
18:56inglor: interestingly the fan dropped 100RPM!
18:57inglor: I suppose it's that 2 degrees which makes a difference
18:57inglor: still far from 35-37 C where nvidia drivers idles to
18:58inglor: unless the nvidia settings lie on their thermal stuff
18:58karolherbst: they save even more power
18:59karolherbst: on my system I got to like 9W with nouveau
18:59karolherbst: where nvidia is around 8.2W
18:59inglor: yeah but how?
18:59inglor: also question to devs: why power consumption is not priority?
19:00inglor: I understand that fps is important but battery also.
19:13ajax: if i had to guess it's more than power management is even harder to reverse-engineer than rendering commands
19:21karolherbst: inglor: because these days usually your nvidia gpu is not your main one or you have unlimited power
19:22Tom^: pfft, im almost over my powerbudget on my 8pins
19:24karolherbst: on load we cant do much anyway
19:24karolherbst: except improving the compiler
19:24karolherbst: or use better paths
19:29Calinou: free software versus ecology :(
19:31ajax: patches welcome, i'm sure
19:31ajax: yes it sucks that the feature isn't there
19:32ajax: being sad about it isn't going to make it happen faster
19:32ajax: complaining about it certainly won't make it happen faster
19:32ajax: terribly sorry that this thing that cost you zero dollars to acquire isn't ideal
19:35Calinou: NVIDIA driver is also free of charge :P
19:35orbea: its not free software though
19:35ajax: and you are at liberty to use it if you'd rather!
19:35ajax: a bit hard to fix it yourself though
19:37karolherbst: nvidia aint need fixin :p
19:39ajax: odule, 0);
19:39ajax: tseng/src/tseng_driver.c: xf86AddDriver(&TSENG, module, 0);
19:39ajax: v4l/src/v4l.c: xf86AddDriver (&V4L, module, 0);
19:39ajax: vesa/src/vesa.c: xf86AddDriver(&VESA, Module, 1);
19:39ajax: shit, sorry
19:39ajax: middle mouse paste: always a mistake
19:42airlied: tseng: always a mistake
21:13mupuf: imirkin_: either you recently fixed a lot of floating point textures piglit tests recently ... or the gk20a does not support some formats: http://piglit.mupuf.org/results/kepler/html/problems.html
21:14imirkin_: i'm guessing there was some dumb issue with that piglit run
21:14imirkin_: could be a GBM thing
21:14Booti386: imirkin_: I'm testing GL context creation with EGL/nouveau, and... I'm getting a segfault in glClear(). The same code works with softpipe, llvmpipe, and even freedreno, so...
21:14Booti386: Here is the backtrace: http://hastebin.com/cimedafuya.log
21:14mupuf: imirkin_: that is one possibility
21:15imirkin_: Booti386: surprising.
21:16imirkin_: Booti386: you should have hit an assert earlier on
21:16Booti386: Oh, also I try to use a PBuffer
21:16imirkin_: apparently surface == null
21:16Booti386: But nope :)
21:16Booti386: Current read surf: 0x18530c0
21:16Booti386: Current draw surf: 0x18530c0
21:16Booti386: In my logs )
21:17Booti386: In my logs :)
21:17imirkin_: #0 update_framebuffer_size (framebuffer=0x69d338, framebuffer=0x69d338, surface=0x0, surface=0x0) at /home/guillaume/mesa/src/mesa/state_tracker/st_atom_framebuffer.c:64
21:17imirkin_: surface == null
21:17imirkin_: i dunno why the args are repeated...
21:17imirkin_: do you have a framebuffer without a depth attachment but with a stencil attachment?
21:17Booti386: Yes, here, of course, but I don't know why my surface become internally NULL :p
21:17imirkin_: it's a different surface
21:18imirkin_: it's the surface backing the zsbuf
21:18Booti386: I only have a PBuffer
21:18imirkin_: that's an EGL thing
21:18imirkin_: anyways... there's something funky going on
21:18imirkin_: someone would have to debug it
21:18imirkin_: if you're up to it, great, if not, provide repro steps and file a bug
21:19Booti386: Yes, of course :)
21:19Booti386: Tell me what to do :)
21:19imirkin_: mupuf: oh, maybe that gk20a run happened during the short period of time when glReadPixels was totally fubar on nouveau
21:20mupuf: we'll see, I am trying to run on mesa 12.0.0
21:20mupuf: to keep it up to date
21:20mupuf: and we will be able to compare
21:26Booti386: Oh, I see, a couple of line before... Well, I don't have any stencil attachment...
21:26imirkin_: mupuf: ok
21:27Booti386: And... Why doesn't it crash in the if ?!
21:28Booti386: Oh, strb->surface is NULL, not strb
21:30mupuf: imirkin_: this one may be more of interest to you: http://piglit.mupuf.org/results/tesla/html/problems.html
21:30mupuf: I thought g80 would be much worse
21:30imirkin_: i saw it
21:30imirkin_: nah, G80 is mostly ok in piglits
21:41imirkin_: and i have some patches to help in the bias situation
21:41imirkin_: but they're not quite right
21:41imirkin_: the problem is that the hw doesn't support what's necessary
21:41imirkin_: s/bias/sampler lod bias/
21:42imirkin_: and apparently 3d textures have various assorted troubles...
21:49Booti386: imirkin_: It's failing for the depth attachment, in fact
21:49Booti386: A compiler optimisation killed the duplicate code
22:02Booti386: Do I need to explicitely request a pbuffer with a depth buffer? And how...?
22:05Booti386: If I remove GL_DEPTH_BUFFER_BIT from glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);, it "works"...
22:22ajax: Booti386: you ask for a depth buffer on a pbuffer by creating it against an fbconfig that has non-zero depth buffer bits requested.
22:22Booti386: Yes, it's what I do :(
22:22ajax: well then nouveau is just busted somehow
22:24ajax: not sure why, though. i'd imagine the code to handle that would be mostly in gallium so would be the same as on freedreno
22:26imirkin_: Booti386: if you want me to look at something, i'll need repro steps. i know exactly 0 about egl
22:26imirkin_: (in a bug... i'm about to head out)
23:14Booti386: imirkin_: http://www.megafileupload.com/s8o2/egl-test.tar.gz
23:17Booti386: Sorry for the lag :)