00:07 mupuf: gnurou: yes, I got it running
00:08 mupuf: I sent you a pull request to update the doc a little for archlinux
00:08 mupuf: I also sent a pull request for envytools, to make it work there
00:09 mupuf: tagr: here is how I find the gpu: https://github.com/envytools/envytools/commit/219c1db297fe1f0b8f2a311bb0909e8b192a93fc#diff-0074faba8502c4a6186b50c324145c4dR176
00:09 mupuf: and how I check if it is by nvidia: https://github.com/envytools/envytools/commit/219c1db297fe1f0b8f2a311bb0909e8b192a93fc#diff-0074faba8502c4a6186b50c324145c4dR161
00:11 mupuf: I guess if the gpu is always at the same address, I could simplify the code
00:12 mupuf: gnurou: I also plugged my system to turn on and off computers to the jetson and I exposed it to every nouveau developer :)
00:13 mupuf: it's great that the board had a header available to expose the power button and the LED
01:12 tagr: mupuf: that should be fine, though technically the node name does not necessarily have to be named that way
01:13 tagr: then again, who knows what else would break if you were to run this on a downstream kernel
01:34 mupuf: tagr: agreed, time will tell!
01:34 mupuf: thanks!
02:30 pecisk: sorry for newbie question but how RadeonSI/Nouveau uses LLVM? I understand driver generates LLVM IR, but after that what happens? Is it generated LLVM IR ran on GPU? CPU?
02:31 airlied: pecisk: nouveau doesn't really use llvm
02:31 pecisk: airlied: ahh ok
02:33 airlied: pecisk: but with radeonsi, the llvm ir is turned into gpu instructions
02:36 pecisk: airlied: that's what I thought, thanks for clarification :)
03:26 pmoreau: skeggsb_: Thanks for pulling it in! Do you think it can squeeze in 4.3 as a bug fix, or will it wait for 4.4 (in which case, maybe it could be send to stable)?
04:37 karolherbst: mupuf: which gt215+ cards do you have?
04:59 karlmag: I think I need to tidy a bit more often... Found an xtx 8800 gtx and a gt9200 (IIRC) in a box :-P
04:59 karlmag: yet to test they actually work though, but there be hope.
05:05 karolherbst: karlmag: 9200 gt actually exist?
05:05 karlmag: maybe it was 9400.. can't remember right now :-P
05:05 karolherbst: :D
05:05 karolherbst: k
05:07 karlmag: I think that probably is right.
05:07 karlmag: maybe I'll get around to check them later today.
05:08 karlmag: http://sishardware.com/unt/16547-asus_en9400gt_silenthtp512m_geforce_9400gt_512mb_128___bit_pci___e_x16_hdcp_vga.html
05:09 karlmag: looks like that, so it should be 9400gt then
05:10 karlmag: though I seem to remember a hdmi port... Maybe I'm just mixing up with other cards:-P
05:15 karolherbst: that card should support pcie v2 though
05:34 mupuf: karolherbst: what do you mean by gt215+?
05:34 mupuf: you really mean all the gpus I have newer than the gt215?
05:34 mupuf: it is faster to ask me which ones I do not have
05:37 karolherbst: mhh
05:37 karolherbst: I mean teslas .d
05:38 mupuf: then there is just the 218
05:39 mupuf: I do not have the ac nor the aa
05:39 mupuf: 213/5/8 are the same
05:39 mupuf: aa/ac have no pcie bus to reclock, I would assume, but I may be wrong
05:40 karlmag: karolherbst: on the other hand; difficult to beat the price ;-)
05:41 karolherbst: mupuf: mhhh, no, I need one of those because of the memory counter
05:41 pmoreau: mupuf: You're right: they don't :-)
05:42 mupuf: pmoreau: but you can still see them in lspci, can't you?
05:43 mupuf: karolherbst: the aa and ac have no memory reclocking
05:43 mupuf: they use the system memory
05:43 pmoreau: Indeed
05:44 karolherbst: mupuf: yes, but you gt218 only was reading out garbage in the memory counter
05:44 karolherbst: that's what bothering me
05:44 mupuf: ah, right
05:46 karolherbst: an I still think there may be some kind of memory counter on the embedded ones
05:47 karolherbst: anyway, I want to figure that part out
05:49 karolherbst: mupuf: you also found that PMFB counter. Any clue what that shows us exactly? I don't see the blob using it, but it helps to messure the memory load
05:49 karolherbst: especially when you have stalls in the gpu waiting for some memory transactios
05:50 karolherbst: maybe it is the gpu core <=> gpu memory bus load counter?
06:02 Yoshimo: is there a branch somewhere that includes both Rspliets kernel-nouveau-nv50-pm work and karols pci speed changes and can be compiled as an out-of-tree module? i can't get these patches together
06:04 karolherbst: Yoshimo: you can get my pcie stuff as a ptch easily
06:04 karolherbst: github is pretty good in that regard
06:05 Yoshimo: it has to be the other way round his stuff on top of yours as far as i can see
06:05 karolherbst: Yoshimo: https://github.com/karolherbst/nouveau/compare/master...karolherbst:pcie_speed.patch
06:05 karolherbst: this should apply cleanly on current nouveau master
06:07 karolherbst: Yoshimo: ohh rspliet uses the linux tree
06:07 karolherbst: mhh
06:07 karolherbst: I think the best thing to do is to fetch bens tree
06:07 karolherbst: apply my stuff
06:07 karolherbst: and apply RSpliets stuff
06:08 karolherbst: for RSpliets stuff you have to adjust the -p parameter though
06:08 Yoshimo: do you construct these .patch urls manually or is that a button somewhere on github?
06:09 karolherbst: Yoshimo: this is the stuff from RSpliet: https://github.com/RSpliet/kernel-nouveau-nv50-pm/compare/6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f...master.patch
06:09 karolherbst: I just add .patch
06:09 karolherbst: :D
06:09 karolherbst: it is state somewhere in the github REST API
06:09 karolherbst: but I don't know where
06:09 karolherbst: it is worth a look though
06:09 karolherbst: there is a bunch of usefull things in there
06:13 karolherbst: mupuf: the 0x100 counter bit does something on kepler, but its value seems to be half the ticks on idle
06:19 pmoreau: Roy's patches were merged into Ben's tree
06:26 karolherbst: ohh yeah, like 10 hours ago
06:26 karolherbst: no gddr5 patch for 4.3 as it seems :(
06:27 karolherbst: ohh no, that's too late anyway
06:27 karolherbst: 4.4
06:32 pmoreau: Too late? I guess fixes can still be merged?
06:33 karolherbst: mhh right
06:34 karolherbst: he wanted to wait for an answer from nvidia, so maybe that's why
06:34 pmoreau: Or maybe they can be forwarded to stable and be merged in 4.4
06:36 karolherbst: it is a bugfix one way or another
06:36 karolherbst: so it can also be added to later rcs
06:40 karolherbst: I think I look a bit into fermi reclocking today
07:54 karolherbst: mhhh
07:55 karolherbst: somehow the fermi reclocking stuff is strange
07:56 karolherbst: mupuf: what about the thermal stuff? I would like to work on the benchmark suite stuff, because I don't have the nerve for that fermi stuff right now :D
08:02 karolherbst: pmoreau: could you try something out for me?
08:02 karolherbst: on your mcp gpu?
08:02 pmoreau: Depends... :D
08:02 pmoreau: Just kidding
08:02 pmoreau: What can I do for you?
08:02 karolherbst: nvapeek 0x10a500
08:02 pmoreau: With Nouveau/blob/nothing?
08:03 karolherbst: nouveau or blob
08:03 pmoreau: K
08:03 pmoreau: One sec
08:03 karolherbst: I don't know if your mcp gpu has pdaemon
08:03 pmoreau: ...
08:03 karolherbst: if it has, we could try out some pdaemon counter stuff
08:04 pmoreau: I guess it doesn't, otherwise I would have had something different from ...
08:04 RSpliet: karolherbst: PMU is not available on NVAA/NVAC to the best of my recollection
08:04 karolherbst: RSpliet: yeah somehow i think it isn't there, but better check that
08:04 RSpliet: it should have HWSQ though
08:05 RSpliet: not that is of any use to you
08:05 karolherbst: mhhh
08:08 karolherbst: I really need some more gt21x traces :/
08:09 yoshimo: karol unfortunately your patch doesn't apply cleanly on darktamas branch
08:15 karolherbst: ohhh
08:15 karolherbst: k
08:15 karolherbst: wait
08:15 karolherbst: I bet beacuse of the merge yesterday
08:18 karolherbst: mhhhh
08:18 yoshimo: https://pastee.org/rsfkn , looks like some things are already there
08:24 karolherbst: yoshimo: I am currently rebasing some stuff
08:27 karolherbst: I have to rebase on pmoreau patch now
08:29 pmoreau: Why not on HEAD?
08:29 pmoreau: You don't want Roy's patches?
08:29 karolherbst: pmoreau: why do you return the old value in nvkm_pci_mask?
08:30 karolherbst: pmoreau: can't use HEAD right now, some patches I need aren't ported to 4.2 yet
08:30 pmoreau: I guess I either took the behaviour from the previous nvkm_pci_mask, or from nvkm_mask
08:30 karolherbst: mhhh
08:30 karolherbst: I bet I looked that up and I am sure it is a void function
08:31 karolherbst: ohhhh
08:31 karolherbst: mhhh
08:31 karolherbst: okay
08:31 karolherbst: I will use yours anyway
08:31 pmoreau: nvkm_mask returns the old value
08:32 karolherbst: yeah I saw it now
08:32 karolherbst: I am not that used to macro coding
08:34 karolherbst: yoshimo: redownlod patch
08:34 karolherbst: should apply now
08:38 karolherbst: pmoreau: I just take commits from nouveau master so that all my branches apply cleanly, while managing 3.19 backwards compatibility (I only need 4.1 though, but I also get 3.19 at the same time :) )
08:39 yoshimo: karolherbst: yes, applies now
08:40 pmoreau: karolherbst: Just out of curiosity, why do you need backwards compatibility to 4.1?
08:41 karolherbst: pmoreau: bfs patches :p
08:42 pmoreau: Never tried it
08:42 karolherbst: mhhh
08:43 karolherbst: it works good enough usually
08:43 karolherbst: like on high load I usually can still play games and stuff
08:43 karolherbst: like compiling chromium/libreoffice :D
08:44 pmoreau: :D
08:44 karolherbst: I wouldn't care about that otherwise
08:48 mupuf: karolherbst: https://github.com/dlespiau/patchwork/blob/freedesktop.org/patchwork/tests/browser.py <-- sounds interesting
08:48 mupuf: http://www.seleniumhq.org/
08:49 karolherbst: mhh looks nice
08:56 karolherbst: done rebasig :/
08:56 karolherbst: I really could autmate this :D
08:57 karolherbst: mupuf: so what is the state of the power sensor stuff?
08:57 karolherbst: wow
08:57 karolherbst: this branch protection feature on github is really nice
08:58 karolherbst: if you have some CI stuff hookedup, you can block merges until they pass
09:09 mupuf: karolherbst: nice :)
09:09 mupuf: the state of the power sensor stuff is I will have a look tonight
09:10 karolherbst: okay :) thanks a lot
09:10 mupuf: unless hakzsam requires reator
09:10 karolherbst: mhh I could actually code the benchmark binaries already
09:10 mupuf: and in this case, I will revert to the jetson's slow IOs by hooking an ssd
09:10 karolherbst: mupuf: you won't add any sysfs entries or stuff like that, will you?
09:11 mupuf: well, how else do you want to expose the power?
09:11 karolherbst: if you use my patch, there is already the hwmon entry ;)
09:11 karolherbst: I was rather asking about a nouveau specific interface
09:12 karolherbst: using hwmon would make more sense, because then it is somehow gpu indepentend
09:12 karolherbst: *independent
09:12 mupuf: totally
09:12 mupuf: I will use your patch for exposing the value
09:12 karolherbst: okay
09:12 karolherbst: then I can already start the stuff :D
09:12 mupuf: the only thing missing in my code was ... deciding how to handle the selection
09:13 karolherbst: shall I add that to envytools? or seperate project
09:13 mupuf: err, I mean, should I create a subdev or not?
09:13 karolherbst: mhhh
09:13 karolherbst: good question
09:13 karolherbst: actually I had the same
09:13 karolherbst: and asked ben
09:13 karolherbst: :D
09:13 mupuf: hehe, I just need to decide
09:13 mupuf: therm has already been abused for the fan
09:14 karolherbst: maybe
09:14 mupuf: not sure it makes sense to repeat the mistake
09:14 karolherbst: adding a sensor subdev?
09:14 mupuf: iccsense
09:14 mupuf: yes
09:14 karolherbst: then the fan stuff could be moved there and temp sensors and stuff
09:14 karolherbst: and ptherm could use it then
09:14 mupuf: or pwrsense
09:14 karolherbst: something like that
09:14 karolherbst: the sense subdev could be splitted again, yes
09:15 mupuf: splitted?
09:15 karolherbst: I mean like it would bundle some stuff
09:15 karolherbst: I don't know if it would make sense to add a subdev just for the power sensors
09:15 mupuf: no, I don't want that
09:16 mupuf: yes, I think it does
09:16 mupuf: and fan should probably be split out of therm
09:16 mupuf: but I will have a look into this as I come back home
09:16 mupuf: I also need to work on my finnish ... So much homework...
09:16 karolherbst: I think it would be nice to have a subdev for all kind of sensors and you can just get values like nvkm_sensors_get_all_values(nvkm_sensors *, nvkm_sensors_type, int **values, int size); or something
09:16 pmoreau: imirkin_: Mesa didn't fail to compile a v330 shader using textureCube, even though textureCube was removed after v140.
09:17 karolherbst: mhhh
09:17 karolherbst: I don't know
09:28 yoshimo: karolherbst: what deters you from working on fermi reclocking?
09:34 karolherbst: yoshimo: kworkers are hanging
09:35 karolherbst: and this is a bit painful to debug
09:35 karolherbst: I won't even use a fermi card myself, so I am more interessted to fix stuff for my card first :/
09:36 yoshimo: obviously
09:39 karolherbst: there is a lot of stuff done for fermi though
10:31 imirkin: pmoreau: pastebin the shader?
10:39 pmoreau: imirkin: https://phabricator.pmoreau.org/P45
10:41 imirkin: hmmm... well textureCube is always available with mesa.
10:43 imirkin: pmoreau: https://www.opengl.org/registry/doc/GLSLangSpec.4.50.pdf -- still there in glsl 4.50
10:43 imirkin: pmoreau: not sure where you got that it was removed... merely deprecated.
10:43 imirkin: pmoreau: oooh, but only in the compat profile. interesting.
10:44 imirkin: i guess mesa's not quite right about that then.
10:44 pmoreau: I switched from Mesa to NVIDIA, and it complained and failed to link, saying it had been removed (or was it deprecated?)
10:45 imirkin: pmoreau: looks like it depends on the profile -- removed from core, deprecated in compat.
10:45 pmoreau: I'm using a core profile
10:46 imirkin: right
11:43 Yoshimo: karolherbst: out of curiousity, what things are missing for your card?
12:05 karolherbst: Yoshimo: stable PWM voltageing, power sensor, dyn reclocking, pcie speed
12:05 karolherbst: allthough dyn reclocking is missing for every card, but currently I try to implement it for gt215+ cards
12:05 karolherbst: and pcie speed is implemented for tesla+
12:05 pmoreau: Maybe clock/power gating as well?
12:05 karolherbst: it just has to be tested and stuff
12:06 karolherbst: pmoreau: right, but that's unimportant to me :p
12:06 pmoreau: :-(
12:06 karolherbst: well
12:06 karolherbst: I can always turn the gpu off, when I don't need it
12:06 karolherbst: so
12:06 pmoreau: :-D
12:06 pmoreau: Right, you could also unplug it if you want
12:06 karolherbst: an under full load it maybe reaches 80°C
12:06 karolherbst: pmoreau: laptop
12:07 pmoreau: Ok, slightly more difficult
12:07 karolherbst: pmoreau: ACPI method
12:07 karolherbst: it is simple :p
12:07 pmoreau: Dual GPUs I gues?
12:23 karolherbst: pmoreau: yeah
12:24 pmoreau: Ok
12:27 karolherbst: I played around with clock gates though
12:28 karolherbst: clock gating was pretty easy to enable and it saved me like 10% on idle
12:28 karolherbst: and then around 10% to 15% are missing to be on the blob level, so meh
12:31 pmoreau: 25% is quite nice :-)
12:31 karolherbst: yeah well
12:31 pmoreau: Even if it is on idle
12:31 karolherbst: clock gating is easy to enable :p
12:31 karolherbst: at least for my gpu
12:31 karolherbst: maybe I will work on that
12:31 pmoreau: Or you can help me convince mupuf! ;-)
12:31 karolherbst: to do what?
12:32 pmoreau: To work on power/clock gating
12:32 mupuf: pmoreau: I already said I would do it, on the jetson
12:32 mupuf: hence why I asked nvidia for one
12:32 karolherbst: pmoreau: nope, I want that he finished the power sensor stuff :p
12:32 mupuf: we have the code for it in the android driver
12:32 karolherbst: *finishes
12:32 mupuf: for some reason, it did not work on discrete gpus
12:32 pmoreau: But I guess jetson is quite different from tesla, regarding it?
12:32 mupuf: so, let's start from there
12:32 mupuf: yes
12:33 mupuf: I want kepler to be good, I'll see about tesla later, if I have time :p
12:33 pmoreau: :-)
12:33 mupuf: but having at least one implementation that works is already good!
12:33 karolherbst: mupuf: did you try to set the engines to auto already? I mean, this was the stuff needed for my kepler
12:34 mupuf: ah ah, of course I tried
12:34 karolherbst: and?
12:34 karolherbst: :D
12:34 mupuf: no differences in power usage
12:34 karolherbst: mhhh
12:34 karolherbst: strange though
12:34 karolherbst: why does it work for me
12:34 karolherbst: ....
12:35 mupuf: because you are lucky-enough to have one bit set in the right register :p
12:35 mupuf: and I am not that lucku
12:36 karolherbst: I see
12:37 mupuf: brb
12:38 karolherbst: how should I call the voltage value mainly for the core/shaders whatever?
12:38 karolherbst: the one got by nvkm_volt_get
13:00 mupuf: karolherbst: core_volt?
13:00 karolherbst: mhhh git send-mail adds me to the CC :/
13:00 karolherbst: mupuf: I don't know if _volt should be in the name
13:03 mupuf: then core is enough
13:09 karolherbst: mhhhh
13:09 karolherbst: what does git-sendmail do...
13:10 thomas_n: heyho how well is reclocking working on NVC0? (specifically the quadro 1000m) Couldn't find anything helpful except for the https://wiki.freedesktop.org/nouveau/PowerManagement/ table, but this really doesn't say much
13:10 karolherbst: ohh smtp
13:10 karolherbst: thomas_n: it doesn't as far as I am concerned
13:13 karolherbst: nice
13:13 karolherbst: so tls is starttls and ssl is ssl/tls
13:13 karolherbst: good to know
13:13 thomas_n: karolherbst: too bad, but perhaps it will some time
13:14 karolherbst: thomas_n: maybe, maybe not. I tried myself to give it a shot, but issues with my own card are more important to me right now :/
13:18 karolherbst: yay
13:18 karolherbst: it works
13:22 thomas_n: hmm maybe I'll be lucky enough finding it work good enough for what I wanna do
13:22 thomas_n: any thx karolherbst for your information
13:33 karolherbst: okay, done with emails for today :)
13:47 karolherbst: oh no, I messed up the first email :/
13:48 karolherbst: mupuf: I've also send the core volt and the ina id patch
13:49 mupuf: I won't apply the ina patch since it only adds the ina3221 and not the 219. I already have the patch anyway
13:49 mupuf: the other one, I will have a look later :)
13:52 karolherbst: :D
13:52 karolherbst: k
13:52 karolherbst: I've also send the pcie and the gddr5 stuff
13:52 karolherbst: ben said something about the sysfs removal
13:53 karolherbst: I think we need to discuss this again or something
13:53 karolherbst: I don't know anymore
14:16 karolherbst: RSpliet: maybe I should add a WARN_ONCE as well?
14:16 karolherbst: for this 16.0 speed thingy
14:17 karolherbst: or maybe I should already add support for 16.0 completly
14:17 karolherbst: it is not that far away
14:17 RSpliet1: if you're sure that this will really be 16_0
14:17 RSpliet1: I guess you don't have a GPU to test it, do you? :-P
14:18 karolherbst: I meant to other places as well
14:18 karolherbst: but I don't know how the vbios will look like, which even doesn't matter here really
14:18 karolherbst: mhh
14:18 karolherbst: we have to modify stuff later then anyway
14:18 karolherbst: I guess it is then fine
14:19 karolherbst: I just don't want to break stuff, when the linux kernel supports 16.0 and the bus does, and then nouveau messed up, because it can't handle it
14:20 karolherbst: RSpliet: "Is there a particular reason for making this u8 over u32 or unsigned int?" I just though smaller types are better? dunno
14:20 RSpliet: then make it handle such a case gracefully, but I'd stay away from trying to predict the future :-)
14:20 RSpliet: hmm
14:20 RSpliet: well, that's common perception
14:20 RSpliet: but not true
14:20 karolherbst: okay, so I shall simply use int
14:20 RSpliet: for return values it's going to end up in a 32-bit register anyway (depending on the calling convention)
14:20 karolherbst: ohh right
14:21 karolherbst: I just have to change the interface then :D
14:21 RSpliet: and in the struct it could lead to unaligned access (expensive on modern CPUs afaik) or the compiler just pads stuff
14:21 karolherbst: k
14:21 karolherbst: ohh I won't fix this today :D it is a bit much
14:21 RSpliet: no worries
14:22 RSpliet: gives Ben some time to comment as well :-P
14:22 karolherbst: yeah
14:22 karolherbst: I just fix the obvious stuff first :p
14:22 karolherbst: and I really dislike this (ver > 1) :D
14:23 karolherbst: but I dislike everything implicit usually
14:23 karolherbst: but the idea is nice though
14:23 karolherbst: I take the second
14:24 RSpliet: (ver >= 2) works too :-P
14:24 RSpliet: but granted, there's a bit of preference there
14:25 karolherbst: the g84_get_real_speed thing is a bit more complicated
14:25 RSpliet: I tend to be careful with my vertical screen real estate, given my 1280x1024 monitor, others have a 4k on their side and stopped caring :-D
14:25 karolherbst: there is a reg which tells you, what the current hardware speed is
14:25 karolherbst: and this changes a little bit later, then the target speed the driver changes :/
14:26 karolherbst: but I shall change the name :D
14:26 RSpliet: function names don't have to represent registers perfectly, they need to be descriptive and consistent for when OCDs like me come along :-P
14:26 RSpliet: but anyway, consider them nits, in general code looks tidy
14:27 karolherbst: the names are a mess :D
14:27 karolherbst: I didn't care enough, you are right, be honest :p
14:27 karolherbst: even g84_get_current_speed is not good enough
14:28 karolherbst: it shall be g84_pci_get_pcie_cur_speed
14:28 RSpliet: hmm you're right, that would be much nicer :-P
14:28 karolherbst: maybe g84_pcie_get_cur_speed is also fine
14:28 RSpliet: I'd say it is
14:28 karolherbst: and this applies to other functions as well
14:30 karolherbst: RSpliet: the error in the last commit is really an error, something horrible happend, what shall not happen
14:30 karolherbst: like vbios declares a pcie speed, but the driver doesn*t support it for the chipset
14:31 karolherbst: if a different speed is applied, this is all fine for that interface
14:32 karolherbst: I also print an error in that function
14:32 karolherbst: maybe I simply remove it in the pstate part
14:33 karolherbst: ohhh wait, I am wrong
14:33 karolherbst: this thing is called for every pci card out there
14:33 karolherbst: yeah, I have to remove that
14:33 karolherbst: thanks for your comments
14:34 karolherbst: okay, bed time for me :)
14:34 karolherbst: nighty nighty
14:35 karlmag: asus en9400gt silent.. guess my memory wasn't too bad then... and a Zotac GT610
14:35 karlmag: karolherbst: oh.. g'nini
14:35 karlmag: reminds me that I should find my bed thing too soon :-P
14:35 karlmag: (note "should" :-P )
14:41 pmoreau: My mail client didn't like Karol's patch 1/2 on perfmon! I have a happy mix of chinese, arabic characters, plus some funny emoticons and other unicode characters. O.O
14:43 karlmag: pmoreau: oh, the joys of charsets.
14:43 karlmag: one thing I don't dare discuss with local postmaster :-P
14:44 karlmag: and the storage guys have a thing or two to say about charsets too..
14:45 RSpliet: pmoreau: blame Eudora
14:46 pmoreau: :D
14:47 mupuf: RSpliet: wow, I had completely forgotten about Eudora!
14:48 RSpliet: I still have it's "new e-mail" jingle :-P
14:54 karlmag: unsure if I *want* to remember that :-P
14:55 RSpliet: people always think that sound comes from Ren and Stimpy
15:06 RSpliet: https://www.youtube.com/watch?v=RTrAVpK9blw&t=36s
15:08 mupuf: :o
16:02 npnth: While I was doing some work today, the OOM-killer decided to target X. No big deal, but afterwards (including persisting after reboot) my monitor is constantly bright black, whether it's supposed to be displaying TTYn or X.
16:03 npnth: I'm trying to nail down the worst-case scenarios first: is there any chance that a pathologically killed X could cause some persistent bits somewhere on the card to be flipped badly?
16:04 imirkin: npnth: clearly...
16:06 npnth: Well, I was thinking it could be other things.
16:07 npnth: Anyway, do you have any suggestions for how I could un-flip everything? Boot a kernel three times with some magic modesetting while chanting or something?
16:08 imirkin: npnth: hard reboot
16:08 imirkin: npnth: i.e. poweroff, wait 15s, poweron
16:09 npnth: imirkin: Okay, sounds good. I've only done soft until now.
16:10 npnth: Well, now it seems to work perfectly.
16:10 npnth: Thanks, I will keep that in mind next time X misbehaves on me.
16:13 imirkin: normally the vbios init sequence resets the card into an operable state, but i guess it doesn't handle every contingency
18:06 leidenfrost: Hi all. I have some video problems that generate kernel lockups in my linux box. In windows the drivers sometimes restart due to that hardware fault. Is there any way to make the kernel not die due to a lockup and restart the driver or even the X server instead?
18:07 imirkin: leidenfrost: nvidia blob drivers are more error-resistant
18:09 skeggsb_: there's a *lot* of areas that need work for us to be resiliant, both on the kernel side and userspace, we will get there, there's a number of people interested in working towards that
18:09 imirkin: 0's a number :)
18:09 skeggsb_: i did say interested, and not actively working :P
18:10 imirkin: hehe
18:10 skeggsb_: i am somewhat, on the kernel side, but nothing substantial to report as of yet
18:10 leidenfrost: At least I didn´t got an ¨get over it and buy a new card¨
18:10 leidenfrost: Nvidia cards aren´t exactly cheap
18:11 imirkin: newer (or older) card won't help the overall issue
18:11 imirkin: what gpu do you have btw?
18:11 leidenfrost: gt240
18:11 skeggsb_: out gpu error recovery strategy so far has basically been "try not to case the errors in the first place", which is nice, but, mistakes happen and we could be a lot better about those
18:11 skeggsb_: cause*
18:11 imirkin: leidenfrost: is it one with gddr5?
18:12 imirkin: leidenfrost: bugs get fixed with some frequency, try the latest software
18:13 leidenfrost: nope, ddr3
18:14 imirkin: hm
18:14 imirkin: should be relatively stable
18:14 leidenfrost: I have a question: If due to some hardware fault, does the X server support restarting the card and the module without killing the desktop?
18:15 imirkin: leidenfrost: nope
18:15 leidenfrost: That´s a bummer
18:16 imirkin: leidenfrost: it's not really in the X server's purvue to do anything of the sort
18:16 leidenfrost: I know the error comes from the hardware, but at least in windows the driver just restarts itself.
18:17 leidenfrost: I know I should replace the card, but getting random crashes without even the possibility of doing a reisub is frustrating.
18:18 imirkin: blob drivers are a lot better at handling various errors -- try those.
18:19 leidenfrost: I´ll give them a try, thanks
19:24 AndrewR: imirkin, hello
19:27 imirkin: AndrewR: howdy
19:28 imirkin: AndrewR: well, perhaps you can mix the color formats under certain conditions. but i dunno what they are.
19:30 AndrewR: imirkin, may be simple rendering, without any depth-buffer as texture trics? Or really this is depend on hw and/or z-compression. You tested this on nv4x , right?
19:31 imirkin: not sure what z-compression has to do with it... i don't think nv3x/nv4x had it
19:31 imirkin: and yeah, this was with nv4x.
19:31 imirkin: there are 2 nv4x classes... you have a nv43 right? so that's the nv40 class then
19:32 imirkin: i mostly tested on nv44 which is a different class
19:32 AndrewR: yes, I'm on nv43.
19:33 imirkin: but i suspect that there's more to it
19:33 AndrewR: I waguely remember something about z-compression on those cards, and in dmesg I have this line: nouveau [ PFB][0000:01:00.0] ZCOMP: 378880 tags
19:33 imirkin: oh... dunno what that refers to
19:35 AndrewR: imirkin, not sure if I get your idea about second 'shadow' texture..you mean you create specific 32-bit texture out of 16-bit zbufer?
19:36 AndrewR: imirkin, original comment was more about swizzle and blocksize, not formats per se
19:37 imirkin: AndrewR: there are 2 separate things at play here
19:38 imirkin: first off, you can't mix swizzled and unswizzled color/zeta targets
19:38 imirkin: secondly you can't mix certain color formats with certain zeta formats.... maybe under some circumstances (e.g. when doing depth tests... or depth writes... or who knows)
19:39 imirkin: or maybe the problem is only in one directly
19:39 imirkin: direction*
19:40 AndrewR: imirkin, because I can't see original probelm ...with what application/game/demo/test you saw it on nv44?
19:40 imirkin: AndrewR: i don't remember... a ton of piglit tests
19:54 imirkin: AndrewR: it's possible i was a bit overzealous with shutting things down, feel free to figure out what the real restriction is
20:17 AndrewR: make'ing new piglit - hopefully its test will provide good assortiment of formats ....
20:17 AndrewR: *tests
21:14 AndrewR: imirkin, sadly, you are right - basic bi/glean test produces dmesg errors :( . But then it aborts saying 'GL_ARB_framebuffer_object is not supported' . ?! It really not supported on this class of hw?
21:16 imirkin: AndrewR: i disabled support for it... ARB_framebuffer_object requires the ability to have different-sized attachments
21:16 imirkin: EXT_framebuffer_object should be fine though
21:17 imirkin: glean tests all sorts of insanity
21:25 AndrewR: imirkin, so bad args to class 0x4097, method 0x0208: 0x06060348 , 0x06060328 , 0x06060325, 0x06060345
21:31 imirkin: AndrewR: yep :)
21:31 AndrewR: hm, bin/glean -t texUnits result in many Mesa: User error: GL_INVALID_OPERATION in glEnable/Disable(texcoord unit) . But may be this was already fixed in mesa-master, after commit I currently use
21:32 imirkin: ok so all those are due to swizzle mismatches
21:32 imirkin: lookup -a 43 -d SUBCHAN -- -v obj-class NV40_3D 208 0x06060345
21:32 imirkin: RT_FORMAT => { COLOR = X8R8G8B8 | ZETA = Z24S8 | TYPE = 0x3 | LOG2_WIDTH = 6 | LOG2_HEIGHT = 6 }
21:32 imirkin: note the TYPE = 3
21:32 imirkin: it should be linear or swizzled (1 or 2)