00:00 imirkin: you just need to have its deps in place.
00:00 mupuf: imirkin: try using them on mac os andwindows
00:00 imirkin: yeah, i have. works great.
00:00 mupuf: binutils is sooo out of date on windows...
00:00 mupuf: anyway, gtg :D
00:00 mupuf: see you!
00:01 mupuf: gnurou: have fun figuring out where the issue lies :p
00:01 gnurou: mupuf: yay, between that and the plain black rendering on GM20B, it's going to be a fun afternoon!
00:01 imirkin: gnurou: still haven't worked it out yet?
00:02 gnurou: imirkin: no, and it gets weirder and weirder
00:02 gnurou: but I think I can pin it down to Mesa not doing something it should do
00:02 imirkin: gnurou: well *i* coulda told you *that* :p
00:03 gnurou: imirkin: could have been a kernel issue :)
00:03 imirkin: not if you had a libdrm app that worked
00:03 gnurou: right, that's what I just confirmed
00:04 imirkin: good luck with the cmdstream bisect :)
00:04 gnurou: yippee
00:05 gnurou: I'm trying to see whether I could use pbdma somehow (our internal tools do not seem more useful), but have trouble figuring out the input format it expects
00:06 gnurou: s/pbdma/dedma
00:06 imirkin: demmt
00:06 imirkin: and mmt
00:07 imirkin: dedma is old and dead
00:07 gnurou: envydis has been quite helpful when I was debugging secure boot, so I'm trying to get more familiar with the envytools
00:07 imirkin: envydis isn't a serious improvement over nvdisasm
00:07 skeggsb: it crashes a lot less often than nvdisasm :P
00:07 imirkin: (except that it works for other ISA's as well... and nvdisasm kinda sucks for the G80 stuff since it only supports the compute program format)
00:08 imirkin: oh yeah. nvdisasm aborts on invalid input, which is a bit frustrating too
00:08 imirkin: like when you're fuzzing it ;)
00:09 gnurou: mmm, I don't think valgrind-mmt will like running on ARM, would it?
00:09 imirkin: should be fine i think
00:10 imirkin: one way to find out!
00:20 gnurou: mupuf: Mesa's version detection works as expected on my side:
00:20 gnurou: configure: error: Package requirements (libdrm_nouveau >= 2.4.62) were not met:
00:21 gnurou: Requested 'libdrm_nouveau >= 2.4.62' but version of libdrm_nouveau is 2.4.61
00:21 mupuf: ....
00:21 gnurou: upgrading to 2.4.62 and Mesa compiles just fine
00:21 mupuf: I can't seem to reproduce it
00:22 mupuf: i distclean
00:22 gnurou: what does pkg-config --modversion libdrm returns?
00:22 mupuf: and reconfigure and it compiles nouveau and crashes
00:22 mupuf: 2.4.61
00:23 gnurou: then configure should definitely fail
00:23 gnurou: that's weird
00:24 mupuf: gnurou: try with this script to recompile: http://pastebin.com/NPVvcgCK
00:24 gnurou: mupuf: after the distclean, do you re-run autogen.sh, or just configure?
00:24 mupuf: re autogen
00:26 mupuf: I just make distclean and then launch this script
00:26 gnurou: your script is very similar to what I do (minus the sysroot and cross-compilation)
00:28 mupuf: right, so there is something weird going on
00:28 gnurou: well, that's interesting - if I compile Mesa for my host (which still has 2.4.61), then configure passes
00:29 mupuf: imirkin: did I say anything about fragile? :D
00:29 gnurou: using the same options as your script
00:29 imirkin: mupuf: *more* fragile? doubtful.
00:30 mupuf: as expected, nouveau does not compile, crashing on the missing NOUVEAU_BO_COHERENT
00:30 imirkin: gnurou: i wonder if you've set it for the dri nouveau and not the gallium one
00:30 mupuf: imirkin: that could be a good explanation
00:31 imirkin: where's the patch?
00:31 imirkin: -LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
00:31 imirkin: +LIBDRM_NOUVEAU_REQUIRED=2.4.62
00:31 mupuf: imirkin: no, it is set for gallium drivers
00:31 mupuf: -s
00:32 mupuf: gnurou just copied what the other drivers do
00:32 mupuf: what would "2.4.33 libdrm >= 2.4.41" do anyway? Is it 2.4.33 or 2.4.41? This construction is insane
00:33 imirkin: well, it's libdrm_nouveau >= $version
00:33 imirkin: not sure why you'd have mismatched versions
00:33 mupuf: right
00:34 imirkin: hm, i wonder what PKG_CHECK_MODULES does
00:34 imirkin: i.e. does it fail if the version's not there?
00:35 gnurou: aha, found something interesting in config.log
00:35 gnurou: $PKG_CONFIG --exists --print-errors "libdrm_nouveau >= $LIBDRM_NVVIEUX_REQUIRED"
00:35 gnurou: instead of LIBDRM_NOUVEAU_REQUIRED
00:35 gnurou: mupuf, do you have the same in your config.log?
00:36 imirkin: well, both of you are ending up with --with-dri-drivers=nouveau
00:36 imirkin: since it's part of the default
00:36 imirkin: and both of the things are called [NOUVEAU]
00:36 imirkin: and i bet it doesn't check the second time
00:37 mupuf: gnurou: yes, same issue
00:38 gnurou: imirkin: you are probably right, if I add --without-dri-drivers to configure, it fails as expected
00:38 imirkin: so either that first one needs to be [NVVIEUX] and fix up the dri driver's makefile
00:38 imirkin: or they need to share a single version check
00:39 gnurou: shouldn't they share the same version anyway? since the DRI driver will fail as well
00:39 mupuf: gnurou: unlikely
00:39 mupuf: the DRI driver is well separated from the gallium one
00:39 gnurou: so we should just bump both versions it seems
00:39 mupuf: nouveau_vieux is for very old cardd
00:39 mupuf: s
00:40 imirkin: the dri driver is in src/mesa/drivers/dri/nouveau
00:40 imirkin: it's for nv04-nv2x cards
00:40 gnurou: ah, I see now
00:40 imirkin: that driver is in ok shape... hardly standards-compliant, but enough for q3a :)
00:41 mupuf: gnurou: no, we should fix the build system
00:41 mupuf: I agree with the propositions of imirkin
00:41 gnurou: so I guess the only solution is to rename the DRI driver to NVVIEUX
00:41 mupuf: either we simplify and get rid of NVVIEUX
00:41 imirkin: gnurou: yeah, it's just a couple spots in the makefile
00:42 gnurou: ok, I'm on it then
00:43 imirkin: gnurou: don't worry about it
00:43 imirkin: doing it now
00:45 gnurou: imirkin: even better, thanks
00:46 gnurou: mupuf: in that case I suppose my patch will still apply on top of imirkin's
00:49 imirkin: patch away
01:02 mupuf: gnurou: yep :) probably
01:03 mupuf: do not worry, we've got this covered
01:03 mupuf: imirkin: I will test your patch
01:03 mupuf: thanks!
01:42 imirkin: mupuf: any objections? if not, i'll push
02:34 mupuf: imirkin: let me read it first!
02:35 mupuf: sounds trivial-enough
02:36 mupuf: let's see if it is fixes my issue, becuase I doubt it will
02:36 mupuf: unless nouveau-vieux is compiled by default
02:43 mupuf: imirkin: ok, Tested-by: Martin Peres <martin.peres@free.fr
02:48 mupuf: you can push, and I'll push the patch from gnurou
05:14 xexaxo: seems like I've missed the interesting "XXX build system is better than YYY", but to sum it up (iirc Ilia said this ages ago) - they all suck.
05:14 xexaxo: the bigger problems come when we don't know how to use it/them :P
06:09 RSpliet: xexaxo: meh, I have little objections to CMake and ANT... I guess they all fail when you hit a corner case
06:15 sooda: hey what's up with these if()s with commas inside them?
06:15 sooda: like this: if (ret = -ENOMEM, !(ctor = malloc(sizeof(*ctor) + size)))
06:16 sooda: what's the purpose of this kind of odd obfuscation? i'd write that like so: ret = -ENOMEM; if (!(ctor = malloc(sizeof(*ctor) + size)))
06:16 sooda: i've seen lots of these in both the kernel driver and libdrm, and this is just difficult to read
06:29 xexaxo: RSpliet: for a simple projects they all work fine.
06:30 xexaxo: but once you have ~50 configure options, with dozens of permutations for the actual output... then things go hairy rather quickly.
07:02 mupuf: sooda: where do you see that?
07:04 mupuf: I did not know that you could have multiple instructions within a if, that's messed up!
07:04 sooda: that one was from nouveau_object_new() in libdrm
07:04 sooda: it's just the basic comma operator, only the last one gets evaluated as the condition
07:04 sooda: let me see if i can grep some more from nvkm... :P
07:05 mupuf: I have never seen darktama do that before
07:05 mupuf: err, skeggsb
07:05 sooda: haha
07:05 sooda: $ grep -RI 'if (ret = ' *|wc -l
07:05 sooda: 56
07:05 sooda: so this pattern is quite common
07:06 sooda: i remember having seen some lines with something different from ret, too
07:06 mupuf: hmm
07:06 mupuf: I wonder what is the purpose of this
07:06 pq: if ((ret = foo())) is something I've seen, but the comma thing is pretty wild
07:06 sooda: there must be some purpose since this is so common
07:06 pq: I bet bad habits
07:07 sooda: pq: yeah that i'd accept, but comma there is just unacceptably wild :D
07:07 mupuf: pq: how would one get this habbit?
07:07 pq: mupuf, no idea :-P
07:07 mupuf: and most of the time, he does not use this construct
07:08 sooda: if (ret == 0 && (ret = -EINVAL, notify->size == reply)) {
07:08 mupuf: he must have a good reason. Let's wait for him to wake up and ask him!
07:08 sooda: just.. come on, that's beyond slightly unreadable
07:08 pq: sooda, oh, but that's a completely different thing
07:08 mupuf: indeed
07:09 mupuf: it avoids breaking the if in two
07:09 sooda: if (ret == 0 && (ret = -EINVAL, notify->size == reply)) { code; i'd modify to if (ret == 0 && notify->size == reply) { ret = -EINVAL; code;
07:09 sooda: oh yeah that indeed isn't 100% the same thing
07:09 sooda: might be in this case, let's see..
07:10 sooda: that's clever, of course. but clever is not always a compliment regarding code readability :P
07:11 pq: I agree on that
07:11 sooda: i'd like to use lots of time to write comments in the code to describe a) why some funky things are going on and b) why some functions exist in general and what's their purpose
07:12 sooda: but that would require understanding the code first. i've found out that this is a difficult task for anyone else than the original author :/
07:12 pq: what's stopping you?
07:12 pq: heh
07:12 sooda: and gotta code some features too :P
07:13 mupuf: the object part of the design of nouveau drm is ... obscure
07:13 mupuf: it got much better recently but the design is not finished yet
07:13 sooda: heh
07:13 sooda: btw i drew a pic
07:13 mupuf: so ben has not taken the time to document it yet
07:14 mupuf: we got promised some docs at some point though :D
07:14 mupuf: oh, cool!
07:14 sooda: http://fpaste.dy.fi/5Qc/disp
07:14 mupuf: care to share it?
07:14 sooda: just a few minutes with grep and graphviz, and manual work so not probably 100% accurate
07:14 sooda: some kind of inheritance diagram
07:14 mupuf: I see
07:14 mupuf: therm is messed up
07:15 mupuf: but there is not much choice on this
07:15 sooda: what puzzles me here is that why fifo_base is a nvkm_gpuobj when all the other similar things are engctx's
07:16 sooda: trying to fix some error handling, mmu faults, but fifo can't find the failing engine context (= some kind of channel object)
07:16 mupuf: if fifo_base is used only for pfifo, then it makes sense
07:16 mupuf: fifo is not an engine, but the command dispatcher
07:16 mupuf: so there is no context for pfifo
07:17 sooda: what's a nvkm_fifo_chan?
07:17 sooda: why is that a namedb and what is this namedb exactly and.. :D
07:17 sooda: i could go on with these stupid questions for a day
07:17 mupuf: oh, the namedv
07:17 mupuf: b
07:17 mupuf: I had forgotten about that
07:17 sooda: looks like a special case
07:18 sooda: since the *_fifo_chans ("*" in the diagram is, btw, a specific implementation for some particular chip) look quite like the context objects but not exactly, there must be something shady going on with it
07:19 sooda: i was trying to fix gk104_fifo_intr_fault() (could never get to gk104_fifo_recover() since the "engctx" ptr is always null) but got stuck since i'd need the channel instance there to recover it, but the channel is never a context on the fifo engine at that point
07:20 sooda: at least on tegra, this function has never worked, dunno if it's different on discrete gpus :P
07:20 mupuf: IIRC, there is the concept of object found inside the gpu
07:20 mupuf: and nouveau is designed to be very close to the hw
07:20 mupuf: that's what I have been told
07:21 mupuf: and I got lost like you are when I started working on updating the context management for pgraph
07:22 mupuf: sooda: you know about http://envytools.readthedocs.org, right?
07:22 mupuf: and envytools in general
07:23 sooda: i know that it exists but haven't played with it yet
07:23 mupuf: The “objects” are individual pieces of functionality of PFIFO-controlled engine. A single engine can expose any number of object types, though most engines only expose one.
07:24 mupuf: so, namedb would be the one remembering the different objects allocated?
07:24 sooda: ah that yeah
07:24 mupuf: well, apparently it is a pre fermi thing
07:25 sooda: i've found that these "names" are kind of like the drm names, some u32's that identify different objects
07:25 sooda: in the namedb
07:30 mupuf: sorry, can't find anything on this
07:33 sooda: this engctx somehow looks like a software construct on top of the gpuobj that is some kind of a memory buffer, i just can't see why the fifo things live under gpuobj and not engctx
07:33 sooda: may also be related directly to some hw thing i just didn't find yet :P
07:34 imirkin: sooda: tbh i'm not a fan of the , thing either. but ben likes it.
07:34 sooda: this codebase is interesting. like playing a dungeon crawler game that is just a big maze :)
07:35 imirkin:agrees
07:35 sooda: find one lock (unknown code) and run around in the maze to find the key (the right piece of information)
07:35 sooda: i've been trying to draw a map though :)
07:35 imirkin: how familiar are you with the underlying nvidia hw btw?
07:43 sooda: if you look at the pic again (http://fpaste.dy.fi/5Qc/disp), neither nvkm_fifo_base nor nvkm_fifo_chan inherit from nvkm_engctx
07:43 imirkin: right
07:43 sooda: i've got a hack stashed somewhere that modifies that a little but it didn't work
07:44 imirkin: why would you want fifo_base to inherit from engctx?
07:44 imirkin: the fifo is a funny beast
07:45 imirkin: which i'm sure you understand better than i do
07:45 imirkin: but it basically has its own abstractions to deal with the crazy iirc
07:46 sooda: because nvkm_fifo_base is really a fifo context, which would make sense to be something channel-related living in the fifo
07:46 sooda: hmm no
07:46 sooda: this messes up my head again, just a asec
07:47 sooda: actually yes :D
07:47 sooda: gk104_fifo_context_ctor looks like a channel.. thing. but then it makes gk104_fifo_base objs
07:47 imirkin: ok so... for example the gr *class* has its own context type, but it also has a fifo_context type
07:48 sooda: the gr context i understand and got a somewhat matching type in nvgpu already, but this nouveau_channel/fifo engine/channel info inside fifos structure is .. complicated
07:49 imirkin: yeah
07:49 imirkin: i guess a gr fifo context is different from a non-gr fifo context?
07:49 sooda: what do you mean by a gr fifo context
07:50 sooda: gtctx?
07:50 imirkin: erm
07:50 sooda: there's gr and then there's fifo
07:50 imirkin: like when you bind the gr engine to the fifo? i guess starting with kepler you can only have one engine bound...
07:51 imirkin: i'm well outside of my knowledge zone though. sorry. you'll have to wait for ben or figure it out yourself
07:53 sooda: thanks anyway, my problems are somewhere between not understanding the mapping between nvkm objs and hw and also not seeing how these contexts are use in general
08:09 imirkin: sooda: btw, is one point of confusion that there are both fifo channels and fifo contexts?
08:09 sooda: kind of. is the fifo context somehow closer to hw?
08:10 sooda: or actually loaded to the fifo when the channel is the mem block and such?
08:13 imirkin: not sure how you'd define distance :p
08:13 imirkin: i'd look at what the relevant ctor/init functions do
08:13 imirkin: and try to map it to things you know about
08:14 imirkin: so like gk104_fifo_context_ctor writes some address to offset 0x200 in the gpuobj
08:14 sooda: yeah, that's what i've been doing :p
08:14 imirkin: (the pgd addr)
08:14 imirkin: so i think that's somehow linked to a vm context?
08:14 imirkin: yeah, the page tables start at 0x200
08:14 imirkin: i think
08:15 sooda: these magic numbers are inconvenient and that they're *4 compared to nvgpu headers. luckily ken started with the official header publication
08:15 imirkin: while if you look at gk104_fifo_chan_ctor, it writes the first 0x100 bytes of the gpuobj with some very fifo-seeming type things
08:15 sooda: sometimes hard to compare, but it'll get easier when i actually start to change things instead of running around in circles, i guess
08:15 imirkin: as for the magic names vs magic numbers, i used to think names would be better, but now i'm on the numbers side
08:16 imirkin: names are pretty meaningless without docs
08:16 imirkin: and numbers are *way* easier to compare to traces
08:16 sooda: well that's true :P
08:16 imirkin: when i was trying to do stuff in dispnv04, which uses names, i had to keep looking up what number each name was to try to compare to the traces
08:17 sooda: just modify the trace automagically to contain the names!
08:17 imirkin: number <-> name mapping changes over time
08:17 imirkin: and we do automatically look things up in rnndb
08:17 imirkin: but most of it would just end up as ENGINE_UNK9873
08:17 imirkin: which is kinda meaningless
08:18 sooda: :/
08:18 sooda: that ken's patch would have lots of numbers but don't know if some that you see in the traces would stil be missing
08:18 sooda: still
08:19 imirkin: i've given him some feedback, but tbh i'm not entirely sure what his goal is
08:19 imirkin: if his goal is to publish a set of gpu register number <-> name mappings, that's great
08:19 imirkin: if his goal is to get that integrated into the nouveau codebase... that might require some more careful thought.
08:20 imirkin: sooda: btw, take a look at the 'lookup' utility in envytools
08:20 imirkin: e.g. $ lookup -a gk104 200
08:20 imirkin: PMC.ENABLE => { 0 }
08:20 sooda: yeah. integrating it there would tremendously help internal work here in nvidia, but since the actual manuals are still closed, well.. :/
08:21 imirkin: e.g. $ lookup -a gk104 200 89374
08:21 imirkin: PMC.ENABLE => { PXBAR | PMEDIA | PIBUS | PCOPY0 | PFIFO | PGRAPH | PVLD | 0x80200 }
08:21 sooda: woop, looks neat. thanks, i just haven't had a time slot for studying that yet
08:21 imirkin: so when you need to know what register X is, pretty easy to look it up in rnndb, without having to constantly update the code for changing names :)
08:23 imirkin: and i'd be perfectly happy to see ken's thing update rnndb... he had an earlier attempt, but it was fairly dirty (due to being autogenerated and your info also having annoying junk in it)
08:25 imirkin: and also since it was for a single family whereas we annotate each of our symbols with the list of gpu/class variants it exists on
08:26 sooda: mm. as ken said, we'd like to switch to nouveau internally at some point for tegra development but with the magic numbers everywhere it's gonna be difficult to maintain compared to nvgpu :P
08:27 imirkin: yeah... i guess there's some schizophrenia within the org wrt opening things up and closing them off :)
08:27 imirkin: i'm rooting for the "open things up" personality
08:28 sooda: there's probably lots of legal and political issues that i wouldn't want to hear of
08:29 sooda: i'm on the "let's just write code together, dammit!" side :P
08:29 sooda: brb ->
08:31 imirkin: i'm also sure it'd be fine to use whatever names you guys wanted in the *gk20a and *gm20b files... it's unlikely we'd ever touch them, and even if we did, we wouldn't really be worrying about looking at traces.
09:08 sooda: yeah, unfortunately a lot of code is shared from the other files/chips :P
09:09 sooda: most of what i've written now for testing is in fifo/gk104.c and gr/gf100.c
09:13 imirkin_: yeah
09:13 imirkin_: although i see it as fortunate :p
09:15 sooda: yes mostly :) but regarding that changing all the numbers to names thing, it wouldn't be if you don't want the change :)
09:17 imirkin_: yeah
09:17 imirkin_: well
09:19 imirkin_: with the numbers thing, the issue is mainly around unknown registers
09:19 imirkin_: if you see an unknown register, it's just a number
09:19 imirkin_: but the numbers have meaning too -- the registers aren't laid out willy-nilly
09:19 imirkin_: adjacent regs often have adjacent meanings
11:14 zerwas: After installing Nouveau I experienced 4 freezes of the system today, I had to use magicsysrq to reboot every time. In dmesg I see hundreds of messages in the form of "nouveau E[ PDISP][0000:01:00.0] 0x0e54: 0x00000000". Are these bad messages?
11:15 imirkin_: which gpu?
11:15 imirkin_: anyways, they're certainly not *good* messages.
11:15 zerwas: imirkin_: GF119 [GeForce GT 610]
11:17 zerwas: This happens on Ubuntu 15.04 using the xorg-edgers PPA. Nouveau version 1:1.0.11+git20150528.27234dbe-0ubuntu0sarvatt~vivid
11:18 imirkin_: iirc there was some patch to avoid disp hangs due some sort of cursor-related thing as i recall
11:18 imirkin_: but... i can't seem to find it
11:19 imirkin_: skeggsb: do you have any recollection what i'm talking about?
11:19 imirkin_: i thought i attached it to some bug but i can't find it now
11:19 imirkin_: zerwas: it would be helpful if you could pastebin a dmesg that includes some of those errors
11:21 zerwas: Sure, here you go: http://0bin.net/paste/fzHWSziO5up9pZoS#3ekVFiiaKQ7gJv0ckyMUNL-dYLFEEuFzMCWUiZisfLD
11:22 imirkin_: unfortunately that's all gobbledygook to me, but i think skeggsb has a way of making sense of it
11:33 Karlton: would reclocking make a difference?
11:34 imirkin_: in what?
11:34 Karlton: freezing
11:34 imirkin_: reclocking can cause freezes if done improperly
11:34 imirkin_: either immediately or down the line
11:36 Karlton: nouveau actually freezes more often for me if I watch a video or run a game on the lowest pstate value
11:36 Karlton: or run something heavy like kde
11:36 imirkin_: heh
11:37 imirkin_: we probably don't properly wait for something
11:37 imirkin_: and going faster papers over it
14:30 gsedej: hello! What is current solution for "PRIME" graphics? Is Bumblebee still active? (last update was april 2013)
14:31 imirkin_: bumblebee is not the preferred solution with kernels 3.13+, at least for nouveau
14:31 imirkin_: nouveau should auto-suspend the gpu when it's not in use
14:31 imirkin_: unless you've explicitly disabled runpm
14:31 gsedej: how to offload?
14:32 imirkin_: gsedej: http://nouveau.freedesktop.org/wiki/Optimus/
14:32 gsedej: (i have GM108M, which is work in progress AFIK)
14:33 imirkin_: well, unless you're trying to play with nouveau, you're probably better off sticking to your intel gpu
14:33 gsedej: I can use nvidia-prime, but i have to login/logout and it works bad for external monitor
14:33 gsedej: but I guess i won't get support here
14:33 imirkin_: the GM108 isn't yet fully supported by nouveau
14:33 imirkin_: and even if it were, it boots to super-low clocks and we don't have reclocking on maxwell
14:33 imirkin_: so chances are pretty good it'd be slower than the intel gpu
14:34 gsedej: is it possible to use nvidia driver just for single app if I may ask?
14:34 gsedej: whitout logging in and out
14:36 imirkin_: i've heard of a thing called 'primusrun'. i have no idea what it is or what it does.
14:36 imirkin_: but i'm sure google can help.
14:36 gsedej: I know nouveau would be slower vs intel (if worked)....
14:36 imirkin_: with nouveau, you'd just do DRI_PRIME=1 foo-applciation
14:38 gsedej: I know, I have laptop at work which has intel-AMD combination and DRI_PRIME works. But just recently AMD become much faster than intel
14:39 imirkin_: probably dpm started to work :)
14:39 imirkin_: it's pretty hard to get right when you have docs, apparently
14:39 gsedej: dpm was working but just the performance was not much better
14:39 imirkin_: without docs... it can be rather tricky.
14:39 imirkin_: oh
14:40 gsedej: anyway...
14:40 gsedej: are there PRIME nvidia GPU which run faster with nouveau vs intel?
14:40 imirkin_: probably :) keplers have reclocking, so if you find one that works with reclocking nouveau should be in the same range as the nvidia driver perf
14:40 imirkin_: well, probably like 60-80% of the blob perf
14:41 imirkin_: which should still beat intel hands-down
14:43 gsedej: oh, so situation is quite similar to the radeon VS catalyst. nouveau really advanced since I was using nvidia last time (GF 8600GT)
14:43 gsedej: and without documentation that radeon has
14:44 gsedej: btw, do you have mmiotrace of GM108M?
14:44 imirkin_: yep
14:44 gsedej: ok, so now it's up to nvidia to release firmware?
14:44 imirkin_: skeggsb just has to process it and figure out what init it does differently vs GM107
14:45 imirkin_: nah, we have firmware that should work on it... starting with linux 4.1
14:45 gsedej: oh great
14:45 imirkin_: you should be able to enable it with a tiny patch to drm/nouveau/nvkm/engine/device/gm100.c and it ought to work ok
14:46 imirkin_: just add a "case 0x118:" right above the "case 0x117:"
14:47 gsedej: btw, now i am on Ubuntu 14.04 kernel 3.13, eDP1 (laptop) and HDMI1 are working flawlessly on intel. Does this mean HDMI is wired to intel and nvdidia does not have physical output at all?
14:49 gsedej: I saw "case" patch in GM106m bug thread :) I just dont feel to compile gpu drivers :D
14:50 imirkin_: that's right
14:50 imirkin_: the GM108's i've seen are pure accelerators
14:50 gsedej: anyway, imirkin_ thanks you and all other nouveau contribuors for great work!
14:52 gsedej: one last thing. what is "VIRTUAL1 disconnected" (from xrandr)?
14:53 imirkin_: some stupid intel thing
14:54 gsedej: ok, thx
15:21 pmoreau: imirkin_: Your spir branch is much appreciated to understand where to register things and how to organise it. :-)
15:23 imirkin_: pmoreau: well, don't go too far with it... i failed at getting it up and running
15:23 pmoreau: :D
15:23 imirkin_: pmoreau: basically i took the simplest thing with a for loop and couldn't get it to work
15:23 pmoreau: For now it also follows how TGSI registers itself, so that should be ok at least.
15:24 imirkin_: pmoreau: another approach is to do LLVM C -> PTX using llvm, and then use ptxas to go PTX -> shader code. but i dunno *exactly* what ptxas outputs, esp wrt relocations, etc
15:24 imirkin_: pmoreau: also that impl has *serious* issues with the out-of-ssa thing. i was hoping i could just do it without thinking too hard, but mroe thought will be rquired
15:25 pmoreau: There is an nv50_ir_ssa file, doesn't it work?
15:25 pmoreau: Or which impl are you talking about?
15:25 imirkin_: pmoreau: i mean... spir is in ssa form
15:26 imirkin_: nv50 ir, on input, has to be non-ssa
15:26 imirkin_: since as part of computing ssa, nv50_ir_ssa computes all sorts of other useful bits required for RA and other things
15:26 imirkin_: but going out of ssa isn't as simple as it looks
15:26 pmoreau: So, non-ssa -> nv50 ir -> nv50 ir ssa?
15:27 imirkin_: well... ssa -> nv50 ir
15:27 pmoreau: But... Didn't you just said that nv50 ir on input should be non-ssa?
15:28 imirkin_: right
15:28 imirkin_: hence the "->" :)
15:29 pmoreau: SPIR-V SSA -> magic_box_1 -> NV50 IR -> nv50_ir_ssa -> NV50 IR SSA then?
15:29 imirkin_: well, the nv50 ir is just an ir... it supports ssa
15:29 imirkin_: but you there's a ssa-ification stage in codegen
15:29 imirkin_: however the various lowering passes aren't expecting the input to be ssa
15:30 imirkin_: and will do non-ssa things
15:30 imirkin_: so it's easiest to just go out of ssa while moving to nv50 ir
15:30 pmoreau: Right
15:30 pmoreau: But it later gets back again to ssa? When is nv50_ir_ssa used?
15:31 imirkin_: see the general flow in nv50_ir.cpp
15:32 imirkin_: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp#n1200
15:33 pmoreau: Ok, I understand better
15:35 imirkin_: it's also questionable whether i should have used the c++ llvm api
16:19 mupuf: gnurou: pushed!
16:19 mupuf: so sorry, I had forgotten about this
16:19 mupuf: at some point, you know, you could get the freaking commit rights
16:24 imirkin_: of course now this means that no one will be able to build nouveau from git for a while
16:24 imirkin_: i sorta wish this had waited a while until 2.4.62 was a real thing, rather than a super-recent release that hadn't made it to any package repos
16:26 imirkin_: gentoo's only up to 2.4.60 for example
16:26 imirkin_: not that i can't make my own ebuild... wtvr
16:28 imirkin_: or i'll just revert that commit locally... yeah, that seems like the simpler thing
16:32 mupuf: imirkin_: ... what the fuck is gentoo doing?
16:33 mupuf: pretending to be testing anything? :D
16:33 imirkin_: dunno. they're really far behind on mesa as well.
16:33 mupuf: ...
16:33 imirkin_: certainly not
16:33 imirkin_: just... lack of manpower
16:33 imirkin_: or the thing didn't build or... who knows
16:33 mupuf: you could try again to get the maintainership for this
16:33 imirkin_: haha, that seems unlikely
16:33 imirkin_: there's some sort of insane process
16:34 imirkin_: maybe not, dunno.
16:34 mupuf: insane process + fewer and fewer users = even more fewer and fewer users
16:34 imirkin_: even more fewer and fewer? :p
16:34 imirkin_: anyways, i don't really care about the # of users
16:34 imirkin_: i could be the last gentoo user for all i care
16:35 imirkin_: it's not a social thing :p
16:36 mupuf: you like my english, right?
16:36 mupuf: it was meant as a joke though
16:36 mupuf: anyway, still need to maxwell in reator?
16:36 mupuf: hakzsam asked me for an nvc0
16:36 imirkin_: i still haven't touched it
16:37 mupuf: ah ah, ok
16:37 imirkin_: told you i was slow!
16:37 mupuf: will move it to the second pcie slot
16:37 mupuf: hehe :D
16:37 imirkin_: sgtm
16:37 mupuf: no hurry!
16:37 mupuf: I am even slower!
16:37 imirkin_: i've been fixing a lot of bugs lately though
16:37 mupuf: but hey, it is summer for a month here! Better have fun!
16:37 imirkin_: so it's not all bad
16:37 mupuf: indeed! still hyper active :)
19:11 gnurou: mupuf: thanks! I will get more familiar with Mesa before asking for commit rights though :P
19:12 gnurou: didn't know about that lookup tool btw - pretty nice. Would be awesome if we could plug it with our own info/documentation. Definitely something to point out to Ken.
19:13 imirkin: gnurou: well it just reads from the xml-formatted files...
19:13 imirkin: it defaults to some domain i think, but you can supply a different one
19:13 gnurou: yeah, so the issue is providing said xml-formatted files
19:13 imirkin: iirc he actually sent rnndb patches
19:13 imirkin: so he at least knows about rnndb
19:13 imirkin: if not the lookup tool itself
19:14 imirkin: we can also generate headers from rnndb
19:14 imirkin: (there's a headergen tool or so)
19:14 gnurou: right - but iirc was exclusive to gk20a, so other chips could not benefit from it
19:14 imirkin: right.
19:14 gnurou: that sounds like the right thing to do: 1) rnndb 2) header 3) whatever else you want
19:15 gnurou: providing headers directly is not necessarily easier, and has a more limited scope
19:15 imirkin: but it'll be difficult to get headergen to spit out the *identical* headers you want
19:15 gnurou: in that case maybe we can extend it, or write a different tool
19:15 imirkin: although it can be modified... i use it rarely to sync the 3d stuff
19:15 imirkin: (mostly because the 3d stuff doesn't really change with time)
19:22 gnurou: imirkin: btw, what do you think of https://github.com/Gnurou/mesa/commit/96ae4c2bfcaf36083543f9d91c6b5b14ebdf70c5 ?
19:22 gnurou: imirkin: this is my last out-of-tree Mesa patch, and you reported that a while ago IIRC
19:23 imirkin: oh yeah. i like it.
19:23 imirkin: good idea, former-me.
19:23 gnurou: hehe
19:24 imirkin: yeah, coz there's only gart... no vram... so it should be just as fast to just map the texture and write to it, yeah?
19:24 imirkin: oh but... tiling
19:24 gnurou: I may not fully understand what this achieves though - does it mean that on shared-memory systems it is better not to use hardware-blits for texture transfers that involve format conversion?
19:24 imirkin: well, this isn't about format conversions
19:24 imirkin: imagine that you want to write data to a texture
19:24 imirkin: how do you do it?
19:25 imirkin: if the texture is sitting in vram, it's faster to write it to memory and then let the gpu worry about copying it into place
19:25 imirkin: if it's all cpu-accessible with the same speed as otherwise, might as well just do the memcpy
19:26 gnurou: ah, it's that simple :) the definition of PREFER_BLIT_BASED_TEXTURE_TRANSFER got me lost somehow
19:26 gnurou: I have been running with this patch on Tegra for ages, so if you like it, I can submit it
19:26 gnurou: and finally close our Tegra branch \o/
19:27 imirkin: take a look at st_TexSubImage
19:27 imirkin: basically if none of the fallback conditions are met, it does a blit
19:27 imirkin: otherwise it maps the texture and writes to it
19:28 imirkin: if there's any format conversion going on, it will go to the fallback path anyways
19:28 gnurou: right
19:28 gnurou: so that seems to be a safe optimization
19:29 imirkin: yeah. otherwise it will write the texture into a staging texture first, and then blit that
19:29 imirkin: that makes sense when vram is far away, but not when it's all GART-only
19:29 gnurou: absolutely. warming git send-email. thanks for the explanation
19:31 imirkin: i wonder if it'd make sense to set vram_domain to gart on the other IGP's... like NVAA/NVAC/NVAF
19:31 imirkin: they all have stolen "vram" memory
19:32 imirkin: which we have to use for scanout and such, but for the rest of it...
19:33 imirkin: o well. hard to care.
19:33 gnurou: mmm if that fake VRAM does not have a faster path than the rest, then it probably would make sense indeed
19:33 imirkin: and it's usually pretty small
19:34 imirkin: so there's a lot of needless motion
19:34 imirkin: it's all system memory
19:34 gnurou: yep
19:34 imirkin: and if we were really brave, we'd look at doing that on NV4C/NV4E
19:35 gnurou: fake VRAM could only be limited to scanout buffers and instmem
19:35 imirkin: but we're not that brave :)
19:35 gnurou: and all objects allocated in the GART domain
19:37 gnurou: anyway, patch sent
19:39 imirkin: got it. will move the thing back to the boolean segment of the caps, but otherwise lg
19:40 imirkin: will push shortly... just build testing in case the unthinkable happens
19:42 gnurou: no hurry - thanks!
19:45 imirkin: ugh. and now i have a terasology trace which for some reason doesn't show the background on nv50, but works fine on nvc0. grrrrr.
19:53 imirkin: gnurou: pushed
19:54 gnurou: imirkin: thanks!
19:55 imirkin: and the terasology thing is something i broke recently
19:55 imirkin: that's positive.
19:55 pmoreau: Grrrr... Apparently reading a binary file is too complicated for me... First 4bytes are fine, but the 5th one doesn't want to be read correctly.
19:58 imirkin: pmoreau: ...?
19:58 pmoreau: I should probably go to sleep! :D
19:58 imirkin: 5am? probably getting to be that time...
19:59 pmoreau: Writing the parser from binary SPIR-V to generate SPIR-V structure
19:59 pmoreau: Well, the sun is already up
19:59 imirkin: i thought there already was a parser somewhere
20:11 pmoreau: I should not write bytes in decimal format obviously! --"
20:12 imirkin: that's probably for the best
20:31 imirkin: RSpliet: http://hastebin.com/pubufukefi.avrasm ;(
20:33 imirkin: and my fixup from 01d3b750 does not appear sufficient... gonna do a diff to see what's up
20:34 imirkin: at least i feel fully justified in making you split those changes apart!
20:41 imirkin: RSpliet: it appears that the low bits of the immediate overlap with the src2 register id
20:46 imirkin: ahh, there ya go
20:46 imirkin: i guess the bottom bits of a float are actually good for something. who knew.
21:16 imirkin: RSpliet: fyi i fixed it with http://cgit.freedesktop.org/mesa/mesa/commit/?id=c3215ef204c0fdfc44230adbd423720169d44dcb
21:22 imirkin: RSpliet: also according to envydis it appears that that mad form only exists for small regs (< 64)