00:56 megari: Congratulations for reaching GL 4.0! Or is it actually 4.1 for nvc0?
00:58 imirkin: 4.1
00:58 imirkin: although i cut some corners on tess... some of the crazier piglit tests fail
00:58 imirkin: unigine heaven runs though, which is pretty good.
00:59 megari: Right. I read somewhere that GL3.txt is not quite in sync with reality regarding GL_ARB_shader_precision.
00:59 imirkin: yeah, it's basically a no-op extension
01:06 karolherbst: hi all :)
01:07 karolherbst: mupuf: are you up for some experimets to find out how we can change link width on kepler+ chips?
01:10 imirkin: karolherbst: if you're up for it, i could use some GK10x mmt traces of a few piglits with 34x blob version
01:10 imirkin: see history for which ones
01:10 karolherbst: can't do traces here :/
01:10 imirkin: ah ok
01:10 karolherbst: of I do anything wrong all time
01:10 karolherbst: *or
01:10 karolherbst: got some null pointer stuff
01:10 karolherbst: don't know why
01:11 imirkin: mmt traces?
01:11 imirkin: you did them before...
01:11 karolherbst: ahh no mmt is fine :/
01:11 karolherbst: got confused the last time too
01:11 karolherbst: I helped imirkin with one test already :D
01:11 karolherbst: yeah sorry
01:11 imirkin: yeah... look at history for the ones i asked buhman about
01:11 karolherbst: mmiotraces are bad here
01:13 karolherbst: okay
01:14 karolherbst: ohhh
01:14 karolherbst: you are imirkin :D
01:14 karolherbst: thought you were mupuf
01:14 karolherbst: sorry for that
01:15 karolherbst: imirkin: four runs?
01:15 imirkin: all coming together now? :)
01:15 imirkin: 4 diff tests, yeah
01:16 karolherbst: currently checking your LINK_WIDTH commit
01:16 imirkin: hoping that between the 4 of them i'll see all the things i care about
01:16 karolherbst: seems like the blob isn't interessted that much in that reg
01:16 imirkin: it's a 2-phase write, same as the other one
01:16 imirkin: first you write the new width, then you write the commit bit
01:17 karolherbst: yeah, saw it already
01:18 karolherbst: but the first time the blob reads it is with nv86
01:18 karolherbst: then nv94
01:18 karolherbst: nothing in nv92
01:18 karolherbst: or before
01:18 imirkin: yeah... i was just assuming about nv41
01:18 imirkin: based on... adjacent registers :)
01:18 karolherbst: I see
01:18 karolherbst: but again
01:18 karolherbst: on nvc0 there is also nothing
01:18 imirkin: i should whip out a nv4x and see if it's there
01:19 karolherbst: but on nvc8 there is
01:19 karolherbst: imirkin: do you think we could forse the blob to "downgrade" a 16x card by plugging in a lot more 16x cards?
01:20 imirkin: no, the claim is that you can adjust it from nvidia-settings
01:20 karolherbst: mhhh
01:20 imirkin: or using coolbits
01:20 karolherbst: I can't do that
01:20 karolherbst: maybe wrong coolbits value
01:20 karolherbst: currently I have set it to 8
01:24 karolherbst: forgot to downgrade blob :/
01:24 gcr2: Hello, I have Nvidia GT-630 and use ArchLinux. I installed xf86-video-nouveau, mesa-libgl, lib32-mesa-libgl and I have white strips on screen. http://imgur.com/Q3VIyT2,MteBlSP,BJBpxzu How can resolve it?
01:25 mupuf: imirkin: is tesselation working properly now?
01:25 imirkin: mupuf: on fermi, yeah... no more blue splotches
01:25 imirkin: mupuf: haven't tested kepler
01:25 mupuf: nice!
01:25 mupuf: is ""
01:25 gcr2: it's nightmare..strips everywhere..
01:25 mupuf: gk110/ir: fake BAR support the fix?
01:26 imirkin: mupuf: no, that was just a dumb thing to get the barrier piglits to not assert
01:26 imirkin: mupuf: http://cgit.freedesktop.org/mesa/mesa/commit/?id=77672cdb64e9c19e974fe5985050709fc317498e
01:26 mupuf: imirkin: lovely
01:26 mupuf: you figured it out yourself then?
01:26 imirkin: gcr2: can you pastebin dmesg and xorg log
01:26 imirkin: mupuf: yeah. although by pure coincidence. not sure why i was even looking at that code.
01:27 gcr2: imirkin: ok, wait a minute
01:27 mupuf: imirkin: anyway, congrats!!
01:28 mupuf: Hopefuly maxence will manage to help for the atomic counters
01:28 imirkin: mupuf: thanks :)
01:28 imirkin: mupuf: i'm not holding out hope... he didn't seem to really be working on it
01:28 mupuf: but I guess image load store is going to be a bitch
01:29 mupuf: imirkin: his mentor seems ok with the work, last I spoke to him
01:29 mupuf: they may have been working in private
01:29 imirkin: maybe.
01:29 imirkin: yeah, images are going to be a big thing... in part because they're totally different on fermi and kepler
01:29 gcr2: imirkin: http://pastebin.com/cfkk4xay http://pastebin.com/rEg2S0uC
01:30 imirkin: gcr2: hm, well you seem to be running a pretty up-to-date system...
01:31 imirkin: gcr2: are you, by any chance, running nouveau ddx from git?
01:32 imirkin: coz if you are, i'm going to blame this on DRI3
01:32 gcr2: imirkin: i didn't understood you full.. nouveau is from arch repo, not from aur/git
01:32 imirkin: ok
01:32 imirkin: [ 1749.371009] nouveau E[ PFIFO][0000:01:00.0] PBDMA0: (unknown bits 0x00008000)
01:32 imirkin: [ 1749.371023] nouveau E[ PFIFO][0000:01:00.0] PBDMA0: ch 5 [firefox[9962]] subc 0 mthd 0x0000 data 0x00000000
01:32 mupuf: imirkin: so, next release is going to be mesa 12, fun :)
01:32 imirkin: you're not the first person to be getting these, but i haven't the faintest clue what it means :(
01:32 imirkin: mupuf: well, 9.2 -> 10.0 was GL 3.1 -> 3.3, but only a single version bump :p
01:33 mupuf: imirkin: hehe, it is actually good, because we will jump from 3.3 to 4.2
01:33 karolherbst: :D
01:33 karolherbst: not again
01:33 imirkin: mupuf: unlikely
01:33 mupuf: the image load store will likely land very soon for intel
01:33 imirkin: yeah, but what about tess and fp64?
01:33 gcr2: imirkin: exist some solution?
01:34 mupuf: that's not how it works. The version increase is when mesa core supports it
01:34 imirkin: gcr2: i don't even know what the problem is, so unfortunately i can't suggest a solution
01:34 mupuf: no need for actually having a driver supporting the highest version
01:34 imirkin: mupuf: core mesa support has gone hand-in-hand with driver support
01:34 karolherbst: imirkin: could it be that tes-both-input-array-float-index-rd.shader_test needs some time?
01:34 imirkin: i don't think there's precedent for this situation
01:34 gcr2: imirkin: ok, thanks
01:34 mupuf: probably not
01:34 imirkin: karolherbst: you need to run it with -fbo -auto
01:34 mupuf: it does not matter anyway
01:35 mupuf: and it will be up to xexaxo to call it however he wants
01:35 karolherbst: okay, thanks
01:35 imirkin: karolherbst: otherwise it puts up a window and waits for you to either hit esc or otherwise kill it
01:36 karolherbst: k, will never happen here
01:36 imirkin: karolherbst: oh, and can you also do tests/spec/arb_tessellation_shader/execution/barrier-patch.shader_test ?
01:36 karolherbst: okay fine
01:37 karolherbst: imirkin: anything else?
01:37 imirkin: karolherbst: i think that's good for now
01:37 karolherbst: how was the command to check the mmts?
01:37 imirkin: demmt -l foo-file
01:38 karolherbst: okay, last one seems fine
01:39 karolherbst: imirkin: http://www.filebin.ca/29bQX2NvjMBm/mmts.tar.xz
01:39 imirkin: karolherbst: awesome thanks
01:40 karolherbst: any idea when skeggsb cleanup stuff will land?
01:40 karolherbst: or at least, when there will be a public brach
01:41 karolherbst: imirkin: interessting enough: nv86 has only the width set in the LINK_WIDTH reg
01:41 karolherbst: everything else is 0
01:42 imirkin: ya
01:42 karolherbst: everything else has UNK27 always set :/
01:42 karolherbst: that helps a lot
01:43 imirkin: don't worry about those bits
01:46 karolherbst: yeah, I just wanted to take a quick look, but I get nothing out of these
01:56 RSpliet: imirkin: did you just finish GL4.0 support for NVC0+. Nice one!
01:57 imirkin: yeah, looks like the kepler vfetch stuff need a bit more work =/
01:58 imirkin: instead of being able to do things like
01:58 imirkin: ALD R10, a[R9+0x120];
01:59 imirkin: you have to, instead, do
01:59 imirkin: AL2P R0, R3, 0x80;
01:59 imirkin: ALD R10, a[R0]
01:59 imirkin: which is also an issue for geometry shaders, in theory, but in practice, the state tracker always did horrible things. but no more.
02:03 RSpliet: ALD != ARL?
02:04 RSpliet: sorry, I can't find those insn on the readthedocs page for TGSI, I should probably go through the envytools ISA docs first
02:04 imirkin: these are nvidia opcodes
02:05 imirkin: which are undocumented
02:05 imirkin: it's what nvdisasm produces
02:05 imirkin: which is a tad more readable than '??? all dfp #:#:#:# $t128 $s0 $r3 $r0 [unknown: 00000000 0c000000] [unknown instruction]' which is what envydis produces
02:05 RSpliet: it.... yes
02:05 imirkin: ALD = load shader input (load from "a" space)
02:06 imirkin: there's also LDL, LDS, LDC, VILD, PIXLD, and probably a few others i'm neglecting
02:07 imirkin: so now i have to figure out how to fit AL2P into nv50 ir... ugh.
02:12 RSpliet: AL2P is just a regular addition?
02:12 RSpliet: as in
02:12 RSpliet: "calculate the offset within a[] for given const and address"
02:13 RSpliet: sorry
02:13 RSpliet: "given immediate and address"
02:14 RSpliet: (have to be on my toes with GLSL terminology)
02:20 karolherbst: imirkin: are these mmts usefull?
02:20 karolherbst: mupuf: but I still think it will me mesa 11 ;)
02:21 karolherbst: versions won't be skipped
02:21 karolherbst: there were the same discussion on the GL3.1 => GL3.3 bump
02:21 karolherbst: *was
02:22 RSpliet: I opt to finish off GL_ARB_shader_precision and GL_ARB_shader_image_load_store very quickly, and then release Mesa 42
03:18 mupuf: RSpliet: GL_ARB_shader_precision is done
03:20 mupuf: RSpliet: so we do have Ogl 4.1 on fermi working nicely (aside from subroutines being slow)
03:20 RSpliet: amazing! :-D
03:23 karolherbst: mupuf: mhhh do you about my memory issue with subroutine?
03:23 mupuf: Intel would be close to 4.3 if only tesselation shaders were supported. It is not a priority though
03:23 mupuf: karolherbst: can't parse the sentence
03:26 xexaxo: mupuf, imirkin: all the way to 11 :P
03:26 mupuf: xexaxo: nice one :D
03:27 mupuf:is looking forward to reading the announcement for all the spinal tap references :p
03:27 xexaxo: iirc Ben tried that one with 10.0 due to the huge leap.
03:29 karolherbst: mupuf: I get kernel ooms whly running metro redux on nouveau
03:29 karolherbst: *while
03:30 karolherbst: mupuf: memory usage goes up to 32GB and then the kernel ooms stuff
03:30 karolherbst: worked with intel though
03:34 karolherbst: will test with current mesa master again though
03:41 karolherbst: yeah, memory problems also on mesa mster
04:16 pmoreau: karolherbst: Do I need to check some regs on my laptop (MCP79+G96) regarding PCI bus width?
04:23 karolherbst: pmoreau: depends
04:24 karolherbst: imirkin: changing width works on tesla?
04:25 pmoreau: karolherbst: What is it depending on? :-)
04:25 karolherbst: I am pretty sure we now pretty much already for tesla regarding width changes
04:26 pmoreau: Ok. Is there a branch I could try (when I get home, next week)?
04:37 karolherbst: pmoreau: not yet
04:38 karolherbst: I will propably also work on that, but there is a lot to do before
04:38 karolherbst: width change doesn't increase performance, because the cards are usually on the highest amount of lanes already
04:38 karolherbst: so its more likely to save power if we reduce the amount of lanes used
04:41 karolherbst: currently the only way to change it is to write directly into the registers of the gpu
05:22 karolherbst: mupuf, imirkin: I think we should really resolve this memory issue before pushing a new mesa release, not that other applications are effected as well and user complain about oom situations/hangs/freezes while trying out some games. Allthough I really don
05:22 karolherbst: 't know if there are other games which needs it
05:23 mupuf: karolherbst: which memory issue?
05:24 karolherbst: metro redux pushing used memory to 32GB and above
05:24 karolherbst: => kernel ooms several processed and kernel threads
05:24 karolherbst: *processes
05:25 karolherbst: could be a kepler issue or result of the hack I am using
05:25 karolherbst: worse is, that the nouveau kernel modules gets SCHED_ERROR
05:25 karolherbst: and the kernel can't oom metro that fast
05:25 karolherbst: so for some minutes everything is really at the limit
05:26 mupuf: eww
05:26 karolherbst: I already tried with zram increasing my swap
05:26 karolherbst: but with 16GB physical memory there isn't much to do
05:26 karolherbst: its like 3GB used before starting metro
05:27 karolherbst: and after trying to load a save, mem usage goes up to above 12GB really fast, then it swaps
05:27 karolherbst: depending on your swap, this could get messy
05:28 RSpliet: karolherbst: I understand this is a pressing issue, but has it been there for a short time, a long time or forever?
05:28 RSpliet: did you try bisecting?
05:28 RSpliet: if it's a long standing issue, it shouldn't block release (as nasty as it seems); if it's new, bisect should give away what introduced it
05:28 karolherbst: RSpliet: metro redux needs subroutines
05:29 RSpliet: ah ok
05:29 RSpliet: is it nouveau specific?
05:29 karolherbst: yes
05:29 karolherbst: intel worked fine
05:29 karolherbst: so does blob
05:29 RSpliet: that lowers severity further ;-)
05:30 karolherbst: I can actually play the game with intel
05:31 RSpliet: so do you think this leak is in the subroutine code, or could it be anywhere
05:31 karolherbst: yeah, but if its really nouveau related and if it occurs on all "real" applications using subroutines, wouldn't it be better to disable it for now for nouveau?
05:31 karolherbst: mhhh
05:31 karolherbst: its in kernel space most likely
05:31 karolherbst: the metro process itself reports more or less 11% memory usage
05:31 karolherbst: but I don*t know who triggers it
05:31 RSpliet: what about Xorg?
05:31 RSpliet: (just covering all bases)
05:32 karolherbst: nouveau runs with DRI3 prime
05:32 karolherbst: so there is no nouveau ddx
05:32 RSpliet: did anyone confirm this bug on a nouveau-only set-up?
05:32 RSpliet: (eg: no prime)
05:32 karolherbst: we would need somebody with the game who can test it
05:33 karolherbst: or maybe has another game who needs it
05:33 karolherbst: but I don't know any yet
05:33 karolherbst: or other applications
05:33 RSpliet: does an apitrace trigger the same issues?
05:33 karolherbst: yes
05:34 RSpliet: then you don't need someone else with the game, just someone who can replay the trace :-P
05:34 karolherbst: right
05:37 karolherbst: I think I have one
05:39 karolherbst: but its like 2GB big :/
05:39 karolherbst: its already trimmed
05:39 karolherbst: will compress it though
05:42 karolherbst: RSpliet: would you like to try it out? while tracing it I stopped earlier, so it hardly needs more then 4GB
05:42 karolherbst: its 200MB big compressed
05:43 mupuf: karolherbst: do we need another repo for apitraces?
05:43 RSpliet: karolherbst: I can take a look over the weekend
05:43 RSpliet: well, perhaps
05:43 mupuf: I can do that on my server
05:44 mupuf: I have tons of space I do not use
05:44 karolherbst: mupuf: mhh if you have 1 TB spare space, sure :D
05:44 mupuf: yep, I do
05:45 karolherbst: then okay
05:45 mupuf: let's avoid reaching more than 100GB of data though, so we need to keep the traces in xz -9 and as short as possible
05:46 karolherbst: well my trace is 200MB already, but this is rather big
05:46 mupuf: I may need to create a unix acount for this though, as git would not be very usable for this
05:46 karolherbst: ftp?
05:46 mupuf: well, that would indeed be ok
05:47 mupuf: and I can limit the maximum size to 100 GB
05:48 karolherbst: I think 1GB would be enough
05:48 karolherbst: mhh
05:48 karolherbst: maybe 10
05:48 karolherbst: or you mean in total?
05:49 mupuf: in total
05:49 mupuf: I trust people not to be stupid and upload a giant trace unless absolutely necessary
05:49 karolherbst: :D
05:49 karolherbst: okay
05:50 karolherbst: do we want to keep traces ordered by issue or application? I was thinking about $game/$user/ and then traces + descriptions what the traces are about
05:53 mupuf:does not care too much about this
05:53 mupuf: but having a contact name would be good
05:53 mupuf: and the ftp should not be public
07:07 mmarker: Ok, I'm trying to wrap my head around the horribly experimental reclocking code, and getting lost in a passage of twisty oclasses, which all don't quite look alike. Trying to understand the gf100 code, and I can see that the pstate file in sysfs is populated, but don't understand how a write in the sysfs file propagates downwards.
07:09 karolherbst: mmarker: look into the clk subdev
07:10 karolherbst: but on fermi recocking doesnÂt work currentlz
07:10 karolherbst: *z
07:10 karolherbst: ...
07:11 karolherbst: mmarker: a pstate changes is triggered by calling the nvkm_pstate_prog function
07:12 mmarker: Ahh, I see
07:12 mmarker: so, how would one collect the info needed to record how to do a reclock? More than happy to break things *cough*
07:14 karolherbst: mmiotrace the blob
07:14 RSpliet: mmarker: for a high level overview, you might want to look at my presentation last year @ XDC
07:14 mmarker: freedesktop?
07:15 RSpliet: but the process is a painful reiteration of tracing what the official driver does, fiddle with the VBIOS a tiny bit, re-trace, rinse, wash, repeat
07:16 RSpliet: http://www.x.org/wiki/Events/XDC2014/XDC2014SplietREclock/
07:17 mmarker: Ok, thanks.
07:18 RSpliet: hmm, the slides might not be a self-contained thing on second thought, probably the talk clarifies them a bit (video?), but feel free to ask questions
07:19 RSpliet: I... might not be around too much for answering them though :-$
07:19 mmarker: No worries.
07:24 karolherbst: maybe it would be better to start with "simplier" things?
07:24 karolherbst: just to get used to the process, but I don't know what you have worked on for nouveau already mmarker
07:24 RSpliet: and/or what your background is in general ;-)
07:25 karolherbst: sadly the pcie stuff is almost gone, it was a nice task to begin with the work :D
07:25 karolherbst: maybe there is still something left
07:25 RSpliet: karolherbst: it's not over 'till the fat lady sings
07:25 karolherbst: right
07:25 karolherbst: but mostly the trivial things
07:25 RSpliet: the clock gating regs should be even simpler :-P
07:25 karolherbst: mhh don't know
07:26 RSpliet: sure they are, they're well understood and come down to a collection of (per-engine) data gathering and static writes during boot and perhaps resume
07:27 RSpliet: basically you do a ton of writes, and you get free power efficiency
07:27 RSpliet: you don't have to calculate what to write, just... build a table with the values :-P
07:27 karolherbst: mhh
07:27 karolherbst: yeah okay
07:28 karolherbst: that sounds easy eough
07:28 karolherbst: are the regs known already?
07:28 karolherbst: at least on fermi?
07:28 RSpliet: (until gnurou steps in with remarks about how it was broken for engine X on NVA3 and you need to disable it before reclocking... but that's for later worries)
07:28 RSpliet: for some engines they are, and they are really easy to spot from trace
07:29 karolherbst: ohh then
07:29 karolherbst: mmarker: might be a good think to do
07:29 karolherbst: demmio is a nice tool to spot stuff like that
07:29 karolherbst: you just have to know what you search for
07:29 RSpliet: there's even some code in Tegra kernel trees for it :-P
07:29 karolherbst: mhh
07:29 karolherbst: wouldn't it be required to messure power consumption of the card somehow?
07:29 karolherbst: so that somebody really knows that it works
07:30 RSpliet: I think mupuf did that in the past and measured a modest improvement
07:37 karolherbst: RSpliet: I meant like it would be helpful to be messure it while changing the reg values
07:38 RSpliet: karolherbst: he did
07:38 RSpliet: ask him for the details
07:38 karolherbst: the question is if mmarker can do it
07:38 RSpliet: oh right
07:38 RSpliet: well... maybe? :-P
07:38 karolherbst: if mmarker wants to do that
07:38 mmarker: Power draw? I'd have to make sure my equipment can hack it
07:39 mmarker: Granted, it's going to be voltmeter and duct tape
07:39 karolherbst: allthough fermi pstate change would be really awesome to implement
07:39 karolherbst: mmarker: ask mupuf, he can really help you with almost everything RE related ;)
07:39 RSpliet: mmarker: hah, interesting how 20 lines of chat puts you in a position of doing X before even asking about your background or interests :-P
07:40 karolherbst: :D
07:40 mmarker: RSpliet: Well, as for background, does screaming at working on ARM devices to yield their tasty secrets count?
07:40 karolherbst: mmarker: are you on a laptop or desktop system?
07:40 RSpliet: mmarker: from what position?
07:41 mupuf: only 100e+ GPUs get the power monitor
07:41 mupuf: on kepler+
07:41 mupuf: although some late fermi also have it
07:41 RSpliet: corporate, hobby? RPI, Sunxi? actual coding, reverse engineering? :-)
07:41 mmarker: karolherbst: Desktop.
07:41 karolherbst: he mentioned he would yous ductape and voltmeter if there is no other way ;)
07:41 karolherbst: *use
07:42 mmarker: RSpliet: Hobby. Started with the ipaq waaaay back - and then was one of the crack monkies who helped port mozilla to ARM. So some kernel space, some userspace
07:43 RSpliet: okay, that's good. any assembly stuff? played with coresight before? :-P
07:43 RSpliet: (not that you need it here, just interested)
07:43 imirkin: karolherbst: yes, your traces were helpful, they revealed the AL2P thing. however what they *didn't* have was a barrier use, which is very surprising.
07:43 imirkin: perhaps the blob knows something we don't
07:43 mmarker: Hah. With that pile of cash - wait, no, I'm in engineering. What pile of cash. :D
07:44 karolherbst1: this wifi router here :/
07:44 mmarker: RSpliet: x86 assembly is still a weakness, sadly. ARM and SPARC babied me too much.
07:44 RSpliet: mmarker: x86 assembly is a rotten nightmare and merely good for bragging rights
07:45 mmarker: You don't have to tell me that.
07:45 RSpliet: Worse than Thumb (TM)
07:46 RSpliet: but that saves me trying to explain the basics of the kernel and/or MMIO... have you played with MMIOTrace before? :-D
07:47 mmarker: That I have not.
07:47 imirkin: do you know what MMIO is?
07:47 mmarker: Memory-mapped IO
07:47 RSpliet: it's probably a good first fun step into the world of reverse engineering
07:47 mmarker: and no, I didn't Google that
07:48 RSpliet: what I do is have a separate Linux installation featuring the official NVIDIA driver and a kernel that can do MMIOTrace. There's some guides on how to do mmiotracing on the nouveau wiki.
07:48 imirkin: well, mmiotrace basically does clever things with PTE's to trace all reads and writes
07:51 RSpliet: you can try and collect some trace from the official driver, run it through demmio (one of the tools we have in the envytools repository), and see if you can recognise the write that sets the RAM "MR" parameter (whose format is documented in public DDR3 and GDDR5 specs. The exact register address is documented somewhere in envytools too)
07:52 RSpliet: there's quite a lot of challenge there, but see if you can tell what CAS latency the driver sets for your RAM :-P
07:52 mmarker: Ok, I'll give it a shot and see what I can figure out.
07:53 RSpliet: that should keep you entertained for a few hours or even days :-P
07:56 mmarker: Yup. Well, off to get back to work. Thanks for the guidance.
08:01 RSpliet: imirkin: I'm not sure if I'd consider "marking a whole MMIO region as invalid, permanently" is clever or just YOLO
08:01 RSpliet: it's an interesting technique nonetheless :-)
08:01 imirkin: any tricks one plays with PTE's are almost by definition clever
08:02 imirkin: esp if they don't lead to a crashed system
08:07 karolherbst: mhh slowly I get the feeling, that GL 4.5 isn't that far away anymore
08:07 imirkin: sounds like we have a volunteer for images!
08:07 karolherbst: :D
08:07 karolherbst: which one?
08:07 karolherbst: GL_ARB_shader_texture_image_samples ?
08:08 imirkin: haha no
08:08 imirkin: shader_image_load_store
08:08 karolherbst: "in progress (curro)"
08:08 imirkin: yeah, but for i965
08:08 karolherbst: I see
08:08 imirkin: core support landed a long time ago
08:08 RSpliet: I thought curro landed a few patches recently
08:08 karolherbst: but I was stalking about GL4.5 in general ;)
08:08 imirkin: but now you get to (a) pipe it through gallium and (b) figure out how to implement it on kepler+
08:09 RSpliet: imirkin: I loved Michaels remark there
08:09 karolherbst: mmt is the way to go I guess until we find stuff the driver can't do
08:09 imirkin: RSpliet: which one?
08:09 RSpliet: "For Nouveau NV50, LLVMpipe, Softpipe, and the other niche drivers there is still much more work left. "
08:09 imirkin: hehehe
08:09 karolherbst: :D
08:09 karolherbst: yeah well
08:09 RSpliet: like, design some silicon :-P
08:09 karolherbst: nouveau at 4.1 and intel not?
08:09 karolherbst: sounds like he is right
08:09 imirkin: clearly nouveau has a bigger team :)
08:10 karolherbst: yeah obviously
08:10 imirkin: or more documentation
08:10 RSpliet: imirkin: you're not *that* big right?
08:10 karolherbst: or no documentation
08:10 karolherbst: could be an advantage
08:10 imirkin: or less retarded hardware
08:10 karolherbst: :D
08:10 huehner: signing key for maxwell firmware maybe ?
08:11 karolherbst: I always though an application requiering documentation to be understood isn't worth the time working with it
08:11 huehner: but that would kind of defeat their purpose
08:11 karolherbst: which purpose?
08:11 imirkin: huehner: i'd be just as happy with them signing our firmware
08:11 huehner: not allowing non nvidia built firmware?
08:12 huehner: imirkin: sure, but i think that way be more difficult to get organized for them, but just a guess
08:12 imirkin: gnurou: is there any chance that could happen? [nvidia signing nouveau fw for maxwell+]
08:12 huehner: imirkin: was just about to ask the same
08:13 imirkin: gnurou: it would allow nouveau (and thus nvidia hw) to continue to be used in the "libre" distros
08:13 huehner: imirkin: i.e. for tegra i think he is actively trying to push the fw files already into linux-firmware repo
08:14 imirkin: yeah i know
08:14 imirkin: but no one's even tried using the nouveau ctxsw fw on gk20a
08:14 imirkin: i feel a little bad about that since i have a tk1
08:15 imirkin: but i was hoping a more competent person (and thus more able to deal with any problems that come up) might take a look
08:15 huehner: other topic i tried to map gm206 trace from blog to the fw-loading code in nouveau and couldn't match the 2 together even
08:15 huehner: i'm no expert at all there but looked like uploading fw may be different even (for the code part, not data)?
08:18 RSpliet: oh, I don't think I have a TK1 unfortunately
08:24 imirkin: huehner: i think blob uploads it as one linked thing
08:24 imirkin: while nouveau does them separately
08:25 imirkin: huehner: you should beg skeggsb for his branch where he implemented ctxsw "by hand" for gm20x
08:25 huehner: imirkin: hmm maybe i did match the 'data' part of the neouvau upload code, essentially very small write but looked like base-offset+length to big blog of data i see before via ramin commands in the trace
08:26 imirkin: yeah, ben ran into the same problem
08:26 imirkin: er hm, maybe not the SAME problem
08:26 imirkin: he said it would load things out of sysram
08:26 imirkin: and we don't have a reverse-mmiotrace ;)
08:34 imirkin: i wonder if the iommu could be used for that... heh.
08:34 imirkin: oh well, bbl
08:44 karolherbst: if somebody seens skeggsb: I would like to work on his cleanup branch for the PCIe stuff :D
08:48 mupuf: karolherbst: he said he was trying to push it on friday
08:48 mupuf: trust him, he is working full time on it
08:48 mupuf: and he is not often visible here because he lives on the east side of australia
08:49 hakzsam_: this is going to be a very big merge :)
08:50 mupuf: probably!
08:51 RSpliet: scarier than a crocodile O:-)
09:02 mupuf: RSpliet: is that an autralian stereotype joke?
09:12 karolherbst: I was working with australians before
09:12 karolherbst: so I kind of new how their schedule is usually
09:13 karolherbst: but friday sounds good
09:15 RSpliet: RSpliet: yep
09:15 RSpliet: and a terrible one
09:15 RSpliet: but you have to admit, crocs *are* pretty scary when they're less than a foot away
09:16 RSpliet: I'm glad we have metrics...
09:40 Tom^: Manoa: did you test things yet?
11:51 imirkin_: oh hey, anyone with a maxwell, if you could try to see if unigine heaven works, that'd be interesting. you'll have to use xf86-video-modesetting though, since the nouveau ddx is all broken and doesn't allow core profiles.
11:57 buhman: fixit
12:06 nanga: Hey guys! I have an old GeForce GT220 on a computer. When I use nouveau 2D is pretty slow on Gnome3. If I use the Intel HD Graphics 4000, 2D animations are much more smooth. Is there any driver option in xorg.conf to solve this problem?
12:07 imirkin_: nanga: it should all be pretty snappy. perhaps something is misconfigured... pastebin dmesg + xorg log + glxinfo output
12:08 imirkin_: ftr, there's no 2d when you use gnome3 -- it's all "3d".
12:08 imirkin_: [er, i guess that's not strictly true...]
12:08 nanga: imirkin_, Oh! I didn't know that, I thought that it was 2D. Sorry about that.
12:09 nanga: imirkin_, The machine is at home. Can I bug you later? ;)
12:09 imirkin_: sure
12:09 nanga: imirkin_, Thanks!
12:34 tobijk: oh we bumped up to gl lvl 400? :> yay
12:34 imirkin_: 4.1
12:34 tobijk: :)
12:35 imirkin_: but who's counting
12:35 imirkin_: tobijk: how's cull distance going?
12:35 tobijk: it already got you an article on heise.de :P
12:35 tobijk: imirkin_: had a test today, havent done something for cull
12:36 imirkin_: isn't it summer?
12:36 tobijk: yeah its test time (2 weeks)
12:38 imirkin_: heh. google translate is funny.
12:38 imirkin_: The driver speaks to the majority of the graphics processors from Nvidia, but coaxed just modern high-end GPUs only a fraction of the power that delivers Nvidia's proprietary Linux drivers.
12:39 tobijk: which part is that? :O
12:39 imirkin_: Der Treiber spricht das Gros der Grafikprozessoren von Nvidia an, entlockt aber gerade modernen High-End-GPUs nur einen Bruchteil der Leistung, die Nvidias proprietärer Linux-Treiber liefert.
12:40 Weaselweb: I'm trying to get used to piglit. I've run my sanity check and now "./piglit summary html summary/sanity results/sanity.results" gives me this error: 'Warning: A python exception that should have been handled was not. This is bug and should be reported. BUG: No module supports file extensions ".results"'
12:40 tobijk: heh not _that bad_
12:40 buhman: wait what?
12:40 Weaselweb: which python module I might be missing?
12:40 imirkin_: Weaselweb: you're just using it funny
12:40 buhman: imirkin_: you did it!
12:41 imirkin_: Weaselweb: just use piglit-summary-html.py directly
12:41 Weaselweb: imirkin_: huh? I'm using it as written in the README ;-) (http://cgit.freedesktop.org/piglit/tree/README#n244)
12:45 Weaselweb: well, also using "./piglit-summary-html.py -o summary/sanity results/sanity.results" results in the same error message
12:48 imirkin_: erm
12:48 imirkin_: yeah, that won't work
12:48 Weaselweb: ah, ./piglit -o summary html summary/sanity results/sanity/results.json.bz2
12:49 imirkin_: that's a lot more likely to work
12:49 imirkin_: basically you need to feed it an output directory where to stick the html, and the sources to display
12:49 imirkin_: the soruces come in the form of a file or a directory that contains said file
12:50 Weaselweb: ic. the docs need some polish
12:51 Weaselweb: ./piglit run quick_cl gpu deqp_gles3 results/gl-cl-combined -> "Fatal Error: There is not profile attribute in module deqp_gles3."
12:51 imirkin_: if you say so... the whole top-level "piglit" command is pretty new in the first place
12:51 imirkin_: yeah, you need the deqp tests
12:51 imirkin_: and point piglit at them
12:51 tobijk: i do something like ./piglit-summary-html.py (summary) result1 result2 result3
12:51 imirkin_: they're not included as part of piglit, it's some giant mega-repo somewhere
12:51 tobijk: after testing :D
12:52 imirkin_: buhman: what did i do?
12:53 tobijk: gl 4.1 :)
12:53 buhman: imirkin_: tessellation and gl 4.0
12:53 imirkin_: oh
12:53 imirkin_: well, it was a team effort
12:53 buhman: "oh, was accident"
12:53 buhman: "old news, I forgot"
12:53 imirkin_: and there are some remaining annoyances
12:54 Weaselweb: does piglit actually show something on screen? I'm running currently on my NVAA with the TV turned off
12:54 imirkin_: Weaselweb: a few tests render to the screen for a split second, but basically not
12:55 imirkin_: Weaselweb: your results should be largely like the nva8 results that you see on my page
12:55 imirkin_: Weaselweb: http://people.freedesktop.org/~imirkin/nv50-comparison/problems.html
12:55 Weaselweb: sounds like nothing to watch. that's great
12:55 imirkin_: or actually more like nva0 than nva8
12:56 tobijk: oh clear_buffer
12:56 tobijk: that would be doable i guess
12:56 imirkin_: tobijk: hm?
12:56 imirkin_: didn't you already do it?
12:56 tobijk: oh it is done :D
12:56 tobijk: for nv50
12:56 imirkin_: yeah
12:56 Weaselweb: imirkin_: the links to "all" and "skipped" don't work (404)
12:57 imirkin_: Weaselweb: yeah. pretty pointless pages that take up lots of space
12:57 Weaselweb: ok
12:57 imirkin_: i just remove them :)
12:57 imirkin_: also takes forever to load a table with 20k rows
12:58 tobijk: who uses those tests? :>
12:58 tobijk: *tabs
17:10 imirkin: can someone give me some pointers of what to search for wrt running intel + nvidia s.t. the nvidia output displays directly on the intel screen? [with the blob] ideally this would be in such a way that i can unload the nvidia module at will without restarting X.
17:13 imirkin: huh. intel dri3 + nouveau works without a compositor? surprising.
17:24 imirkin: oh i bet it's coz i have TearFree enabled
17:49 imirkin: skeggsb: what does nouveau_pushbuf_validate do? i got an assertion about kref being null in nouveau_pushbuf_data (yay for throwing those asserts in)
17:55 skeggsb: imirkin: makes sure there's enough pushbuf space for relocs (<nv50, due to no fixed virtual addresses there), does the accounting for any new additions to the bufctx, adding them to the list we send to the kernel etc, and flushing the pushbuf if the new additions can't fit in memory at the same time as the older ones
17:56 imirkin: skeggsb: so my solution to the whole issue of "there is no kref" thing was to add PUSH_REFN's (which just do pushbuf_refn)
17:57 imirkin: should i also have thrown a pushbuf_validate?
17:57 skeggsb: the validate just gathers up all the new "REFN"s, but yes, you should do that before submitting a draw or the kernel won't get the new info
17:57 imirkin: well... this isn't for the kernel
17:57 imirkin: this is for libdrm
17:58 imirkin: basically there's code like
17:58 imirkin: nouveau_pushbuf_data(push, q->bo, more args go here)
17:58 skeggsb: yes, but all that machinery is how libdrm builds the kernel's "these are the buffers that this draw will touch" list
17:58 imirkin: ok, so i need to validate before calling the pushbuf
17:58 imirkin: er
17:58 imirkin: before doing pushbuf_data
18:06 imirkin: interesting.
18:07 imirkin: skeggsb: http://paste.debian.net/285429/
18:07 imirkin: nouveau_pushbuf_data: Assertion `kref' failed.
18:07 imirkin: i thought it was one of the push data's from the mesa code...
18:15 imirkin: so basically what that's saying is that there's no kref associated with a nvpb->bo
18:15 imirkin: which ought to be impossible :(
18:24 imirkin: skeggsb: anyways, i'm hitting this when trying to run heaven with dri3 prime
20:48 imirkin: ok... that should fix many of the variable-indexing piglit tests
20:49 imirkin: still a bunch of fails, no idea why
20:49 imirkin: but at least a lot fewer MEM_OUT_OF_BOUNDS messages
21:18 imirkin: ugh. memory-combining patch and non-patch stores seems like a *really* bad idea
21:27 imirkin: mmkay. tess is in a much better state now. almost everything passes on my GK208.
21:52 imirkin: if anyone's up for it, could use a blob trace of tests/spec/arb_tessellation_shader/execution/vs-tes-tessinner-tessouter-inputs.shader_test
22:17 imirkin: hopefully the answer is something more subtle than piping those values through by hand to tes when tcs isn't there...