00:33 imirkin: skeggsb: did you see idr's nv20 woes?
00:59 skeggsb: imirkin: i noticed your patch, but didn't see anything beyond that
01:00 imirkin: skeggsb: idr sent a note in #dri-devel on friday night (your sat morning)
01:01 imirkin: skeggsb: https://people.freedesktop.org/~idr/dmesg.txt
01:03 skeggsb: imirkin: your patch is indeed needed for the fifo/nv04 path, but fifo/nv50 and disp/nv50 are fine as-is (the client mutex protects the use there, but it's a global hash table for nv04-nv4x)
01:04 imirkin: ok, that makes sense.
01:05 imirkin: i'm pretty weak on which mutexes are acquired when
02:55 mooch: if anybody here knows pre-G80 PFIFO well enough, i need someone to explain to me what this is trying to work around implementing http://git.redump.net/mame/tree/src/mame/video/chihiro.cpp#n4656
02:56 mooch: i know it's a bunch of game-specific hacks. what i don't know is wtf is going on
02:57 imirkin: something incredibly weird
02:57 imirkin: it's a fifo ring... you write, then adjust the put pointer. the gpu reads from the fifo and adjusts the get pointer (or vice-versa, i forget)
02:57 imirkin: when get == put, there is nothing new to be processed
02:58 mooch: so, without these hacks, the gpu just processes commands infinitely?
02:58 mooch: and what's the proper solution?
02:59 imirkin: they must implement some fifo processing command wrong
02:59 imirkin: the proper solution is to not have that hack.
02:59 imirkin: i.e. nothing like that should be necessary
02:59 imirkin: and it goes without saying that looking for specific pointer values in memory is *incredibly* fragile
03:00 imirkin: the envytools hwdocs actually do an excellent job of covering fifo operation
03:01 mooch: i beg to differ
03:02 mooch: i still can't figure out how all the different pfifo flags work
03:04 mooch: and they're necessary to get nt4 booting with nv4 drivers
03:05 imirkin: http://envytools.readthedocs.io/en/latest/hw/fifo/dma-pusher.html
03:07 mooch: i also need docs on pio mode
03:15 mooch: imirkin: why is http://envytools.readthedocs.io/en/latest/hw/fifo/pio.html empty?
03:16 imirkin: the usual reason - no one wrote anything there
07:03 pmoreau: skeggsb: ping for https://lists.freedesktop.org/archives/nouveau/2016-May/025081.html
07:48 rmrfchik: crash http://pastebin.com/RMg20VKc
09:03 karolherbst: rmrfchik: did you try to unload nouveau?
10:08 rmrfchik: karolherbst: nope, just locked the screen (xscreensaver) and went to drink tea. when I returned, the box was rebooted
10:09 karolherbst: I see
10:20 karolherbst: rmrfchik: well I know we have some issues related to unloading nouveau and maybe even suspend gpus, cause I also hit similiar things while unloading. Maybe I find some time and try to fix those race conditions.
11:16 karolherbst: skeggsb: if you have any ideas how we could rework the clk update code without pain, please let me know. I didn't look into moving all that stuff inside nvkm_clk_(p/c)state_prog might work. will try to come up with something after XDC
11:41 mupuf: karolherbst: what are you trying to do?
11:42 mupuf: mooch: PIO has never been used by Nouveau and is not exactly the best command submission method ;)
11:47 karolherbst: mupuf: clock updates on temperature change, I already had it implemented, but skeggsb disliked the design
12:46 karolherbst: mhh interesting, had to deal with if + max/min + add/sub operations here at work and figured that this might be also useful for the compiler to find situations where a set/slct can be opted away by smartly modiyfing conditional code doing add/sub+min/max operations
13:40 mooch: mupuf: i'm just trying to emulate the hardware tho
14:16 robclark: hmm, that is an interesting code construct.. http://hastebin.com/moxikukeye.c
14:17 ajax: ahh, the comma operator
14:18 ajax: uh, not even a comma. huh.
14:18 robclark: yeah, I'm not entirely sure what a break inside an if inside an expression even means..
14:19 RSpliet: robclark: the nvkm_msec takes a "piece of code" as a third argument
14:19 robclark: ahh, macro fun..
14:19 RSpliet: it's the test that times out after the amount of ms provided in the second argument ;-)
14:20 RSpliet: it's a piece of art, really!
14:20 ajax: #define nvkm_msec(d,m,cond...) nvkm_usec((d), (m) * 1000, ##cond)
14:20 RSpliet: is there a specific reason for looking at PDAEMON code?
14:20 ajax: and nvkm_usec is a ({}) statement-expr
14:21 ajax: yeah that's... that's something
14:22 robclark: I guess not *that* much worse than wait_event_*()..
14:58 duelle: Hi, will there be a new release for xf86-video-nouveau in the near future? e.g., version 1.0.13?
15:02 RSpliet: duelle: to what purpose are you interested in a new release?
15:03 imirkin_: we really should
15:03 imirkin_: i think current nouveau is broken for Xorg 1.18 :)
15:03 ajax: 1.19, yes
15:04 imirkin_: also 1.18
15:04 duelle: RSpliet: Currently I have to create my own package because a fix I need to get my multi-screen setting to work was introduced after 1.0.12
15:04 imirkin_: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=b824d36c28124955eda4aced5e637aa75eea4d6c
15:04 duelle: Therefor it would be great if there would be some kind of official version to have it applied via official OS packages
15:05 ajax: imirkin_: i mean, that's a broken feature, sure
15:05 duelle: It is not a big deal - just wanted to ask
15:05 imirkin_: ajax: which used to work fine with xorg 1.17
15:05 ajax: when i hear "broken for xserver N" i think "doesn't build" or "crashes"
15:05 imirkin_: robclark: skeggsb likes crazy macros.
15:05 RSpliet: duelle: nah you're right, it would be good to have a release, but nothing prevents your distribution from picking up the head of git either :-)
15:05 imirkin_: ajax: ah ok. i think "does not function as intended/used to"
15:06 ajax: RSpliet: don't go down that road
15:06 ajax: RSpliet: that kind of thinking is how we get the intel ddx
15:06 duelle: RSpliet: I agree, though it would be easier if it was some kind of official version. even if it were or whatever
15:06 imirkin_: it works so nicely for xf86-video-intel...
15:06 robclark: imirkin, I guess it would be slightly cleaner to make it "if (cond) break;" inside the macro, like the wait_event stuff does.. but mah
15:06 imirkin_: anyways, skeggsb really ought to do one. or mlankhorst. someone who can.
15:07 imirkin_:can't
15:07 imirkin_: or at least i don't know how
15:07 RSpliet: ajax: Fedora already goes down that road, fwiw...
15:08 ajax: maybe sometimes. not at the moment, for f25 anyway.
15:08 RSpliet: ajax: http://koji.fedoraproject.org/koji/rpminfo?rpmID=7783142
15:09 ajax: RSpliet: don't confuse "srpm contains script for creating a git snapshot" with "source tarball is a git snap"
15:09 ajax: note the name of the tarball there...
15:12 RSpliet: ajax: okay, you meant it more pedantic than I expected, fair. But Fedora does cherry-pick patches from git master.
15:13 ajax: http://s2.quickmeme.com/img/62/62f538b129e13afc6c7d9b9278b63f63f4c91e1f8fd1077c36e088039bf538f8.jpg
15:14 karolherbst: ajax: right, and users switch to modesetting because they are scared of git snapshots :O
15:14 ajax: fine with me tbh
15:14 karolherbst: not with me (and honestly every laptop user)
15:15 ajax: why laptop user?
15:15 karolherbst: I still think it is a mistake to downgrade from specific to general code for a ddx, except maybe glamor on top of vulkan might be good
15:15 karolherbst: ajax: power effiency
15:15 RSpliet: duelle: sorry for that little discussion. The best way to raise it with the lead dev is to forward your question to the mailinglist
15:15 karolherbst: *efficiency
15:16 RSpliet: sorry for that extra overhead, but he's notoriously Australian thus in a different timezone :-)
15:16 ajax: karolherbst: can you be a little more specific? does the nouveau ddx have some power saving feature, or is exa really that preferable to glamor, or...
15:16 ajax: (because if glamor is really a loss then ffs fix the 3d driver)
15:16 imirkin_: ajax: as long you support all the new users using the crashy GL impl, that's fine by me
15:16 imirkin_: EXA is rock solid
15:17 imirkin_: GL is soft as lime
15:17 duelle: RSpliet: In general it is not that much effort for me. Just thought that I might not be the only one who has such issues with the distro-provided packages that mainly rely on the latest versions. So my intention was just to ask whether there is some time window when one could expect a (for me) fixed version.
15:18 karolherbst: ajax: doing 2d over OpenGL isn't exactly free
15:18 imirkin_: ajax: separately glamor on intel is slow as balls for me, but no one seems to care because it's for "legacy X applications"
15:18 karolherbst: you have a lot of the opengl runtime checks and crap of things you don'T need within a ddx
15:19 RSpliet: duelle: it's probably somewhere dangling at the bottom of a long long todo. Express your concern and its importance will be reassessed :-)
15:19 karolherbst: I am sure a vulkan version of glamor might turn out to be much more usefull in 5 years than glamor will be
15:19 ajax: it wouldn't be tough
15:19 ajax: most of the magic is in shaders we've already written
15:20 duelle: RSpliet: Okay I'll try it, thank you for the hint.
15:20 ajax: imirkin_: if you've got testcases...
15:20 imirkin_: ajax: for the slowness? xlock -mode wator on a 2400x1920 framebuffer
15:20 ajax: whoa, xlock
15:21 ajax: suddenly i'm wearing flannel and listening to soundgarden
15:21 imirkin_: i've been using it for nearly 2 decades. don't see any reason to change.
15:21 imirkin_: and i like the wator one, which was never ported to xscreensaver for some reason
15:22 imirkin_: (also xscreensaver was a pain to use last time i tried it ... some 15 years ago or so)
15:24 ajax: from a quick read, wator doesn't really look like it's doing anything too crazy
15:25 imirkin_: it causes a ton of glReadPixels to be done
15:25 imirkin_: or ... something
15:25 imirkin_: basically each frame is supposed to "atomically" flip from step to step
15:26 imirkin_: but drawing of the fishes is so slow that it takes like 5s to actually update a single frame
15:26 Tom^: imirkin_: https://lists.x.org/archives/xorg-devel/2016-March/049061.html so it isnt fixed yet?
15:26 imirkin_: Tom^: that was an improvement that dave made
15:26 karolherbst: screensavers are painful
15:26 imirkin_: not sure if it's been pushed
15:26 imirkin_: but with it it went from super-mega-incredibly-godawful slow
15:26 imirkin_: to plain ol' super-incredibly-godawful slow
15:27 Tom^: heh
15:27 imirkin_: but it was a marked improvement
15:27 ajax: i think the only bug in that patch was it got xypixmap handling wrong
15:28 Tom^: imirkin_: seems to exist even a v2 of those patches. commited on august 23rd
15:29 imirkin_: Tom^: ok, well i haven't tested with those specifically
15:30 karolherbst: I am sure there can't be a overall fast glamor implementation, cause reading pixels will kill any performance you got somewhere else, but maybe I am wrong and it will be better for every use case, I am still convinced that using vulkan for this would be actually better
15:30 karolherbst: would be interesting if anybody tried to do that at all
15:31 ajax: i agree with "reading pixels will kill
15:31 imirkin_: the underlying issue is that the performance of operations under glamor differs a lot from "traditional" implementations. this will make older applications not work well because their underlying assumptions are broken.
15:31 ajax: i don't agree that that's a necessary property of glamor
15:31 karolherbst: ajax: well right, there might be "sanely" developed application which won't behave bad
15:31 ajax: no, you misunderstand me
15:32 imirkin_: ajax: well, maybe not necessary, but definitely current.
15:32 ajax: i'm pretty sure if you've got either compute shaders or integer functions in shaders you can do everything but GetImage without reading back
15:33 ajax: does glamor implement that? well, no, not yet
15:33 karolherbst: "computer shaders" as a requiernment for good glamor perf?
15:33 karolherbst: seriously?
15:33 ajax: only because of the planemask
15:33 ajax: which, tbh, even legacy applications don't use
15:34 karolherbst: again, seriously? you want to use OpenGL 4.3 features within a ddx which should be able to run on every kms based driver?
15:35 ajax: i didn't say it'd be mandatory
15:35 karolherbst: no, but mandatory for good performance, maybe I missunderstood you though
15:35 ajax: no, necessary to do _all of X on the GPU_
15:36 ajax: if you're not doing all the corner cases like FillStippled planemasked wide arcs, then you don't need all the new crazy
15:36 ajax: but again: even wator isn't doing that
15:36 karolherbst: k, but then you have the possibility of CPU slow paths within glamor, if your hw doesn't support a required extension for a hw accel path, right?
15:37 ajax: possibility nothing. certainty. those fallbacks are already there
15:37 ajax: so what
15:37 ajax: the more features your gl exposes, the less you hit them
15:38 karolherbst: right, but what I try to say is, that opengl itself has a quite high overhead compared to direct hw things within DDX. secondly, if you hurt perf on old hw due to missing features, it will be more painfull for those, because 1. "native" ddx support dropped for modesetting 2. CPU fallbacks kill power efficency even further
15:39 ajax: i can't "hurt" perf on old hardware any more than it already is
15:39 karolherbst: maybe it is plenty fast if your hw supports like every fast path, might be, I am still not convinced that "glamor" is a sane fallback driver in this case
15:39 ajax: i get what you're saying and i'm suggesting you're describing how glamor happens to be right now instead of what it can be.
15:39 karolherbst: well modesetting with glamor that is
15:40 ajax: and to the point about gl driver efficiency... well, no kidding
15:40 ajax: you want a good gl driver anyway
15:41 ajax: mesa features and performance improve in proportion to the demand of the apps using them
15:41 imirkin_: yeah, that's definitely a good idea (having a good GL driver)
15:41 ajax: if glamor is incentive to get mesa's overhead down
15:41 karolherbst: sure, but opengl has a rather high runtime impact
15:41 imirkin_: patches welcome =]
15:42 karolherbst: maybe it is indeed totally unimportant in the near future, cause cpu/gpu wakes are significantly more expensive than those little gl things they do through glamor
15:42 karolherbst: and waking up itself causes more harm than the actual work
15:44 karolherbst: imirkin: mhh, all I do is making shader compilation more expensive on nouveau, but then again, I also think that a on disc shader cache is a good idea, so that we don't care about shader compilation overhead anymore ;)
19:19 karolherbst: !
19:19 karolherbst: "HUD: Add support for block I/O, network I/O and lmsensor stats" :D
19:19 karolherbst: nice
19:19 imirkin_: lol
19:19 karolherbst: :D
19:19 imirkin_: i was mostly kidding about network i/o when i suggested it
19:19 karolherbst: guess I won't need to add this anymore then
19:19 karolherbst: the lmsensor part is nice though
19:20 karolherbst: allthough it only touches curr
19:20 karolherbst: not in
19:22 imirkin_: could be changed presumably
19:22 karolherbst: mhh I meant power though
19:22 karolherbst: volt is "in"
19:22 karolherbst: ...
19:23 karolherbst: and now I see why I didn't find why ksysguard won't see my power sensor....
19:43 airlied: karolherbst: btw your power argument is kinda bogus since it assumes EXA is any way power efficient
19:44 airlied: where EXA is probably rendering a bunch of stuff on the CPU, that the GPU could do a lot more efficiently
19:44 karolherbst: mhh, true. I usually always mean SNA vs modesetting though
19:45 karolherbst: because SNA is like the only serious comparison you can actually do
19:45 ajax: in #nouveau, eh
19:46 karolherbst: airlied: or am I even wrong with SNA?
19:46 airlied: SNA suffers from the other problem
19:46 karolherbst: yeah complexity mainly
19:46 airlied: it misrenders your desktop randomly
19:46 karolherbst: mhh
19:46 karolherbst: actually not for me
19:47 imirkin_: airlied: pretty sure that's a problem with all DDX's
19:47 ajax: nah, fb gets it right
19:47 karolherbst: I don't have any issues with my intel ddx running dri3 sna so far
19:47 imirkin_: mmmaybe :)
19:47 karolherbst: maybe I am the only one though
19:47 airlied: karolherbst: pick a git snapshot :)
19:47 karolherbst: internet gives me that feeling
19:47 karolherbst: airlied: I have
19:47 airlied: then try that same git snapshot on anther GPU
19:47 karolherbst: currently: PIPE_DRIVER_QUERY_TYPE_AMPS
19:47 karolherbst: ....
19:47 airlied: then pick another git snapshot
19:47 karolherbst: *2.99.917_p20160829
19:48 karolherbst: mhh
19:48 karolherbst: well, I have a hsw one
19:48 airlied: SNA might work on one GPU at any one time
19:48 airlied: the problem is getting it to work across GPUs
19:48 airlied: so a distro can ship it
19:48 karolherbst: well, sna isn't exactly what I call "well supported" though
19:48 karolherbst: doesn't seems like anybody is really interested in getting it to work
19:49 ajax: it's more code than the intel 3d driver
19:49 karolherbst: which I really don't get. sure there are complexity issues and sure you might break other hw if you deveop on one
19:49 karolherbst: ajax: that bad?
19:50 imirkin_: sna is huge.
19:50 karolherbst: I just know that my gpu hardly goes above 1W like ever while normal desktop usage
19:50 karolherbst: usually it is around 0.2W
19:51 karolherbst: *sigh* so there is nothing really good
19:51 karolherbst: seems like I have to wait for vkamor :p
19:51 ajax: desoxy:~/git/mesa% cat src/mesa/drivers/dri/i9?5/*.{c,h,cpp} | wc -l
19:51 ajax: 145570
19:51 ajax: desoxy:~/git/drivers/intel% find src/sna/ -name '*.[ch]' | xargs cat | wc -l
19:51 ajax: 152556
19:52 karolherbst: well to be fair a lot of stuff is in common mesa code
19:52 imirkin_: that doesn't count the compiler(s) in mesa
19:52 imirkin_: or the recently removed format logic
19:52 imirkin_: (which is in src/intel now)
19:52 imirkin_: and blorp
19:53 ajax: to be fair a lot of X is in common xserver code
19:53 karolherbst: for a second I thought my code for my xdc demo is broken :O
19:54 ajax: rather than use it or improve it, sna.
19:54 ajax: seriously the damn thing has its own copy of the software renderer
19:54 imirkin_: i dunno. sna's always worked for me. there are occasional bugs, but ickle has quickly tracked down all the ones i could repro
19:55 imirkin_: this is on SNB, HSW, and SKL
19:55 karolherbst: also the intel ddx actually delivers flicker free prime offloading most of the time
19:55 karolherbst: with dri3 and sna
19:55 karolherbst: without tearing
19:55 karolherbst: there are occasionly issues, but with modesetting it is far worse
19:55 ajax: that's great
19:56 ajax: doesn't change that i have no idea how to start fixing any bug in sna
19:56 karolherbst: as I said, I don't get the feeling anyobdy really cares about SNA, allthough it is great
19:57 ajax: antipathy counts as caring
19:57 imirkin_: really? i think ickle cares.
19:57 karolherbst: you know what I mean
19:57 imirkin_: it's well-supported
19:57 imirkin_: which is what i look for
19:57 karolherbst: I don't get the feeling that "intel" cares at all about sna
19:57 ajax: it hasn't had a release in 21 months
19:58 imirkin_: do i care about either of those?
19:58 airlied: well supported implies you actually release it
19:58 ajax: how am i supposed to know which sha1 is the working version of sna?
19:58 airlied: and take care of stability
19:58 imirkin_: ajax: easy - git head :)
19:58 airlied: instead of implementing new features in git head, and fixes for old features on top of them
19:58 karolherbst: ajax: if intel would care, there would be like 1 or 2 devs more working on it, + proper release management most likely
19:59 ajax: imirkin_: yeah, the smiley means you know i can't take that answer seriously.
19:59 imirkin_: from what i can tell, the reason there's no release is some dumb spat between ickle and danvet
19:59 imirkin_: ajax: yes, i know.
19:59 airlied: imirkin_: I don't think so
19:59 airlied: at least I've never heard about anything blocking a release
19:59 karolherbst: if there ain't a silly reason I would say they do it on purpose then
19:59 karolherbst: :D
19:59 imirkin_: airlied: he says something's broken
19:59 imirkin_: (he's said what, i just don't remember)
20:00 airlied: lots of things it does are broken, that's the problem :)
20:00 imirkin_: no, it was some dumb thing
20:00 imirkin_: like gen3 with some odd configuration
20:00 karolherbst: ...
20:00 karolherbst: yeah reason enough to block a release
20:00 karolherbst: ...
20:00 imirkin_: i didn't say i agreed
20:01 imirkin_: but i also have little influence on the process
20:01 airlied: actually broken GEN3 was what caused a lot of bug reports when we turned SNA on
20:01 karolherbst: wouldn't be suprised if the guy blocking it is in favor of glamor, just to make the situation more intense ;)
20:01 airlied: karolherbst: everyone is in favour of glamor
20:01 karolherbst: not me
20:01 imirkin_: not me! :)
20:01 imirkin_: but again, no one cares about that apparently
20:01 karolherbst: I am in favor of vkamor :p
20:01 ajax: xulkan, please
20:01 airlied: imirkin_: I care less and less about wator every time you mention it :-P
20:01 ajax: pronounced to rhyme with "sulking"
20:02 imirkin_: and everyone is perfectly happy running code in X with an exit() in it
20:02 karolherbst: vkamor is the better term, duh
20:02 airlied: because really it's a screensaver from 20 years ago, build and bridge and let it go
20:02 airlied: next you'll be like RMS emailing yourself webpages
20:02 imirkin_: airlied: too reliant on gmail for that :)
20:02 airlied: I wonder if rms uses email to read gmail
20:03 imirkin_: hehe
20:03 airlied: there've been lots of nicer screensavers developed since then
20:03 airlied: and you know what no screensaver and power off the monitor is the best
20:03 airlied: global warming and all that
20:03 imirkin_: airlied: well it's largely an example
20:03 imirkin_: there are other applications, but the change is more subtle
20:03 imirkin_: that one's just an obvious "this is horrid"
20:04 ajax: the one big thing that makes glamor suck for even modern applications is that we don't have a zero-copy TexSubImage2D
20:04 ajax: so putimage ends up memcpy-bound on the cpu
20:04 imirkin_: can it be done with a PBO somehow?
20:04 ajax: ennnnnh.
20:04 karolherbst: crap, didn'T save the screenshot :(
20:05 ajax: as implemented, when the ddx putimage call completes, the ddx no longer owns the memory containing the image
20:05 airlied: imirkin_: my initial wator fix made other things slow
20:05 ajax: and it will get recycled back into the client read buffers
20:05 airlied: due to some PBO path being hit on amd
20:05 imirkin_: airlied: don't change glamor on my behalf - i won't use it anyways
20:06 imirkin_: i won't use it on i965 because i965 will exit() when it gets confused
20:06 imirkin_: and i won't use it on nouveau because i know too much about how bad the GL driver is
20:07 ajax: which is to say the data is already read into the client buffer before putimage is called, so to zero-copy you'd need to hack up the dispatch loop to recognize long requests and give the ddx a way to allocate where the image data goes
20:08 ajax: doable, but kinda shitty
20:08 ajax: or, you need a way to hint to TexSubImage2D to upload directly instead of trying to queue it into the cs
20:08 karolherbst: :P
20:08 karolherbst: :O
20:08 karolherbst: the heck
20:08 karolherbst: my gpu traped
20:09 karolherbst: triggered by screenshot
22:03 karolherbst: mupuf: do you think it also makes sense to expose the current through hwmon and not just power?