00:13 mupuf: imirkin: Ah ah, ok. Thanks,
01:34 haagch: gnurou: well it uses nyan-blaze instead of nyan-big from mainline linux. how should the gpu entry look like?
01:38 imirkin: haagch: you have CONFIG_NOUVEAU_PLATFORM enabled right?
01:40 imirkin: haagch: it seems like the gpu is disabled in all the tegra124 dts configs except for jetson-tk1 and venice2
01:40 imirkin: what's missing is a vdd-supply line i believe
01:41 imirkin: basically you need a VDD_GPU regulator and hook it up to vdd-supply. no idea where to get it from.
01:41 imirkin: oh wait, it's defined for nyan
01:43 imirkin: haagch: try this, bug.... i have no idea what i'm doing. dunno if this could brick your box. you've been duly warned. http://hastebin.com/axanagolol.diff
01:44 imirkin: you could ask in #tegra
01:49 haagch: hm, this seems to be something to experiment with https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/3cc8122478fe708dc874dd3af17af98a970b2f3f/arch/arm/boot/dts/tegra124-nyan.dtsi
01:54 haagch: https://raw.githubusercontent.com/torvalds/linux/master/arch/arm/boot/dts/tegra124.dtsi is status = disabled a problem?
01:57 haagch: http://lists.freedesktop.org/archives/dri-devel/2014-September/069101.html hm..
01:58 haagch: maybe i'll do, thanks for the tip
02:51 karolherbst: haagch: so you found your problem?
02:57 chille: I have multiple graphic cards in my computer. Is there any way to tell nouveau to only use one of them?
03:08 imirkin: chille: you can use the stub pci driver to bind to them, which will make nouveau unable to bind to them
04:11 gnurou: haagch: the nyan-blaze .dts file does not have a GPU node - have a look at the one in tegra124-jetson-tk1.dts for a reference
04:14 gnurou: haagch: the only change you will have to do is vdd_gpu, but the device providing it is apparently not defined in tegra124-nyan-big.dts
04:14 gnurou: haagch: ah and also please add status =
04:15 gnurou: haagch: ah and also please add 'status = "okay";' to the gpu node, since the Nyan's bootloader will not enable the node by itself
04:16 gnurou: haagch: ah, and vdd_gpu is defined in tegra124-nyan.dtsi! Just add the right label to the node named "+VDD_GPU_AP"
04:17 gnurou: with these changes, the GPU should be probed and even work, if your Mesa is recent enough and you have modified your DRM apps to work with render nodes
04:18 gnurou: haagch: oh and if it works, please send a patch upstream the enable the GPU node :)
04:19 gnurou: (and of course I'm barely repeating what imirkin said above)
04:19 imirkin_: :)
04:19 imirkin_: but unlike me, you know what you're talking about
04:20 imirkin_: it _is_ funny that we both went through the same stages of
04:20 imirkin_: "damn, no vdd_gpu"
04:20 imirkin_: "oh look! it's defined"
07:10 RSpliet: mwk: have you ever attempted to find out more about the falcon pipeline? reckon it's just a simple 3/4-stage pipeline?
07:10 mwk: RSpliet: never tried
07:11 mwk: but I recall someone once tried figuring out some timing information
07:11 mwk: what do you want that for?
07:12 RSpliet: oh mostly just curiousity... it's hardly a critical path, but curious about whether one should hand optimise for RAW stalls on registers or the like
07:13 mwk: no idea
07:13 karolherbst: RSpliet: maybe it would be promising to optimize the memory optimizations in general
07:13 mwk: if you really want to figure that stuff out, I invite you to mess around with the perf counters...
07:13 karolherbst: RSpliet: Tom^ saw has some flickering while reclocking and I also heard this from others
07:13 karolherbst: no idea where this comes from though
07:13 RSpliet: karolherbst: on Kepler, it's not synchronised with vblank
07:13 karolherbst: ahhh okay
07:14 RSpliet: on pre-kepler, it only synchronises with the vblank of the monitor with the highest res
07:14 karolherbst: that explains why
07:14 karolherbst: so has the driver to do that then?
07:14 RSpliet: there's a function in the PMU microcode that does the sync
07:14 RSpliet: but the real way forward is figuring out how the line buffer works
07:15 karolherbst: that would also fix those rare screen corruptions I assume
07:15 RSpliet: so that taking memory off-line doesn't starve the stream of pixels towards the scanout logic
07:16 RSpliet: those corruptions are more likely caused by not properly pausing the render pipeline prior to changing the memory clock
07:16 RSpliet: or the copy engine, or whatever needs to be paused, I know very little about the specifics there
07:16 karolherbst: k
07:17 RSpliet: mwk: not quite sure how commited I'd be... thanks though :-)
07:17 karolherbst: anyway I was thinking about optimizing the pmu code a bit regarding memory reclocking, no idea if it helps with anything though :/
07:18 RSpliet: what do you want to improve?
07:19 karolherbst: just the whole nvkm_pstate_prog thing somehow
07:19 karolherbst: and I think memory reclocking takes the most time, because there are two pmu requests
07:20 RSpliet: the avg. vblank period is 500μs, the average reclock takes about 100μs at most, so we're well within timing constraints for single-monitor set-ups (except some high-res reduced-vblank units). I'd personally regard PMU code perf optimisations as "non-critical, no visible impact"
07:21 RSpliet: don't feel obliged to follow my advice, but if you want to have a bigger impact, the points I raised wrt. sync-to-vblank on kepler and line buffer are probably more rewarding :-)
07:22 karolherbst: yeah, it was just a thought I had yesterday in the supermarket :D
07:22 karolherbst: I can't connect any displays to my gpu anyway, so I can't test neither of those
07:23 RSpliet: (ftr. I was curious about falcon because I'm interested in understanding the context switching overhead a bit better. I'm merely curious how big the firmware execution overhead is, but judging by the code it seems negligible)
07:23 karlmag:gives karolherbst a few display cables... :P
07:23 karolherbst: well... :D
07:23 karolherbst: RSpliet: no idea, but I doubt we can do more then 100 per second
07:24 karolherbst: mhh maybe 1000 at most
07:24 RSpliet: context switches? I have reports of it taking about 10μs, curious what that breaks down into
07:24 RSpliet: (that would be in the semi-hypothetical case of a full preemptive context switch, so including local mem and register file. I don't think nouveau does that :-))
07:25 karolherbst: no I meant round trips. I have a really trivial function in perf which just reads some memory out and returns it
07:25 RSpliet: round trips to what?
07:25 karolherbst: host => pmu => host
07:26 RSpliet: oh, if that includes a full memory reclock, it's limited by the refresh rate of your monitor on pre-kepler... guess why ;-)
07:26 karolherbst: no, just reading stuff out
07:26 RSpliet: hmm, that doesn't sound quite right, but even that should be good enough
07:27 karolherbst: mhh I just did 100 requests.. with cat overhead; 0m0.080s
07:27 karolherbst: that includes interrupts on the host and pmu and everything
07:27 RSpliet: how? using a little envytools program?
07:28 karolherbst: current_load interface
07:28 karolherbst: https://github.com/karolherbst/nouveau/blob/pdaemon_counters/drm/nouveau/nvkm/subdev/pmu/fuc/perf.fuc
07:28 karolherbst: perf_load:
07:28 karolherbst: it isn't really doing much as you see
07:29 RSpliet: right, what I mean is, using nvapeek/nvapoke incurs quite a bit more overhead than a kernel nvkm_rd32 in the kernel
07:29 karolherbst: right
07:31 karolherbst: I don't know if 1500 requests per second is good or bad though, I think it will be enough and depending on what we do on the pmu it might be more or less in the end
07:36 RSpliet: I do recall that register reads/writes from PMU are notoriously slow and there's very little we can do about that
07:36 RSpliet: there's no need for a high-speed interface there :-)
10:30 karolherbst: imirkin: do you have some knowledge about the gallium API in general? I need a way to check if there is hwmon support for the currently used gpu. for example I could check for a hwmon directory inside "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0", but I would need such path somehow before I can check
10:33 hakzsam: karolherbst, you should create a new file, for example hud_sysfs.c in src/gallium/auxiliary/hud
10:34 imirkin_: karolherbst: what are you trying to do?
10:34 karolherbst: imirkin_: add gallium_hud entries for power consumption
10:34 karolherbst: and maybe other stuff too
10:34 karolherbst: but mainly power consumption
10:34 karolherbst: and maybe also current clocks
10:34 karolherbst: but that can wait
10:34 imirkin_: soooo
10:34 imirkin_: hmmm
10:35 karolherbst: idea is to get data per frame
10:35 karolherbst: to debug dynamic reclocking
10:35 hakzsam: karolherbst, okay, so forgot what I said... because it's nouveau related
10:35 karolherbst: and benchmark it
10:35 hakzsam: karolherbst, have a look at what radeon does
10:35 imirkin_: the driver is the only thing that knows the fd
10:35 hakzsam: they already expose temp, etc
10:35 karolherbst: hakzsam: hwmon isn't nouveau related
10:35 imirkin_: from an fd you can find out what it is
10:35 imirkin_: i think.
10:35 karolherbst: hakzsam: through the sysfs-hwmon interface?
10:35 imirkin_: although i dunno if there's a good way to go from /dev/dri/renderD128 to something more useful
10:35 hakzsam: karolherbst, which gpus use hwmon?
10:36 karolherbst: nouveau does?
10:36 karolherbst: any why shouldn't they
10:36 hakzsam: nouveau is the only one?
10:36 karolherbst: hakzsam: the idea I have is, power consumption, temperature, maybe voltage could be just exposed on the kernel side through hwmon
10:37 karolherbst: and mesa could just read from that
10:37 karolherbst: then it is less code in mesa
10:37 karolherbst: and other tools can use it too
10:37 karolherbst: why having non hwmon code paths for that at all?
10:37 karolherbst: I don't see the point in doing it any other way, so I am a bit confused why there is no hwmon support for radeon even if they expose temperature
10:38 hakzsam: if other drivers use it, I think this should be in hud_sysfs.c or something like that
10:38 karolherbst: yeah, I know, but I need the path of the device inside sysfs
10:38 hakzsam: karolherbst, did you already expose these information through hwmon?
10:38 karolherbst: nouveau does
10:39 karolherbst: temperature and voltage (since 4.5) and power consumption is WIP
10:39 hakzsam: ah right
10:39 karolherbst: but temperature since I can remember
10:39 karolherbst: hakzsam: https://gist.github.com/karolherbst/67f17bd5b4c75eef0de0 ;)
10:39 hakzsam: yeah I remember now :)
10:40 karolherbst: ohh right I wanted to ask nvidia if they would tell use how to get the actual memory voltage :)
10:41 hakzsam: well, I don't know how to get that path, ask on #dri-devel
10:42 imirkin_: i just did :)
10:44 karolherbst: yeah I also added why we need that kind of information :D
10:44 karolherbst: imirkin_: the pipe_screen is created from the render node?
10:44 imirkin_: there's a nouveau_device which has a fd in it
10:44 karolherbst: I have no clue how that thing works completly, so
10:44 karolherbst: ohh
10:44 imirkin_: but i dunno how to go from that fd to the device it is
10:45 imirkin_: i mean you can find out that it's /dev/dri/renderDxxx
10:45 imirkin_: but... what to do with that
10:45 karolherbst: I would like to have a non hacky way :/
10:45 imirkin_: i don't even know of a hacky way.
10:45 imirkin_: i suspect udev knows... somehow
10:45 karolherbst: imirkin_: I bet we could ioctl some pci stuff
10:46 karolherbst: yeah
10:46 karolherbst: udev knows
10:46 karolherbst: ohh wait
10:46 karolherbst: yeah I think I know
10:46 imirkin_: udevadm info /dev/dri/renderD129
10:46 imirkin_: E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD129
10:46 imirkin_: how does it know?
10:46 karolherbst: yep
10:46 karolherbst: because /dev is created and managed by udev
10:46 karolherbst: well not created
10:46 karolherbst: but populated
10:48 karolherbst: but what about systems without udev?
10:50 karolherbst: imirkin_: how do I get that fd?
10:50 karolherbst: pipe_context->priv ?
10:50 karolherbst: and priv is some nouveau_ struct?
10:50 imirkin_: pipe_context has no data in it
10:50 imirkin_: there's a nouveau_context that wraps it
10:50 imirkin_: and has a nouveau_device in it (iirc)
10:50 imirkin_: which in turn has a fd
10:51 karolherbst: mhh
10:51 karolherbst: struct nouveau_device *dev = nouveau_screen(pscreen)->device; ahh
10:51 karolherbst: pscreen is pipe_screen
10:51 imirkin_: yes.
10:52 karolherbst: good, at least I can stick to pipe_screen for now
10:59 haagch: so i've made the changes https://gist.github.com/ChristophHaag/a73abd0743c2f6d2a870 and now nouveau gets loaded and /dev/dri/renderD128 gets created
10:59 imirkin_: haagch: nice!
10:59 imirkin_: is nouveau happy (check dmesg)?
10:59 haagch: kmscube doesn't seem to work, but the patched X works
11:00 haagch: Gallium 0.4 on NVEA
11:00 haagch: thanks guys
11:00 imirkin_: yeah, kmscube won't know it has to render on one device and display on another
11:00 imirkin_: haagch: if you're interested, i have a patch for ETC2 and ASTC support
11:01 imirkin_: which the GK20A has but none of the other GPUs do
11:01 imirkin_: and since mine tends to turn off after like 5 minutes, i've had a hard time testing it
11:01 haagch: you can run it as kmscube /dev/dri/card0 /dev/dri/renderD128 and kmscube /dev/dri/card1 /dev/dri/renderD128
11:02 imirkin_: ah ok
11:02 imirkin_: and that still didn't work?
11:02 haagch: both say "no connected connector!" and then "failed to initialize DRM"
11:02 imirkin_: so you *probably* want kmscube /dev/dri/card0 /dev/dri/renderD129
11:02 imirkin_: card0 is probably the tegradrm, card1 is nouveau
11:03 imirkin_: renderD128 = card0, renderD129 = card1
11:03 haagch: there is only the 128 render node
11:03 haagch: but 2x card and 2x control
11:04 haagch: and the patched X is hardcoded to open /dev/dri/renderD128
11:04 imirkin_: ah ok.
11:04 imirkin_: tegradrm must not create a node at all
11:04 karolherbst: imirkin_: where does nouveau_device come from? libdrm?
11:04 imirkin_: a render node, that is
11:04 imirkin_: karolherbst: yes.
11:04 imirkin_: karolherbst: check winsys/nouveau/something.c
11:45 karolherbst: imirkin_: is there a good way how to rebuild every required file after I modified the compile flags in those .am files? (after calling configure again)
11:46 imirkin_: yeah. make clean; make :)
11:46 imirkin_: tbh this should Just Work. but mesa does something wrong. i don't hit this often enough to care.
11:46 imirkin_: i think mesa doesn't use a config.h.in or something
11:47 karolherbst: mhh
11:47 karolherbst: I don't think config.h.in is at fault here
11:47 imirkin_: although that would have the effect of just rebuilding everything anyways
11:47 karolherbst: because I onhly add the udef stuff to gallium/aux
11:47 karolherbst: yeah
11:48 karolherbst: anyway, I do something wrong :/
11:48 karolherbst: imirkin_: shouldn't that be enough? https://gist.github.com/karolherbst/03ef488f2ede90258cfa
11:48 karolherbst: I get linker errors for d3dadapter
11:50 karolherbst: or do I have to add $(LIBUDEV_CFLAGS) everywhere in gallium now?
11:50 imirkin_: you should just add it to GALLIUM_CFLAGS or something
11:50 karolherbst: ohh okay
11:50 imirkin_: also you forgot about LDFLAGS
11:51 karolherbst: find ../src/ -iname "*.am" -type f -exec grep UDEV {} + only told me about CFLAGS in ../src/loader/Makefile.am
11:51 karolherbst: ohh I check the wrong files
11:54 imirkin_: might be _LIBS, i forget offhand
11:54 karolherbst: now it works
11:54 imirkin_: ok :)
11:54 karolherbst: Automake.inc
11:54 karolherbst: GALLIUM_COMMON_LIB_DEPS needed $(LIBUDEV_LIBS)
11:54 imirkin_: cool
11:55 imirkin_: iirc emil split it up into a bunch of diff files coz of the various build systems
11:55 karolherbst: I like how it doesn't work at all anyway
11:55 karolherbst: I mean running anything with it
11:55 imirkin_: and the desire to share between autoconf, android, and scons
11:55 karolherbst: yeah makes sense
11:56 karolherbst: yeah well, udev_device_new_from_subsystem_sysname doesn't found :/
11:56 karolherbst: I guess I forgot it somewhere else
11:56 karolherbst: will try make clean first
11:57 karolherbst: imirkin_: but it is easy with udev, pretty easy
11:58 imirkin_: this stuff is usually pretty easy to figure out
11:58 karolherbst: u = udev_device_new_from_subsystem_sysname(udev, "dri", "render129"); then udev_device_get_syspath(u); :)
11:59 karolherbst: thing is, I don't think we should depend on udev here in the end if there is a better solution :/
11:59 imirkin_: it's not great... you would definitely want it moved off to the side
11:59 imirkin_: and made optional
12:06 karolherbst: imirkin_: fd is -1 :/
12:07 imirkin_: doh
12:08 karolherbst: I guess print_help is called a bit too early :/
12:08 karolherbst: hud_create calls it
12:13 karolherbst: imirkin_: hud_create is called inside XMesaCreateContext somewhere at the end
12:15 karolherbst: any other idea?
12:31 karolherbst: ohh I have to used drm not dri :/
12:38 haagch: so nouveau works fine even when playing "heavy" games like tesseract, but switching in kwin5 to xrender compositing immediately locks up everything
12:38 haagch: is that warning in dmesg a problem? https://gist.github.com/ChristophHaag/5320c30299134ead55ef
12:39 imirkin_: ooh, something in tegra
12:39 imirkin_: i guess they're having trouble sharing buffers? i dunno =/
12:40 haagch: it's the Gnurou/nouveau module by the way, not mainline
12:41 karolherbst: haagch: xrender won't use the "fast" part of the tegra
12:41 karolherbst: but the drm module
12:42 karolherbst: imirkin_: xrender is plain X draw calls right?
12:43 imirkin_: karolherbst: i mean... X calls using the RENDER extension
12:43 karolherbst: ohh image compositing
12:43 imirkin_: karolherbst: but he's using GLAMOR
12:43 imirkin_: so... deep down inside it's GL
12:43 karolherbst: yeah I know
12:44 karolherbst: thing is, the stack showed tegra_gem_set_tiling which is part of tegra_drm
12:44 karolherbst: mhhh
12:44 karolherbst: haagch: might want to try out xrender without glamor?
12:44 haagch: probably because https://github.com/Gnurou/xserver/commit/a894e721c12c248d8fb5d497a8be9d3f14193ebb#diff-769941114790dcd63a67cb35271ac8adR175
12:45 karolherbst: ahhh
12:45 karolherbst: seems like that ioctl(drmmode->fd, DRM_IOCTL_TEGRA_GEM_SET_TILING, &args); fails
12:45 karolherbst: haagch: do you see a line with "failed to set tiling parameters" in the x log?
12:46 karolherbst: but this happens much earlier
12:48 haagch: no
13:46 karolherbst: imirkin_: https://gist.github.com/karolherbst/a2fb9273559c353bd74d
13:46 karolherbst: I hope there is something easier than this possible :/
13:49 karolherbst: at least it prints "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon2" for me
13:50 imirkin_: wtf is fts.h?
13:50 karolherbst: fts(3) ;)
13:50 karolherbst: I think it is linux specific though?
13:51 karolherbst: it's there to traverse directories
13:51 karolherbst: ohh it is 4.4BSD
13:53 karolherbst: anyway I would hope there would be an easier way to tell if we have a subdirectory inside a directory which isn't either . or .. :/
13:59 imirkin_: never heard of it
14:00 karolherbst: do you know any other way to check if there is a directory like hwmon%i inside hwmon ?
14:01 karolherbst: udev returns /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD%i and then we have to check if /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon and /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon%i exists
14:04 karolherbst: anyway, I checked, radeon also exports stuff through hwmon
15:52 mupuf: boring ... no performance change for xonotic quality setting low on nvd9 for mesa in the past year
15:52 mupuf: which suggests that it is likely heavily memory-limited
15:52 mupuf: or that no-one touched the compiler
15:53 mupuf: the biggest performance dip was ... 0.6% and it went back to the original speed pretty quickly, which may suggest that it was just something in the background
15:54 imirkin: mupuf: check against master too?
15:54 imirkin: i pushed a few opts post-11.1
15:55 mupuf: yes, it was master
15:55 imirkin: mostly minor things
15:55 glennk: xon is most likely heavily fill limited on those lower end cards
15:55 mupuf: tested the performance every week
15:55 imirkin: but... 0.5% here, 0.5% there, who knows
15:55 mupuf: in the past year
15:56 mupuf: the final reading is 0.05% faster than the first one, one year ago
15:56 mupuf: so... USELESS!
15:56 imirkin: ;)
15:56 mupuf: Just need to try other benchmarks :p
15:56 mupuf: but it is so prone to ... crashing
15:56 mupuf: which makes it a great platform to implement watchdog support!
15:56 imirkin: always looking on the bright side...
15:57 mupuf: yop!
15:57 mupuf: it has always been unstable
15:57 mupuf: on this machine
15:57 mupuf: the other nvd9 I have is super stable
16:00 mupuf: imirkin: http://fs.mupuf.org/mupuf/nvidia/nvd9_xonotic.html
16:00 mupuf: I am still working on this new visualisation, and the details view is useless right now in this single-report mode
16:00 mupuf: I am improving other stuff right now
16:01 mupuf: but the environment is working pretty well, aside from the fact I forgot to install packagekit which means that I have no versions for the distro-provided libs
16:01 imirkin: mupuf: that's cool... careful with that auto-adjusting scale
16:01 imirkin: it's pretty misleading
16:01 mupuf: in the details? Definitely
16:01 imirkin: no
16:01 imirkin: the trends
16:01 imirkin: it ranges from 100 to 99.4
16:01 imirkin: instead of, say, 50 to 100
16:02 imirkin: or something else like that
16:02 mupuf: right, well, I could set a minimum for sure
16:02 imirkin: also... percents are non-linear
16:02 imirkin: 100 - 50 = 50, but 200 - 100 = 100
16:02 imirkin: even though it's the same 2x change
16:02 mupuf: it is not an issue usually when you have a lot of benchmarks
16:03 mupuf: yep, there is already support for chosing the unit
16:03 mupuf: ms, fps, %
16:03 mupuf: you just need to re-generate the report with different parameters
16:04 imirkin: i don't think you understood my point
16:04 mupuf: oh, and I forgot to give the cgit freedesktop URL so as it could point us to the commit
16:04 mupuf: I do
16:04 imirkin: my point is that... let's say you have one change which halves the perf
16:04 imirkin: and one which doubles
16:04 imirkin: the distance to the 100% line will be 2x bigger for the doubling change than the halving change
16:04 mupuf: what you want is ms as a unit
16:04 mupuf: ms/frame
16:04 imirkin: using ms, or fps, or anything else -- that will have the same issue
16:05 mupuf: I mean, having ms/frame as a unit on the side, not as a basis for computing the % of the target
16:05 imirkin: the issue isn't one of units, it's of scale
16:05 imirkin: in case it's not clear, i'm suggesting you use a log scale
16:07 mupuf: does not sound like a too-bad idea
16:07 imirkin: it doesn't really matter as much since 1/1.05 is basically == 0.95
16:07 imirkin: but for bigger changes it matters more
16:08 mupuf: definitely don't want to go to type only, no-one agrees on what should be done, so I just give options. However, this is a very strong argument for the default
16:08 imirkin: perhaps the big changes just almost never happen
16:08 imirkin: and so the more direct view is clearer to everyone, dunno
16:08 imirkin: but at least make a log option :)
16:08 mupuf: right
16:09 mupuf: imirkin: how do you like the environment part?
16:10 mupuf: Clicked on the + yet?
16:10 imirkin: mupuf: perhaps make the plus "cursor:pointer"? :)
16:11 mupuf: yop
16:11 imirkin: everything else looks clickable *except* the plus
16:11 mupuf: you can click on the text too
16:11 mupuf: it works just the same
16:11 imirkin: i like it
16:11 mupuf: What I wanted was a treeview in a table....
16:12 imirkin: you can get that
16:12 imirkin: mupuf: for example (from a quick googling...) http://ludo.cubicphuse.nl/jquery-treetable/
16:13 mupuf: yeah, I tried avoiding it
16:13 mupuf: I guess I should just give in
16:13 mupuf: I am using only css3 for the tables right now, but they look like shit for sure
16:14 imirkin: use js. it's fun. http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.js
16:14 mupuf: but you know what, it is ok because I am merely writing the core of the tool, the engineering team will take the visualisation as a prototype and make it nice ... hopefully :D
16:15 mupuf: Ah ah, I do not consider webdev fun :D
16:15 mupuf: too much to learn before I can enjoy myself :D
16:15 mupuf: and seriously, I don't care that much about it :p
16:16 imirkin: :)
16:16 imirkin: life's too short for javascript?
16:16 mupuf: sounds about good :D
16:17 mupuf: also, you can show only the benchmarks you want to see on the trend line and details
16:17 mupuf: but since there is only one, that's pointless :D
16:17 mupuf: I will ask karol for more benchmarks tomorrow
16:18 mupuf: and I should add a big warning that packagekit is not installed too, that would help!
16:18 mupuf: anyway, bedtime
16:18 mupuf: in the end, the only thing useful the tool did was ... bisecting the compilation failures
16:18 mupuf: hurray
16:18 mupuf: wonderfu
16:19 imirkin: heh
16:19 mupuf: it is funnier on intel, performance is a joyful rollercoaster :p
16:19 imirkin: on the bright side - no perf drop :)
16:19 mupuf: yep!
16:19 mupuf: but to be fair, the gpu is ... underclocked
16:19 imirkin: yeah
16:19 imirkin: try it on a kepler?
16:19 mupuf: and we only see one bottleneck
16:19 mupuf: yeah, it will come on reator at some point
16:20 mupuf: not sure how I will keep people out when it is running though
16:20 glennk: reator2?
16:21 mupuf: glennk: well, this laptop was supposed to be one
16:21 mupuf: along with another laptop
16:21 mupuf: and the tk1
16:21 mupuf: so, I guess 4 machines should be enough :D
16:21 glennk: laptop and consistent benchmarking seems like each others antithesis
16:22 mupuf: not entirely untrue
16:22 mupuf: time will tell!
16:23 mupuf: I am working on a new system, with basic acceptance tests for performance and rendering checking
16:23 mupuf: with auto bisecting when regressing (working pretty well, even on kernels)
16:24 mupuf: but one step at a time, I will keep on working on it and come back to this experiment :)
19:09 kb9vqf: Is nouveau.pstate=1 still valid for new (Linux 4.4-ish) kernels?
19:09 kb9vqf: I don't have the pstate device node any more after upgrading from 4.2
19:29 kb9vqf: Never mind, found the new path in debugfs: /sys/kernel/debug/dri/0/pstate
19:29 kb9vqf: must have been a pretty recent change
21:10 lanteau: I'm having some issues getting an AGP GeForce 6800 Ultra (NV40) working with nouveau on linux kernel 4.4.0 with libdrm version 2.4.65
21:10 lanteau: I believe (from what I've read), the NV40 should be supported...
21:11 lanteau: I think the two most telling lines in dmesg are:
21:11 lanteau: [ 25.965156] nouveau 0000:f0:10.0: gr: intr 00100000 [ERROR] nsource 00000010 [LIMIT_COLOR] nstatus 04000000 [PROTECTION_FAULT] ch 1 [0008e000 Xorg[847]] subc 4 class 009f mthd 0308 data 04380780
21:11 lanteau: and
21:11 lanteau: [ 67.550355] nouveau 0000:f0:10.0: DRM: GPU lockup - switching to software fbcon