01:28 AndrewR: hm, on nouveau/4.3 kernel and nv43 I tried to enable pstate file and play around. But guess those lines in dmesg tell me it failed, while cat'ing file itself indicates some change?
01:29 AndrewR: "clk: failed to raise voltage: -22" and then "clk: error setting pstate 0: -22"
01:30 pmoreau: It did fail
01:30 pmoreau: Or at least for one of the clocks, maybe not for all of them
01:31 imirkin: should work on almost all nv4x's... that's odd
01:31 AndrewR: pmoreau, guess it failed, because unsynced glxgears still stay at same level ....
01:32 AndrewR: imirkin, may be some refactoring killed it
01:32 imirkin: should check what happens with an older kernel
01:32 imirkin: as for your mesa bug, ARB_buffer_storage messes up traces in the first place
01:32 imirkin:&
01:32 AndrewR: imirkin, ok, but I don't have apitrace on this machine yet ..thanks for tip, will disable it
01:38 karolherbst: imirkin: this is the infamous voltage entry not found bug, but I am surprised that this even hits tesla :/
01:38 karolherbst: ohh this is pre tesla even
01:38 karolherbst: AndrewR: do you want to upload your vbios somewhere?
01:39 karolherbst: sould be in /sys/kernel/debug/dri/1/
01:39 karolherbst: ..
01:39 karolherbst: no dri/0/
01:39 karolherbst: my mistake
01:39 AndrewR: karolherbst, I think it was already ...given. but moment will recapture and resend it
01:46 AndrewR: karolherbst, cat /sys/kernel/debug/dri/0/vbios.rom > somefile ? ls -la tells me file exactly 64000 (bytes?) big ..but my previous file from same card a bit bigger (ca't recall how I get it) - 61440
01:48 karolherbst: you have to cat it, yes
01:48 karolherbst: and ls doesn'T tell the truth :p
01:48 karolherbst: or do you mean after cating?
01:49 karolherbst: it is fine though
01:52 AndrewR: karolherbst, http://s000.tinyupload.com/index.php?file_id=30431323381406193076
01:55 AndrewR: karolherbst, http://s000.tinyupload.com/index.php?file_id=75324436202167325679 - another version ...
02:06 karolherbst: okay, the first one looks better
02:06 karolherbst: ohh wait
02:06 karolherbst: actually not
02:07 karolherbst: AndrewR: do you have envytools installed?
02:07 karolherbst: there is a tool called nvagetbios in there, you might want to run this one to get the vbios
02:10 AndrewR: karolherbst, not yet, need to clone it first
02:11 karolherbst: there may be a package
02:15 karlmag: "Can you suggest me a graphics card. Either Amd or nVidia. if nVidia, please a kepler based one." I ask the sales person (by email). "Sure; have a look at this geforce gtx 960 card"
02:15 karlmag:facepalms
02:16 karlmag: maxwell v2
02:21 karolherbst: usually sales personal has no clue whatsoever
02:22 karolherbst: or at least no deep understanding
02:22 karolherbst: karlmag: but you already know, the best kepler based card is the titan Z :p
02:23 karlmag: karolherbst: the actual question had a few more restrictions and guidelines too. Price, for example :-P
02:23 karolherbst: so I figure 200$ max?
02:24 karolherbst: GTX 760 (not 192 bit) or GTX 660 :p
02:24 karlmag: possibly a bit more
02:24 karolherbst: if you are lucky get a 760 Ti
02:24 AndrewR: karolherbst, http://s000.tinyupload.com/index.php?file_id=06606216787609935774
02:24 karlmag: I actually started asking about a specific 650 card, but they figured they couldn't provide that anymore, thus removed the page for it :-P
02:25 karolherbst: AndrewR: thanks, this vbios file seems to be okay
02:25 karolherbst: karlmag: mhhh
02:25 karolherbst: karlmag: try to get a cheap 760 Ti
02:25 karolherbst: this card is pretty fast
02:25 karlmag: okay
02:25 karolherbst: though a 4GB GeForce GTX 760 would be nice too
02:26 karolherbst: the ti one seems to be 10% faster though
02:30 nchauvet: aaronp, people are reporting issue with libvdpau-1.1.1 that are currently fixed with current git HEAD, as seen in https://bugzilla.redhat.com/show_bug.cgi?id=1266295 , would you care to make a new release ?
02:32 karolherbst: AndrewR: okay, it shouldn't fail setting the voltage :/
02:35 AndrewR: karolherbst, may be it was bug fixed in real 4.3 - I use branch from http://cgit.freedesktop.org/nouveau/linux-2.6/log/?h=linux-4.3
02:36 karlmag: hmmf... clicked in another window... everything went black.. :-P had to reboot. Always fun..
02:37 karlmag: 760 (ti) seems to be fairly unavailable around here
02:38 karlmag: actually... 760 might be
02:39 karlmag: evga geforce gtx 760 4GB
02:39 karlmag: never heard about that brand before
02:39 karolherbst: AndrewR: did you try 4.2?
02:39 AndrewR: karolherbst, not on this machine
02:40 karlmag: all encased and one fan... ... *unsure*
02:40 AndrewR: karolherbst, but I can try ...reboot obviously needed
02:40 AndrewR: karolherbst, I have pre-compiled 4.2 (with slightly different config)
02:41 karolherbst: AndrewR: should be fine, in 4.3 just a big nouveau rework landed and maybe it brake it for you
02:42 AndrewR: karolherbst, yes, this is why I compiled it ..to see how much it will broke :}
02:59 AndrewR: karolherbst, it works with 4.2 (glxgears at 1000+ fps instead of ~350). No errors in dmesg (only tried to go up to first perf level - 20: core 300 MHz shader 300 MHz memory 1000 MHz
03:00 AndrewR: karolherbst, because with higher one it tend to lock up - probably due to low-end/old PSU (power supply ...its celeron1000 assembled ..in 2001 or so)
03:06 karolherbst: AndrewR: I am pretty sure it locks up because of nouveau issue
03:06 karolherbst: which card do you have exactly?
03:23 AndrewR: karolherbst, 01:00.0 0300: 10de:00f1 - from lspci -vn
03:23 AndrewR: karolherbst, or in human-readable form: 01:00.0 VGA compatible controller: NVIDIA Corporation NV43 [GeForce 6600 GT] (rev a2)
03:24 AndrewR: karolherbst, Subsystem: XFX Pine Group Inc. GeForce 6600 GT AGP
03:24 AndrewR: karolherbst, this one need two additional power cords (same as for old PATA hdd). May be it draws too much ....
03:25 karolherbst: seems to be a GDDR3 card
03:25 karolherbst: don't think so
03:25 karolherbst: nouveau doesn't handly reclocking that well in general
03:25 karolherbst: *handle
03:25 karolherbst: nouveau might just do something wrong for your card for higher pstate
03:26 AndrewR: karolherbst, nouveau [ PFB][0000:01:00.0] RAM type: GDDR3 - at least nouveau thinks so (from dmesg)
03:26 karolherbst: there are some fixes outstanding for tesla cards (maybe they are more generic)
03:26 karolherbst: pmoreau: for which does your memory reclock issue fix apply?
03:26 karolherbst: is it tesla only or could it also effect older cards?
03:27 karolherbst: AndrewR: anyway, do you know how to bisect the kernel?
03:27 karolherbst: if you want, you could figure out which commit exactly broke your card
03:27 AndrewR: karolherbst, yes, I saw patch series on ML ..but then I need to try it on my another card in another machine (only one monitor/kbd/mouse for two of them ..in active use..few more just 'around')
03:27 AndrewR: karolherbst, yes, while here it will be not uberfast process.
03:28 karolherbst: mhh
03:28 karolherbst: AndrewR: do you use gentoo by the way? or something else?
03:28 pmoreau: karolherbst: It's Roy's fix, and I had the issue on a G96 with GDDR3
03:28 AndrewR: karolherbst, Slackware ....
03:28 karolherbst: pmoreau: yeah I know, I am just asking you because you are mostly more responsive :p
03:28 karolherbst: AndrewR: I see
03:29 karolherbst: AndrewR: I bet you know how to install a kernel module properly?
03:29 karolherbst: if so, use my branch for bisect: https://github.com/karolherbst/nouveau/commits/master
03:29 karolherbst: it is 4.2 compatible
03:29 AndrewR: karolherbst, guess I'll install it one way or another :}
03:29 karolherbst: and you don't have to care about the kernel in general
03:29 karolherbst: if the card misbehaves with my branch (which is just an older version of the rework) it is good to use
03:30 karolherbst: then you only need to bisect the nouveau bits
03:31 karolherbst: AndrewR: b54e3692c22c4bc0891c08b204544c4e4ef44179 ist the commit before the rework
03:31 pmoreau: Well... even using the kernel tree, you can restrict the bisection to the Nouveau bits
03:31 karolherbst: if master HEAD is bad and b54e3692c22c4bc0891c08b204544c4e4ef44179 is good you know what to do ;)
03:31 karolherbst: pmoreau: yes, but then you have to install your entire kernel and stuff
03:31 pmoreau: Yeah
03:32 pmoreau: But you might have to some time, if Nouveau uses some drm functions that were added or remove in some kernel version.
03:33 karolherbst: pmoreau: roy fixes seem to be nv50ü
03:33 karolherbst: nv50+
03:33 karolherbst: pmoreau: my branch works with 3.19
03:33 karolherbst: up to 4.2
03:34 pmoreau: Ok
03:34 karolherbst: RSpliet: do you know about any outstanding gddr3 nv4x issues?
03:35 karolherbst: pmoreau: I still wait for some kernel patches to be ported to 4.2, so I stick with 4.1 for now
03:36 pmoreau: AFAIK, Roy doesn't have any NV4x cards
03:38 RSpliet: pmoreau: untrue, I do in fact own an NV4B
03:38 RSpliet: there's however very little pre-NV50 cards that do memory reclocking
03:38 pmoreau: My bad
03:38 RSpliet: to a point where I believe it's simply not implemented in nouveau
03:39 AndrewR: karolherbst, cloned, now I'll play around (guess link to my kernel source in /lib/modules/$kernel_name must be accurate...for starting...)
03:39 AndrewR: karolherbst, thans for help, will try to return with some news
03:39 karolherbst: AndrewR: there are no link in /lib/modules generally :p
03:39 AndrewR: *thanks
03:40 AndrewR: karolherbst, build -> /mnt/zip0/src/linux-2.6
03:40 karolherbst: there are build and source symlinks inside the specific kernel version though, and yes, these have to point to the right
03:40 RSpliet: ah yes, no, nouveau will not touch NV40 memory timings or other parameters
03:41 RSpliet: so it's not expected to work so well
03:41 karolherbst: RSpliet: okay, I expected something like that already
03:41 karolherbst: AndrewR: if you have some time, you might want to fix gddr3 reclocking for your card :D
03:41 RSpliet: heh
03:41 AndrewR: karolherbst, yes, I meant them .... this setup a bit overcomplicated - kernel source live inside jfs formatted file on ntfs filesystem :P
03:42 karolherbst: hey, I fixed it for my card without ever doing anything for nouveau before :p (though it was a pretty lucky find)
03:42 karolherbst: so I am not asking for the impossible :p
03:42 AndrewR: karolherbst, we will see (but yes, I hope to do something ..interesting)
03:43 RSpliet: in fairness, most of it is a simplified version of NV50
03:43 karolherbst: AndrewR: in fact you only have to mmiotrace the prop driver while reclocking
03:43 RSpliet: but... the devil is in the details
03:43 karolherbst: and let nouveau do something similiar
03:43 RSpliet: someone should turn NV40 reclocking around and do it on HWSQ instead
03:44 RSpliet: but... meh, not worth it really with so little cards out in the wild
03:44 RSpliet: karolherbst: unless you want that practice round :-P
03:44 karolherbst: RSpliet: to bad, I only have a nv3x card somewhere .D
03:44 RSpliet: same story holds
03:44 karolherbst: yes, it is a agp card and no, I don't ahve a board for this
03:45 RSpliet: that's precisely why I don't think the work is worth the effort :-D
03:45 karolherbst: but I have more fun things to do :p
04:11 karlmag: karolherbst: came across a zotac gtx 650 ti 2GB. Is that a good candidate?
04:11 karolherbst: depends on how much it is
04:12 karolherbst: but usually a 660 is better
04:12 karlmag: less than $200
04:12 karolherbst: but 650 ti is good enough
04:12 karolherbst: ohh
04:12 karolherbst: mhh
04:12 karolherbst: I wouldn't pay more than 150
04:13 karlmag: Well, I have to take local vat, etc into account too. Difficult to get much below that for a 4 monitor one it seems
04:13 karlmag: the ones you've mentioned earlier today seem to be difficult to find around here
04:14 karlmag: Not even 100% sure I'll get this one, since they don't actually have it in stock.
04:15 karlmag: maybe I should try for the 660 though, just found one
04:15 karlmag: about $50 more than the 650
04:16 karlmag: scratch that.. it was removed too..
04:17 karlmag: seems like that particular netshop is purging graphics cards
04:22 karolherbst: :D
04:31 karlmag: It's a wonder I still have hair :-P
04:44 karlmag: looks like almost everything non-maxwell has been removed :-(
04:47 karlmag: mostly gtx7XX and 9XX left. Same goes for other sites it seems.. Hmmf..
04:49 karlmag: 750 it seems
05:07 karlmag: maybe I should get a 750(ti) while they still sell them :-P
05:13 karolherbst: karlmag: 750 ti is maxwell
05:13 karolherbst: first gen though
05:13 karlmag: I know
05:13 karlmag: seems difficult to get kepler cards :-/
05:13 karlmag: all of a sudden
05:13 karolherbst: why?
05:13 karolherbst: I could one in 2 or 3 days :p
05:14 karlmag: well, because all the webshops I'm looking at doesn't seem to have any?
05:15 karlmag: the one that did started purging the ones I had when I started asking..
05:15 karlmag: I.e probably not available anymore
05:15 karolherbst: karlmag: country?
05:15 karlmag: Norway
05:16 karolherbst: karlmag: how is the shipping from UK?
05:16 karlmag: a bit high, probably, then there is vat + customs charges on top of that.
05:16 karlmag: and any warrenty out the window for all intents and purposes
05:17 karolherbst: why?
05:17 karolherbst: ohh right, norway isn't EU member :/
05:17 karlmag: mmhmm
05:17 karolherbst: doesn't eu wide warrenty still applies to norway?
05:18 karlmag: dunno
05:18 karlmag: in any case the return shipping would kill the fun of it
05:18 karolherbst: right
05:19 karlmag: and also risk to have paying all the vat and charges on a replaced card
05:19 karlmag: so.... rather not.
05:19 karlmag: Guess I have to dig a bit deeper.
05:20 karlmag: The webshops I've been looking at are the biggest and most popular. I.e probably highest turnaround too
05:20 karolherbst: seems like for norway EU warrenty laws still apply
05:20 karolherbst: maybe something from finnland or sweden would be okay then
05:20 karlmag: same difference really
05:20 karolherbst: shouldn't be shipping to those countries be much cheaper and faster?
05:21 karolherbst: especially sweden?
05:21 karolherbst: it's not like the distance is bigger
05:21 karolherbst: :D
05:21 karlmag: might be slightly cheaper, but not much
05:22 karlmag: basically it's "europe" and "rest of the world"
05:22 karolherbst: mhh, I really don't think it should make any difference
05:22 karolherbst: because a shop from sweden can be neared than a shop in norway for you
05:22 karolherbst: *nearer
05:22 karolherbst: UK is just stupid because it is over sea shipping
05:22 karlmag: nope, I live on the west coast. About as far from the swedish boarder as you can get
05:23 karolherbst: ohh
05:23 karolherbst: k
05:23 karolherbst: but norway is pretty long :p
05:23 karlmag: yeah
05:23 karlmag: national shipping rates are the same no matter where in the country
05:23 karolherbst: don't know, I might have guessed it shouldn't be that expensive from sweden actually
05:23 karlmag: not that it's very cheap either, but quite a bit cheaper than international
05:23 karolherbst: because it is not big deal from norway
05:24 karolherbst: ohh I see
05:24 karolherbst: then it makes sense again :D
05:24 karlmag: karolherbst: in practice you're probably right, but the charges doesn't take actual distance into account. It's divided into zones.
05:25 karolherbst: yeah
05:25 karlmag: It costs X to ship to Y
05:25 karolherbst: that's why I thought sweden shouldn't make any big difference
05:26 karolherbst: I just thought it might be easier to find something usefull in sweden shops
05:26 karlmag: there used to be a "nordic country" shipping zone before, but not really sure it exists anymore.
05:26 karlmag: in any case, it wasn't *that* much cheaper than the europe one
05:40 karolherbst: RSpliet: I can't think of any good design for that pdaemon counter stuff :/
06:14 mdolezel: hi is there someone with t440p and with GK208M [GeForce GT 730M]? i have overheating issues.
08:17 karolherbst: uhh there is somebody with a intel 5500 and 740M :/ this is really some kind of joke
08:20 aaronp: nchauvet, really? That's weird.
08:20 aaronp: Oh, I'll bet the implicit declaration of secure_getenv() is truncating the pointer returned, or something.
08:20 nchauvet: aaronp, yep, I don't reproduce that been said
08:20 aaronp: Sure, I'll make a new release.
08:20 nchauvet: fedora 22 x86_64 (so same release)
08:21 karolherbst: aaronp: what's the problem with secure_getenv?
08:22 glennk: karolherbst, presumably it'd be the gddr5 version
08:22 karolherbst: aaronp: you know you have to copy the returned string of secure_getenv?
08:22 karolherbst: glennk: okay, that would be okayish then :D
08:24 karolherbst: aaronp: and if you do char *str1 = secure_getenv("ENV1"), *str2 = secure_getenv("ENV2); str1 and str2 may be the value of ENV2 both.
08:31 karolherbst: aaronp: it is even funier: secure_getenv("ENV1") == secure_getenv("ENV2") is allowed to be true, so can char *str1 = &secure_getenv("env")[4], str2 = &secure_getenv("long_env_name")[14]; => str1 may be "_env_name=...."
08:31 aaronp: karolherbst, the problem was that mesa_dri2.c was missing an #include "config.h", so it didn't pick up _GNU_SOURCE, so secure_getenv was implicitly declared, which means it returns int.
08:31 aaronp: So the return value was getting truncated and then sign-extended to a pointer.
08:31 karolherbst: aaronp: ohhhhh
08:31 karolherbst: aaronp: that's evil too
08:31 aaronp: karolherbst, is that true across threads?
08:32 karolherbst: the spec doesn't say anything about trhead safety :/
08:32 aaronp: I don't think libvdpau does anything with the result of one secure_getenv() call after it makes another.
08:32 karolherbst: the pointer may point to anything
08:32 aaronp: If it's not thread-safe then it can't possibly be safe to use. :)
08:32 karolherbst: pointer to a list of env name=value;... string
08:32 karolherbst: or function local static
08:32 karolherbst: getenv is never safe to be used :D
08:33 aaronp: This whole secure_getenv() thing is so stupid anyway. Who runs VDPAU apps setuid ??!?
08:33 karolherbst: maybe the prop driver does?
08:34 karolherbst: "The implementation of getenv() is not required to be reentrant. The string pointed to by the return value of getenv() may be statically allocated, and can be modified by a subsequent call to getenv(), putenv(3), setenv(3), or unsetenv(3)."
08:34 aaronp: Oh shoot, it does use vdpau_driver after it assigns vdpau_driver-path.
08:35 aaronp: I don't have time to fix this today. I'll file a bug and get someone else to do it. :)
08:35 karolherbst: ohhh "Modifications of environment variables are not allowed in multi-threaded programs. The getenv and secure_getenv functions can be safely used in multi-threaded programs."
08:35 karolherbst: I think each thread gets a copy of the entire environment
08:36 karolherbst: would make sense if you think about fork and all the stuff
08:36 aaronp: I don't really get why getenv() would modify the string pointed to by other calls to getenv(), but maybe there's a good reason for it somehow.
08:36 karolherbst: aaronp: performance
08:36 karolherbst: static char* inside the implementation
08:36 karolherbst: you don't free the returned pointer, do you?
08:37 karolherbst: so it is up to getenv to decide what the pointer points to
08:37 aaronp: Yeah, but you're looking up a string in an existing table of already null-terminated strings. Why not just return a pointer to the actual string? I could see setenv() needing to reallocate the environment but getenv()?
08:37 karolherbst: aaronp: no
08:37 karolherbst: this is implementation specific
08:37 aaronp: Right. I'm just saying the implementation seems stupid. :D
08:37 karolherbst: you don't know what getenv does internally ;)
08:38 karolherbst: yeah, somtimes performance seems to be more important for whatever reasons
08:38 karolherbst: or maybe glibc wants to make it impossible to change the pointer value
08:38 karolherbst: you could overwrite the internal string that way
08:39 karolherbst: don't know, I really dislike this interface, because it is damn easy to get it wrong
09:22 qq[IrcCity]: does a theory of CPU kernel mode ⇔ video card interaction exist? what are subdevices (of nkvm_device) and engines?
09:24 qq[IrcCity]: nkvm_device_init (in the devinit->post mode) runs a function for each subdevice. but collateral damage is seemingly too severe.
09:25 qq[IrcCity]: which namely subdevices should be present and for which operations are they in charge?
09:33 qq[IrcCity]: karolherbst suggested to sniff Nvidia’s driver (namely, its initialization sequence) under mmiotrace, but results would have mediocre value without a theory.
10:42 mlankhorst: argh, stupid thing uses xor encryption..
11:20 AndrewR: karolherbst, bisection finished .. log: http://fpaste.org/275461/ (first bad one was volt: convert to new-style nvkm_subdev )
11:20 karolherbst: AndrewR: okay, makes somehow sense, will try to find the real issue though
11:21 karolherbst: the commits are quite big
11:28 AndrewR: karolherbst, may be it was simply never called before? -// .volt = nv40_volt_new, become .volt = nv40_volt_new, at line 543
11:28 AndrewR: karolherbst, https://github.com/karolherbst/nouveau/commit/78ad904116e30a70c311a98843b3e44330611e40
11:28 karolherbst: AndrewR: no, this is fine
11:29 karolherbst: AndrewR: could you load nouveau with nouveau.debug=debug with the faulty one and paste dmesg somewhere?
11:30 AndrewR: karolherbst, yes ...
11:30 imirkin: aha
11:31 imirkin: it's wrong
11:31 imirkin: +nv40_volt = {
11:31 imirkin: + .vid_get = nvkm_voltgpio_get,
11:31 imirkin: + .vid_set = nvkm_voltgpio_set,
11:31 imirkin: that needs to be nvkm_volt_get/set
11:31 karolherbst: imirkin: sore?
11:31 karolherbst: it was nvkm_voltgpio_set before
11:32 karolherbst: https://github.com/karolherbst/nouveau/commit/78ad904116e30a70c311a98843b3e44330611e40#diff-fdd7082bb52d0d9b352cf9cc5041b534L201
11:32 karolherbst: nvkm_volt_get just calls .vid_set internally, doesn't it?
11:32 imirkin: oh oops
11:33 imirkin: but only if voltgpio_init succeeds... hm
11:33 karolherbst: though an infinite call loop might be fun in the kernel :D
11:33 imirkin: whereas now it's always set
11:33 karolherbst: yeah, maybe it was fauilty in the first place before and now it just fails
11:35 karolherbst: I think the issue may lay somewhere else, maybe the voltage parsing is just faulty for his board now
11:36 karolherbst: but mhhh
11:36 imirkin: i think _very_ few nv40 boards have voltage regulators
11:37 karolherbst: his one has
11:37 karolherbst: 2 VID gpios
11:37 karolherbst: I already checked his vbios
11:37 karolherbst: and two different voltages
11:37 karolherbst: 1.3V and 1.4V
11:37 karolherbst: one for each pstate
11:38 imirkin: hm ok
11:54 qq[IrcCity]: does anybody know how to force an X server (without terminating it) to switch off its virtual console? (i.e. to go to TUI)
11:54 AndrewR: karolherbst, http://fpaste.org/275471/
11:55 qq[IrcCity]: one of my problems (likely the most frequent one) turned out to be a deadlocked Xorg blocking VC switching, not an actual GPU lockup.
11:55 imirkin: qq[IrcCity]: chvt 1
11:56 qq[IrcCity]: imirkin: did you ever look what does the modern set_console() do?
11:56 imirkin: nope
11:57 qq[IrcCity]: there is a bit in the kernel that denies set_console().
11:59 karolherbst: imirkin: "[ 8.435532] nouveau 0000:01:00.0: volt: current voltage unknown" that explains it a bit
12:00 karolherbst: so nvkm_volt_get(volt) returns with an error
12:01 karolherbst: AndrewR: would you like to do the same with this branch? http://cgit.freedesktop.org/~darktama/nouveau/
12:01 karolherbst: not that it is something that got already fixed (unlikely, but well)
12:01 karolherbst: at least we should get improved error message there I think
12:09 qq[IrcCity]: freaking vt_dont_switch can be defeated via «ioctl( , VT_UNLOCKSWITCH)». at least it follows from reading vt_ioctl.c.
12:44 qq[IrcCity]: dammit. Xorg receives SIGUSR1 when switching VC is requested. it’s not the VT_LOCKSWITCH stuff, it’s a part of the regular switching consoles sequence.
12:44 qq[IrcCity]: and when Xorg is locked up, it won’t allow to switch its freaking console off.
13:15 AndrewR: karolherbst, http://fpaste.org/275512/ - hardly better ....
13:20 RSpliet: karolherbst: there already is a 2-way fifo in the pdaemon code to send messages to the kernel
13:20 RSpliet: and a notion of tasks
13:20 RSpliet: so... you can literally make pdaemon send a message to interrupt the kernel driver iirc
13:20 karolherbst: RSpliet: yeah, but the pdaemon counters are a bit different though
13:21 RSpliet: you should have mostly unlimited access to normal registers afaik
13:21 RSpliet: (although that could get you in trouble with hakzsam's work)
13:22 karolherbst: RSpliet: no, he uses different counters
13:22 karolherbst: even the blob only uses the pdaemon counters for load messurement
13:22 RSpliet: good
13:22 karolherbst: I already have an userspace daemon which does dyn reclocking, to
13:22 RSpliet: but thus you can write a pdaemon periodic task to measure the load... shouldn't be so hard
13:22 karolherbst: it even works with teh blob kind of
13:22 karolherbst: RSpliet: right
13:23 RSpliet: mupuf: does your temperature control code not do something very similar, or is that all userspace driven?
13:23 RSpliet:can't recall
13:23 karolherbst: ha
13:23 karolherbst: the blob does it on the cpu
13:24 karolherbst: orr wait, wrong reg?
13:24 RSpliet: idk
13:24 RSpliet: long time since I've looked at any of that
13:24 karolherbst: what does "PDAEMON.MUTEX_TOKEN" mean?
13:24 karolherbst: or do
13:26 karolherbst: RSpliet: fun fact though is, that the script also may have to take temp into account
13:26 karolherbst: we shouldn't have two seperated task for that
13:31 RSpliet: I like that thought
13:32 RSpliet: but I recall NVIDIA had some pretty rigorous measures to cut the clock in half when things were getting a bit too hoy
13:32 RSpliet: *hot
13:32 RSpliet: or further
13:32 RSpliet: anyway, mupuf knows
13:36 karolherbst: yeah
13:36 karolherbst: I checked that too
13:36 karolherbst: it is not cut in half in fact
13:37 karolherbst: and there is some calculations
13:37 karolherbst: but I like this interrupt thingy
13:38 karolherbst: I was thinking of doing anything callback based, like you can register functions, which get called when enough data was collected by the counter
13:38 karolherbst: like every 0.1 seconds or something :D
13:38 karolherbst: the thing is, I don't relly know if it is worth doing it with a pdaemon script?
13:38 karolherbst: what is the advantage of that?
13:38 karolherbst: except less latencies between reg reads
13:46 karolherbst: ohhh the blob uses two counters for memory load
13:47 karolherbst: mhhh
13:47 karolherbst: I put them together, because it kind of helped me :/
13:48 karolherbst: wow, that means the blob uses 7 out of 8 counters just for dyn reclocking :/
13:48 karolherbst: RSpliet: do you have a kepler desktop card?
13:49 karolherbst: ohh wait, nvm
13:49 karolherbst: there is one unused counter and I don't know for what the blob intents to use it for
14:35 RSpliet: very generic cycle counter for debugging purposes?
14:39 mupuf: RSpliet: talking about FSRM?
14:39 mupuf: I really need to get the code in nouveau
14:39 mupuf: and stop using the thresholds as a way to get IRQs when we overheat
14:39 mupuf: as *just* a way
14:55 karolherbst: mupuf: hi
14:55 mupuf: karolherbst: hey!
14:55 mupuf: back home!
14:56 karolherbst: RSpliet: it seems to be never used, but 7 counters in total is a lot though: 1. video encoding, 2. en/decoding 3. nothing 4. gpu core 5. memory 6. pcie 7. memory 8. total
14:56 karolherbst: one of the both memory counters can be used to detect core waitings on memory operations
14:56 mupuf: what is the difference between 5 and 7?
14:57 mupuf: total == count every cycle
14:57 karolherbst: mupuf: not really sure, I use both together and I am able to clock the memory at the right time with it
14:57 karolherbst: yes
14:57 mupuf: it actually is useless since pdaemon is never reclocked
14:57 karolherbst: I am pretty much optimized my algorithm
14:57 karolherbst: and it seems to work for 95% of all games/applications
14:58 karolherbst: mupuf: yeah I know, it is always the same
14:58 karolherbst: mupuf: currenty version of userspace daemon: https://github.com/karolherbst/envytools/commit/eac21aa2cf627f616503d176e7be3fe056d1556c
14:59 karolherbst: it is simple but effective eough
14:59 karolherbst: ohh I still have some local optimizations, but nothing big
15:00 karolherbst: newest: https://github.com/karolherbst/envytools/blob/clock_daemon/nva/nvagpuload.c
15:01 karolherbst: it is pretty difficult though to not end up in an endless reclocking cycle like 0f <=> 0a switches
15:01 karolherbst: for memroy
15:02 mupuf: karolherbst: and how do you test it?
15:02 karolherbst: running games
15:02 mupuf: yeah, right
15:02 karolherbst: look that fps is always at 60 fps
15:02 karolherbst: or highest possible
15:03 karolherbst: sometimes I stop the daemon
15:03 karlmag: what games? *curious*
15:03 karolherbst: and check if higher clocks are changing anything
15:03 karolherbst: run games at high cpu load to check if the daemon clocks down
15:03 karolherbst: stuff like that
15:03 mupuf: we'll need to set up a real rig for this
15:03 karolherbst: karlmag: linux game of my steam libary :D
15:03 karolherbst: mupuf: I know
15:04 karolherbst: brb
15:04 mupuf: we need repeatable benchmarks
15:04 karolherbst: but I just wanted to implement an idea
15:04 mupuf: sure sure
15:04 mupuf: I am sure your code works very well
15:04 mupuf: and it is a very good start!
15:04 mupuf: I am glad you rewrote it in c
15:05 mupuf: bash was a bad idea :D
15:05 karolherbst: you can test if you want :D
15:05 karolherbst: you just need to adust like every path and cstate/pstate information :D
15:05 karolherbst: :D
15:05 mupuf: if only I could reclock properly first
15:05 karolherbst: to be fair, in bash I wouldn't be possible to check every 0.1 seconds
15:05 mupuf: lol
15:05 mupuf: THAT bad?
15:05 karolherbst: well
15:06 karolherbst: around 7 nvapeek calls
15:06 karolherbst: this takes some time
15:06 karolherbst: maybe it would be possible though
15:07 RSpliet: mupuf: it's a great way to test the PID overflow method...
15:07 mupuf: that too!
15:08 linkmauve1: mupuf, I watched your conference from XDC, and at some point you talk about using an ioctl to make Nouveau and Grate agree on the tiling format for dmabuf; why not just make them understand the same set of dmabuf modifiers?
15:08 mupuf: linkmauve1: which talk?
15:09 linkmauve1: The one with Alexandre Courbot.
15:09 mupuf: we talked about Grate?
15:09 linkmauve1: About the K1 and X1.
15:09 mupuf: right
15:09 linkmauve1: Not Grate specifically, is there another driver?
15:09 linkmauve1: I might be confusing names.
15:10 mupuf: we talked about the 3d engine and the display controller
15:10 linkmauve1: I’m currently working on dmabuf support in Weston, and I wanted to see real-life showcases of modifiers being used, as currently we reject any dmabuf with a modifier not equal to zero.
15:11 karlmag: karolherbst: btw.. unless my order gets cancelled (since they might not be able to get it) I hope to have a 660 soon.
15:12 mupuf: the problem is that you need to get every display driver to understand the modifiers in the same way
15:12 linkmauve1: There are vendor prefixes to give you a namespace in which to specify your own modifiers.
15:13 mupuf: yes, we have been talking about this for some time
15:13 linkmauve1: Is it not a good solution?
15:13 mupuf: yes, probably?
15:13 linkmauve1: ^^
15:14 mupuf: I have been working on this for some time, but every time I talk about this, we keep on disagreeing :D
15:14 linkmauve1: :D
15:14 linkmauve1: Was the ioctl way a stop-gap until modifiers were agreed on?
15:15 mupuf: not sure what ioctl you are talking about
15:18 linkmauve1: I’m not sure either, at some point Alexandre did speak about it, let me find when.
15:21 linkmauve1: mupuf, at 13:36 from https://www.youtube.com/watch?v=dnG0X0uwLuY he speaks about a Tegra-specific ioctl, but right after about modifiers so… Yeah, nvm. ^^
15:23 karolherbst: karlmag: nice
15:23 mupuf: linkmauve1: well, you need to ask him then :p
15:23 mupuf: linkmauve1: his name on irc is gnurou
15:23 linkmauve1: Hi gnurou. :)
15:23 linkmauve1: (Which timezone?)
15:23 karolherbst: mupuf: anyway I currently try to implement it in kernel space on the cpu (not with a pdaemon script first)
15:24 karolherbst: mupuf: any idea how the blob does it for pre gt215 hardware?
15:24 mupuf: linkmauve1: japan
15:24 karolherbst: because I was thinking if there are some chipsets which doe dyn reclocking on the cpu, I might start with that, and add support for a pmu script later based on the same algorithm or something
15:25 mupuf: karolherbst: gt215 has less counters too
15:25 mupuf: but before that, it uses .... pcounter of course!
15:25 karolherbst: yeah I know, only 4
15:25 karolherbst: and no way to get pcie counters
15:26 linkmauve1: So far I have been unable to find a single pair of display and provider drivers that were using modifiers to negociate a dmabuf format.
15:26 mupuf: karolherbst: really?
15:26 karolherbst: yeah
15:26 karolherbst: but it doesn't really matter
15:26 mupuf: linkmauve1: yes, as I said, people do not really agree on this kind of stuff yet
15:27 linkmauve1: Ok.
15:27 mupuf: it is annoyingly complex
15:27 linkmauve1: Yeah, I’ve had some preview of that kind of complexity.
15:27 mupuf: what I would love to see is that we would expose formats like you said: vendor_id:format_id
15:28 karolherbst: mupuf: would you like to confirm this? https://github.com/envytools/envytools/pull/24
15:28 mupuf: and then having a userspace library that would match the formats
15:28 linkmauve1: I’ve been looking at it from the side of the EGL user, as well as from the DRM planes user.
15:28 mupuf: but then what do you do if the formats do not match?
15:28 linkmauve1: Likely reject the buffer, since you can’t know anything about it.
15:28 mupuf: if it is only the pixel format, then a shader can do the trick
15:28 mupuf: well, that's one way for sure :D
15:29 mupuf: but what if you need to convert it?
15:29 mupuf: karolherbst: speaking about nvenc, how the heck did you find this one?
15:29 linkmauve1: Yeah, I already implemented YUYV, NV12 and YUV420 in Weston by reimporting the different planes of the provided dmabuf as separate dmabufs, using R8/GR88 formats instead.
15:29 karolherbst: mupuf: anyway, I would need some high end gt215+ tesla card and an high end kepler card on reator to test stuff out a bit :)
15:30 linkmauve1: Of course, that only works in the GL renderer.
15:30 karolherbst: mupuf: it is there on kepler, and not on fermi
15:30 karolherbst: and
15:30 mupuf: gt21x and high-end do not really go together :D
15:30 karolherbst: it is also added to the other three video stuff
15:30 mupuf: those are shitty GPUs :D
15:30 linkmauve1: And that’s only when the first import failed.
15:30 linkmauve1: (EGL import, we don’t do DRM plane import yet.)
15:30 karolherbst: mupuf: W 0x10a514 0x00020070 PDAEMON.COUNTER_MASK[0x1] <= { PVLD | PPDEC | PPPP | 0x20000 }
15:31 karolherbst: it was a bit obvious, but I didn't verified it yet
15:31 mupuf: that is a fair assumption, indeed
15:31 mupuf: well, try not to add guesses in envytools. You can add comments though!
15:31 mupuf: and that would be appreciated
15:31 karolherbst: I did
15:31 karolherbst: "<bitfield pos="17" name="PVENC" variants="GK104-"/><!-- needs to be confirmed -->" :p
15:32 mupuf: I meant the opposite
15:32 karolherbst: I mean I could simply verifiy it though :/
15:32 mupuf: <!-- bit 17 may be nvenc -->
15:32 karolherbst: I guess I do it then :D
15:32 mupuf: yeah, that would be the best :)
15:32 mupuf: linkmauve1: I see you are having fun :p
15:33 mupuf: anyway, this is a real discussion that should be restarted
15:33 karolherbst: for your kepler there is no dedicated counter for that though :/
15:33 mupuf: I talked about this with daniel stone in private recently
15:34 karolherbst: ohh wait, mhh
15:34 linkmauve1: mupuf, indeed. ^^
15:35 linkmauve1: What’s missing the most, imo, is a generic way for the display driver to expose the format:modifier couples it supports.
15:35 linkmauve1: The formats are already available by querying the DRM planes; although I heard yesterday that recent Nvidia cards don’t have any overlay plane.
15:35 karolherbst: hey, strange
15:36 mupuf: agreed, we need to expose that
15:36 mupuf: and that could already be done
15:36 mupuf: and I think everyone agrees
15:36 mupuf: but it will not solve much since we also need a way to convert buffers
15:37 mupuf: and so far, there is no interface for that
15:37 mupuf: and egl/gl try to be as agnostic as possible of the memory format
15:37 mupuf: aside from the colour format
15:38 linkmauve1: Where do you want to do the conversion? Wouldn’t that be something the user application would do instead of any driver part?
15:38 mupuf: ah ah, how could it do it?
15:38 mupuf: using the cpu?
15:38 mupuf: handling tiling formats too?
15:38 mupuf: and what about resolving compression tags too?
15:39 linkmauve1: Or just requesting the buffer in the format the display expects— but then the GPU driver would be the one doing the conversion.
15:39 mupuf: the only sensible thing would be to have drivers allowing to convert buffers in a different format supported by the driver
15:39 linkmauve1: Providing driver handling the conversion, and display driver, in your sentence?
15:39 mupuf: and then importing the buffer into the other driver and potentially changing the format there once again before sending it to the display controller
15:40 mupuf: yeah, the problem is that the display may not be from the same company as the 3d engine
15:40 linkmauve1: Indeed.
15:41 linkmauve1: In the worst case there is no common modifier and thus only linear buffers are exposed, but your GPU driver supports that already right?
15:42 mupuf: should
15:43 mupuf: one other problem is that depending on the hw and driver, the kernel may not be able to do the conversion
15:43 mupuf: nouveau is fine because the copy engines can do all the convertions you want to handle
15:43 mupuf: but ... intel can't. It is handled by the 3d engine and it pretty much means it should be done in mesa
15:44 mupuf: that means we need to export extensions in either egl or gl
15:45 linkmauve1: Ah yeah, the PRIME case.
15:45 linkmauve1: I never had a dual-GPU so this is pretty new to me.
15:45 mupuf: right
15:45 mupuf: but hey, prime is all about having one gpu doing the rendering and a display controller ... diplaying it
15:45 mupuf: and both not having to be from the same constructor
15:45 linkmauve1: Are you speaking about what people call reverse-PRIME, where the Intel GPU creates the dmabuf and the Nvidia display then imports it?
15:47 mupuf: well, the prime case is just as annoying, isn't it?
15:47 linkmauve1: Oh, and then if they were for whatever reason using the 2D engine instead of the 3D one they couldn’t share it with Nvidia tiled, right?
15:47 mupuf: nvidia has support for the tiling formats of intel
15:47 mupuf: in the hw
15:48 linkmauve1: So it would just be a matter of both agreeing on a shared set of modifiers?
15:48 linkmauve1: “just”
15:49 mupuf: Well, yes and no
15:50 mupuf: not sure what are the modifier you are talking about, but we should be able to query the precise format of the buffer
15:51 mupuf: then we should have a userspace library mapping together all the formats from the different vendor ids
15:51 linkmauve1: An attribute of dmabufs, which is a vendor-namespaced 64-bit integer, leaving 56-bit per vendor for any kind of format modification (tiling, compression, etc.).
15:51 mupuf: as in, format 1 of vendor 3 is the same as format 4 of vendor 4
15:52 mupuf: then we need an interface to convert a buffer from format to another
15:52 mupuf: sounds exactly like what we need then :)
15:52 mupuf: and let weston request a convertion
15:53 mupuf: but hey, we will also need to be able to ask the client to start allocating buffers in another format
15:53 mupuf: and that is HARD
15:53 mupuf: especially since they use a dri3-like approach
15:53 mupuf: that is to say, they allocate the buffers through egl/gl and they have no control on the actual format
15:54 mupuf: but mesa could handle without any protocol
15:54 mupuf: not sure how it would work when dealing with proprietary drivers!
15:54 linkmauve1: Heh. ^^'
15:55 mupuf: the last part has been proposed by daniel stone
15:55 mupuf: not myself
15:56 linkmauve1: The util library part?
15:57 linkmauve1: I will have a chat with him about that next time I see him at work.
15:57 mupuf: yeah, prepare to have your mind blown :D
15:58 linkmauve1: ^^'
15:58 mupuf: fuck, 2am and I still haven't done any of my homework :s
15:58 linkmauve1: Oops, sorry. :x
15:58 mupuf: tomorrow will be a short day at work
15:59 mupuf: it's ok, I don't think I could have studied any more words today anyway
15:59 linkmauve1: It’s only 12am here.
15:59 mupuf:had to speak Finnish today to order a pizza and for some reason, the guy did not get that I wanted a custom pizza... Listing the ingredients was not enough :D
16:00 linkmauve1: :D
16:00 mupuf: It is funny how the only people who do not speak english in this country are ... foreigners :o
16:01 mupuf: good night everyone!
16:01 linkmauve1: Good night. \o_
16:17 pmoreau: mupuf: He he, same over here! :-)
22:29 pmoreau: skeggsb_: ping (about the PCIe tag field size, EXT_TAG enabling) :-)
22:39 pmoreau: mwk: just a gentle reminder for you to have a look at my pull requests for envytools ;-)
22:46 pq: mupuf, I don't think we absolutely need to be able to convert between different non-zero modifers. If we get a list of supported ones from each device, user space can check if any match - if not, just use linear.
22:47 pq: like we do now for everything cross-device
22:50 pq: mupuf, asking clients to allocate in the correct format+modifier is exactly what I and linkmauve1 are working on for a general Wayland protocol extension.
22:53 pq: mupuf, granted, GL is not the primary use case for this work really - we've seen comments that GL implementors want to keep using their hidden-inside-EGL things, and that's ok.
22:55 pq: mupuf, we're looking at how to know what format modifiers (as defined by drm_fourcc.h) a compositor can support and advertising that to clients. Having clients allocate with specific modifiers is something I have not thought of yet.
23:23 pmoreau: skeggsb_: Maybe I could remove the pci_is_pcie() check, and revert MCPxx to use nv40_pci_new. I need to check whether there are other G84+ cards that are not PCIe.
23:28 mupuf: pq: we will still need a library that says some formats are equivalent
23:28 skeggsb_: pmoreau: even mcpxx is pci-e isn't it?
23:29 pmoreau: skeggsb_: pci_is_pcie() returns false for it. And in lspci, it is not displayed as being PCIe as well
23:29 skeggsb_: ah, interesting
23:30 skeggsb_: i kinda just assumed it would be
23:30 pmoreau: Or rather, maybe it is PCIe capable, but it is not connected to a PCIe bus
23:31 pq: mupuf, do we? Why don't drivers advertise already specified formats?
23:32 pq: err, modifiers
23:32 mupuf: yeah, that is another way, but I find it encourages exposing less formats than actually supported
23:33 pq: someone has to be doing the research on what formats are the same in any case, which means driver writers have to document what their modifiers mean
23:34 pq: anyway, I don't think a normalizing translation is that big an issue, it could live in libdrm.
23:34 mupuf: yeah, but once a kernel is released it is hard to go and update that
23:35 mupuf: whereas asking devs to just expose every format supported and then expanding a user-space library is much easier
23:35 pq: I see no big difference either way
23:35 mupuf: and this library could later be the basis for knowing the cost of convertion
23:36 mupuf: yes, the only difference I see is that the kernel would not need to be changed as often and it is easier on proprietary drivers
23:37 mupuf: pq: anyway, I am really looking forward to seeing what solution you two will come up with!
23:38 pq: yeah, that's for the kernel people, doesn't seem to affect the user space much.
23:39 pq: mupuf, it's partially already here: http://cgit.freedesktop.org/wayland/weston/tree/protocol/linux-dmabuf.xml
23:39 mupuf: ? weston needs to understand formats, I don;t understand why the kernel cares at all
23:39 pq: mupuf, what's missing is advertising modifers along the formats.
23:40 mupuf: what do you plan on having in the modifiers?
23:40 mupuf: tiling format and compression state?
23:40 pq: mupuf, no, weston does not *have to*, unless it wants to convert with shaders, but that's not mandatory.
23:40 pq: mupuf, the drm_fourcc.h defines modifiers.
23:40 mupuf: yes, agreed
23:41 mupuf: drm_fourcc.h is all about pixel format
23:41 pq: mupuf, modifiers are already merged in upstream kernels, we'll simply use them.
23:41 pq: and modifiers
23:42 mupuf: I see intel document his format
23:42 mupuf: good
23:42 pq: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h#n140
23:42 mupuf: but it is just the tiling format :s
23:43 pq: so?
23:44 mupuf: I guess it is better than nothing, it will still require mesa to resolve the compression tags before creating the dmabug
23:44 pq: mesa is not really the target audience of our work
23:44 mupuf: good, if you can make it work in the general case, then it is all good :)
23:44 pq: it's basically everyone else
23:45 pq: mesa only needs to be able to import and use these in case the compositor is compositing with GL
23:45 mupuf: so, what should be done if two formats are equivalent between vendors?
23:45 pq: you'd ask the kernel devs about that
23:46 mupuf: right now, it seems like it is impossible to match them ;s
23:46 pq: how so?
23:46 mupuf: fourcc_mod_code(INTEL, 2) <-> fourcc_mod_code(SAMSUNG, 1)
23:46 pq: modifiers are intended to be opaque values primarily
23:47 pq: yeah, you'll need look-up table, if those actually are the same, and one vendor refuses to use the modifier from another
23:47 airlied: I don't think the idea was to match intra-vendors
23:47 airlied: reusing was the idea
23:47 mupuf: don't get me wrong, this is what I want. But then someone has to know about the equivalent formats unless you are asking the drivers to expose formats for all the vendors (bad idea, will never happen)
23:48 airlied: it was mainly for sharing between devices from the same vendor
23:48 airlied: so tegra and nouveau
23:48 airlied: or any soc where display and render were separate
23:48 mupuf: airlied: I think this is sane! Let the userspace deal with this and have a force import if a driver thinks it does not support one modifier.
23:49 mupuf: the latter is a cross-vendor case
23:49 mupuf: which is what you said you don't want to support
23:49 airlied: but it isn't a random cross vendor case
23:49 mupuf: not entirely
23:49 airlied: not like on x86
23:49 airlied: where you could have misc radeon and misc nvidia
23:50 mupuf: right, but I do not see why it is harder in the x86 world than the arm world
23:50 airlied: generally socs can do linear or the display engine learns about the render engine's output format
23:50 mupuf: if we have this userspace DB, everything should be fine
23:50 airlied: it probably would need to be a userspace DB
23:50 mupuf: yes
23:50 mupuf: for many reasons
23:50 airlied: or a dump all formkats kernel query
23:51 mupuf: anyway, I want to follow this development
23:51 pq: my plan includes adding EGL API to query supported importable formats + modifiers
23:51 mupuf: and I need to make public a proposal I made earlier. It is just food for thoughts, not anything else
23:52 mupuf: it was trying to make it easy for compositors
23:52 pq: DRM I haven't looked at yet, because a Wayland compositor cannot accept a format+modifer the DRM could import but the renderer cannot.
23:52 pq: not in a general case
23:54 pq: this is for client <-> server comm
23:54 mupuf: ack
23:55 pq: server-internal uses between a GPU and a display block are not on my table atm.
23:55 mupuf: well, keep us updated and I will try to allocate some brain cycles on that :)
23:55 mupuf: partial solutions are OK as long as they are building towards the right solution (tm)
23:56 pq: sure
23:57 pq: mupuf, I think https://phabricator.freedesktop.org/T13 is the closest tracker we have atm.