03:05 RSpliet: baegle: which component of nouveau?
03:36 kb9vqf: So, how close is noveau to having real OpenCL support at this point?
03:37 kb9vqf: ended up going with a Radeon card for now but would prefer the nVidia cards due to lack of AtomBIOS
03:40 RSpliet: kb9vqf: it's a WIP, I wouldn't expect something stellar for *at least* another few months
03:40 RSpliet: (they're making good progress, but it's been stalled for a long long time)
03:40 kb9vqf: RSpliet: That's pretty much what I wanted to hear; progress is being made. :-)
03:41 kb9vqf: In the meantime we can see how much OpenCL would speed up the application in question on the Radeon
03:41 RSpliet: how is not having an atombios an advantage btw?
03:41 kb9vqf: it's a non-free software issue mostly
03:41 kb9vqf: anytime you have non-free software running in ring 0 it's a danger flag (difficult to audit, etc.)
03:42 kb9vqf: yes, I know AtomBIOS is interpreted, but I wonder how good the Linux sandbox is (or if there even is one)
03:42 RSpliet: mmm, but keep in mind nouveau has other performance bottlenecks (esp for modern cards you hardly ever reach the advertised clock speed... because we don't have an atombios)
03:42 kb9vqf: NVE0 cards work quite well
03:43 kb9vqf: anyway right now it's a toss up; I'd like to do an apples to apples comparison radeon to nouveau comparison for OpenCL
03:44 kb9vqf: if nVidia locks the platform down entirely then ATI's better even with AtomBIOS since that at least can be sandboxed
03:44 kb9vqf: (in theory, haven't checked kernel sources yet)
03:45 kb9vqf: primary reasons for looking at nouveau first were 1.) hardware on hand / supported by our preferred manufacturer and 2.) relatively good luck with the NVE0 cards and reclocking, etc.
03:45 RSpliet: which is exactly what NVIDIA has done with the second generation maxwell cards (GM20x)
03:45 kb9vqf: and we won't be using those :D
03:45 RSpliet: okay
03:45 kb9vqf: ATI is the long range plan right now unless nVidia can get its head on straight
03:46 kb9vqf: ....but, since nVidia hardware is on hand right now, was wondering about the OpenCL
03:46 RSpliet: if you have plans to audit our "fuc" firmware imlementation, let us know
03:47 kb9vqf: will do. would probably only happen once OpenCL support is available though, and if the NVE0 cards are still a good value proposition at that point
03:47 kb9vqf: ....or if nVidia decides to release an open-source friendly variant ;-)
03:47 kb9vqf: (and pigs fly)
03:53 RSpliet: perf/watt will most likely be better with Maxwell or what may be released afterwards
03:53 RSpliet: so depends on what you value ;-)
03:53 RSpliet: kb9vqf: NVIDIA has reasons for demanding signed firmwares to be uploaded to their card
03:53 RSpliet: we can argue about the validity of these reasons, but... it doesn't appear to be a random move
03:54 kb9vqf: RSpliet: Yeah, all they're really doing though is making GPU computing even less attractive, and it wasn't really a surefire thing in the first place
03:54 kb9vqf: lots of benchmarks are showing that the GPU is just as bad as the CPU when all the overhead is factored in
03:55 RSpliet: 10x speed-ups for massive parallel workloads, 2x perf/watt is the rule of thumb I keep reading
03:55 kb9vqf: *if* you can get the data into the GPU
03:55 kb9vqf: most workloads aren't as massively parallel as people think
03:56 kb9vqf: anyway thankfully there's ATI
03:56 RSpliet: that includes the upload/download overheads, but yes, does not factor in the "we use more memory than available"
03:56 kb9vqf: AtomBIOS as I said can at least theoretically be sandboxed, which helps. Binary blobs running on the host CPU though (the nVidia driver) are an instant no-go
03:57 kb9vqf: so basically your 2x perf/watt shrinks somewhat when you have to firewall the compute nodes ;-)
03:58 kb9vqf: (I don't mean a standard firewall either, I'm talking firewalling individual machines from one another or racks from one another depending on partitioning)
03:58 kb9vqf: anyway I'm way off topic
03:59 kb9vqf: it's a shame nVidia went down this path, they seem to be becoming the Intel of the GPU world
04:39 pmoreau: kb9vqf: I agree with RSpliet for the OpenCL status. We should have a better idea, at where we are, at FOSDEM.
06:04 imirkin: anyone on a G8x/G9x? i need glxinfo -l -s output against mesa 11.1.0 for it
07:00 pmoreau: imirkin: Does MCP79 work as well? (I don't want to restart X to enable the G96. ;-))
07:01 imirkin: pmoreau: mmmmmmmmmm
07:01 imirkin: pmoreau: it has a couple of things the G9x's don't...
07:01 imirkin: pmoreau: no rush though, whenever you do so at a natural point works for me
07:01 imirkin: and perhaps someone else will have supplied it by then
07:01 imirkin: i gtg though, bbl
07:01 pmoreau: Hum… ok
07:01 pmoreau: :-D
07:02 pmoreau: see you later
07:22 pmoreau: imirkin: Here you are: https://phabricator.pmoreau.org/P70
07:29 imirkin_: pmoreau: thanks :)
07:29 pmoreau: If you need me to run piglit tests or whatever else, I'm still on the G96. :-)
07:32 imirkin_: alrighty. this is getting respectable. just need to fill intel in.
08:21 karolherbst: imirkin_: mhh I am on current nouveau master and still nouveau doesn't get load :/
08:21 imirkin_: PEBKAC :p
08:22 karolherbst: well then git bisect
08:22 karolherbst: ...
08:37 karolherbst: imirkin_: also 11.1.0 is broken
08:37 karolherbst: maybe it is libdrm fault
08:38 imirkin_: it's something purely local to your machine.
08:38 karolherbst: yeah, maybe that
08:38 karolherbst: but I just upgraded libdrm and mesa
08:38 karolherbst: and then it broke
08:41 Tom^: OSI layer 8 problem.
08:46 Tom^: imirkin_: im building mesa now, and since you gave me my hopes up now i will hold you responsible if its not fixed. =D
08:47 imirkin_: Tom^: well it was def an issue... whether it was *the* issue, who knows
08:47 imirkin_: Tom^: i fired up cs:go last night, which demonstrated to me that it's been a LONG time since i've played that sort of game
08:47 imirkin_: i barely made it through training :)
08:47 Tom^: =D
08:48 Tom^: its a bit sad that i cant apitrace it either, its gonna end up in terabytes of logs
08:48 imirkin_: heh
08:48 Tom^: unless i can somehow not trace the first 10 minutes.
08:55 karolherbst: imirkin_: so with libdrm 65 it works with 66 not :/
08:55 Tom^: "../build-aux/test-driver: line 107: 5924 Segmentation fault (core dumped) "$@" > $log_file 2>&1
08:56 Tom^: interesting
08:56 Tom^: https://gist.github.com/anonymous/151a938a2bb6a973a1a6 O_o
08:57 imirkin_: w00t, not my code :)
08:57 imirkin_: (probably)
08:57 Tom^: the even more interesting bit is that it built 64bit , but this lib32 one didnt
08:58 karolherbst: imirkin_: should mesa compiled against libdrm 65 work after upgrading libdrm to 66?
08:58 imirkin_: karolherbst: yes.
08:58 karolherbst: mhh
08:58 karolherbst: okay, for me it does not
08:58 imirkin_: for me it does :)
08:59 karolherbst: well maybe bisecting libdrm helps
09:04 karolherbst: imirkin_: 65 built from git also doesn't work :O
09:04 karolherbst: ohh wait
09:04 karolherbst: wrong ld library path
09:07 imirkin_: like i said, PEBKAC :p
09:08 karolherbst: okay, with system libdrm it works :D
09:08 karolherbst: and mesa built by me
09:09 damex: git commit -m 'bump deadbeef-fb'
09:09 damex: miss
09:10 karolherbst: imirkin_: I have no clue what is causing this, everything looks sane :/
09:15 imirkin_: karolherbst: LIBGL_DEBUG=verbose glxinfo with the failing mesa
09:15 imirkin_: please include the command line that you use.
09:16 karolherbst: imirkin_: https://gist.github.com/karolherbst/9dfd577dec7472fb3ef9
09:17 karolherbst: ohh you wanted LIBGL_DEBUG :D
09:17 imirkin_: can you add in a "strace -f -e open" in front?
09:18 karolherbst: reload
09:18 Tom^: hm thats a first, i had to actually blacklist the nvidia module or it wouldnt load nouveau O_o
09:19 karolherbst: Tom^: the kernel auto loads modules for your hardware
09:19 karolherbst: or udev
09:19 karolherbst: :D
09:19 Tom^: well yea, just that in the past its always chosen nouveau over nvidia.
09:20 Tom^: libGL error: failed to load driver: nouveau
09:20 karolherbst: imirkin_: well it fails with mesa compikled from source (master) and I am sure I got the paths right
09:20 imirkin_: karolherbst: can you load all this up in gdb, and do a "break nvc0_screen_create"
09:21 imirkin_: and see where it's failing?
09:22 Tom^: imirkin_: do i need xf86-video-nouveau from git too?
09:22 karolherbst: Tom^: dri3 :p
09:22 imirkin_: Tom^: for what?
09:22 imirkin_: Tom^: actually the answer is 'no' no matter what... git head == xf86-video-nouveau 1.0.12 :)
09:23 karolherbst: imirkin_: nvc0_screen_create doesn't get hit, but gdb also doesn*t see main :D
09:23 imirkin_: karolherbst: ok, can you add a breakpoint in...
09:23 imirkin_: nouveau_drm_screen_create
09:23 karolherbst: yep
09:23 imirkin_: does it get hit?
09:24 karolherbst: yeah
09:24 imirkin_: cool
09:24 imirkin_: start stepping :)
09:24 karolherbst: okay, an error got hit
09:24 imirkin_: which one
09:24 karolherbst: nouveau_device_new
09:25 imirkin_: gr
09:25 imirkin_: p err
09:25 karolherbst: yeah well
09:25 imirkin_: p *drm
09:25 karolherbst: $1 = {void (int, const char *, ...)} 0x7ffff41e8ec0 <err>
09:25 karolherbst: $2 = {client = {parent = 0x0, handle = 0, oclass = 0, length = 0, data = 0x0}, fd = 6, version = 16777985, nvif = true}
09:26 imirkin_: that's a funny version.
09:26 karolherbst: :D
09:26 karolherbst: I am bisecting mesa, because something in mesa clearly changes behaviour
09:26 imirkin_: 0x1000301
09:28 Tom^: imirkin_: well https://gist.github.com/anonymous/688a065a5aa977e068ff around line 311 "(EE) AIGLX error: Calling driver entry point failed"
09:28 karolherbst: imirkin_: screen is also NULL
09:28 imirkin_: why did all this work so well for me....
09:28 imirkin_: what kernel are you guys on?
09:28 karolherbst: imirkin_: yeah, no idea, let me finish bisecting and we will know why
09:29 imirkin_: something mega-recent i'm guessing? i was on 4.3.0
09:29 Tom^: 4.3.2
09:29 karolherbst: 4.3.2
09:29 karolherbst: ohh no
09:29 karolherbst: 4.3.3
09:29 imirkin_: wtvr
09:29 imirkin_: not 4.4-rc
09:29 imirkin_: or ben's private tree
09:29 karolherbst: well nouveau master though
09:29 imirkin_: ohhhh
09:29 pmoreau: Works fine for me on 4.3.3
09:29 imirkin_: ok
09:29 karolherbst: + my bunch of patches
09:29 Tom^: im on karolherbst repo tho
09:29 imirkin_: that's the difference then.
09:29 imirkin_: i'm on 4.3.0 nouveau
09:29 pmoreau: (But on Tesla)
09:30 karolherbst: ohhh
09:30 imirkin_: karolherbst: add a breakpoint in nouveau_device_new
09:30 imirkin_: and figure out what fails
09:30 hakzsam: works fine here too
09:33 hakzsam: btw, I tested those two series (drm+mesa) with nouveau master and they worked as expected
09:33 Tom^: karolherbst: yea your nouveau repo destroys my X :P
09:34 Tom^: default kernel one works
09:34 karolherbst: don't think it is related to my changes though :/, though I messed with the nvif a bit, could be that I messed up real good
09:34 imirkin_: can you just try to figure out what fails?
09:35 Tom^: im still on the same commit since the fan patch got added, so it isnt any recent change.
09:35 hakzsam: karolherbst, I suggest you to test with nouveau/libdrm/mesa master without your patches first
09:35 karolherbst: imirkin_: nouveau_object_init
09:35 karolherbst: if (drm->nvif) { nouveau_object_init; ...
09:36 imirkin_: sec
09:36 imirkin_: can you figure out where? :)
09:38 karolherbst: nouveau_object_ioctl returns -13
09:38 karolherbst: in the if (!abi16_object(obj, &func) && drm->nvif) { case
09:39 imirkin_: 13 == EACCES :(
09:39 imirkin_: ben! gr
09:39 imirkin_: hakzsam: did you test render nodes case?
09:40 hakzsam: no
09:40 imirkin_: karolherbst: unless you messed with permission in your branch
09:40 karolherbst: no
09:40 karolherbst: imirkin_: https://github.com/karolherbst/nouveau/compare/master...karolherbst:master_karol_no_thouchy_old
09:41 karolherbst: I just added some nvif interfaces, but that's all
09:41 hakzsam: please try without your bunch of patches :)
09:42 imirkin_: karolherbst: is there something in dmesg?
09:42 karolherbst: no
09:42 imirkin_: oh, only at trace :(
09:42 karolherbst: well I will try with master then without the 4.4 patch
09:42 imirkin_: can you load nouveau with nouveau.debug=trace
09:42 imirkin_: and then run it again?
09:44 karolherbst: hakzsam: it also fails without my changes
09:44 hakzsam: mmh
09:44 imirkin_: karolherbst: can you load it with debug=trace and provide what all it prints?
09:44 imirkin_: (when you try to run some app)
09:45 imirkin_: i'm guessing you'll see "route != owner" or something =/
09:45 hakzsam: probably yeah
09:45 karolherbst: imirkin_: https://gist.github.com/karolherbst/e4350f1bfd514902ce02
09:46 karolherbst: "ioctl: route != owner" :D
09:46 imirkin_: yep.
09:52 Tom^: oh well ping me when you smart people figure it out, cant try your changes imirkin_ until i can use karols clock patches :p
09:52 imirkin_: sending an email to list... =/ maybe ben will see it.
09:52 Tom^: noticing fps drops when the game is running at ~14 fps from the start is a bit hard ;)
09:53 karolherbst: Tom^: which game?
09:55 Tom^: cs:go
09:55 imirkin_: i'm going to push something out to disable it for a while
09:55 imirkin_: or actually...
09:56 imirkin_: can you locally revert a8c474760268f2ebdddd655cea06dbef4500236a in mesa?
09:56 imirkin_: Tom^: karolherbst --^
09:57 karolherbst: imirkin_: yeah, I will test the commit before for now (still bisecting)
09:58 Tom^: imirkin_: so revert and try karols repo again? or master nouveau?
09:58 imirkin_: Tom^: either should be fine
10:03 karolherbst: imirkin_: okay, the commit before a8c474760268f2ebdddd655cea06dbef4500236a works fine
10:04 imirkin_: right
10:04 hakzsam: yeah, because it uses the old interface
10:04 imirkin_: can you try reverting that on top of master?
10:05 hakzsam: karolherbst, how can I reproduce your issue locally (what steps)?
10:05 karolherbst: hakzsam: DRI_PRIME=1 glxinfo
10:05 karolherbst: :D
10:06 karolherbst: well you would also need the nouveau master module and master mesa ;)
10:06 karolherbst: but that should be all
10:06 Tom^: yea same here, reverting that commit make it work
10:06 hakzsam: so, I can't :)
10:06 karolherbst: well
10:06 karolherbst: seems like you don't need prime offloading at all
10:06 karolherbst: cause Tom^ has only his nvidia gpu
10:07 hakzsam: but.. it works fine here with nouveau, libdrm and mesa master with a fermi
10:09 imirkin_: hakzsam: are you using nouveau master?
10:09 hakzsam: yeah
10:10 karolherbst: imirkin_: reverting that also works for me
10:10 imirkin_: ok cool
10:10 imirkin_: i'm going to push that out
10:10 imirkin_: or something like it
10:10 imirkin_: maybe do an env var thing
10:11 karolherbst: mhh
10:11 karolherbst: why not try first and on error disable nvif?
10:11 hakzsam: imirkin_, yeah, please don't revert that commit because I need it :-) an envvar seems fine by me
10:11 Tom^: we are two against one. REVERT. ! =D
10:12 imirkin_: if only this were a democracy...
10:17 maxpas: http://nouveau.freedesktop.org/wiki/CodeNames/#nv110familymaxwell any reason why http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-980-ti is left out of the GM200 section?
10:18 imirkin_: is it a GM200?
10:18 imirkin_: or a GM204?
10:18 maxpas: yes
10:18 imirkin_: hm yeah, GM200 according to pci.ids
10:18 maxpas: http://www.anandtech.com/show/9306/the-nvidia-geforce-gtx-980-ti-review "Now just a bit over two months since the launch of the GTX Titan X, NVIDIA launching their second GM200 card, GeForce GTX 980 Ti."
10:19 imirkin_: anyways, it doesn't really matter... not like anyone with that gpu is likely to use nouveau -- nouveau totally doesn't work on those
10:19 hakzsam: Tom^, are you using nouveau master too?
10:19 imirkin_: probably doesn't even init since we only deal with the GM204/206 cases
10:20 maxpas: http://www.3dcenter.org/news/reihenweise-pascal-und-volta-codenamen-aufgetaucht-gp100-gp102-gp104-gp106-gp107-gp10b-gv100 will Pascal GPUs be supported?
10:20 Tom^: hakzsam: well right now karolherbst https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler branch
10:20 maxpas: GP100, GP102, GP104, GP106, GP107, GP10B
10:21 karolherbst: ohh
10:21 karolherbst: on that branch I really did not mess up with nvif
10:22 imirkin_: maxpas: not anytime soon.
10:23 hakzsam: Tom^, and you only have one gpu?
10:23 Tom^: yup unless i ofc go into uefi and bring the beastie IGP online
10:23 hakzsam: karolherbst, yeah I trust you :)
10:24 Tom^: its an i7 3770 and iirc its an Intel® HD Graphics 4000 . but right now its disabled.
10:24 hakzsam: weird.
10:25 Tom^: i can really confirm that git revert fixed it, X up and running glxgears working. but forgot lib32-mesa so steam complained about it couldnt load nouveau until i reverted it and relaunched steam.
10:26 karolherbst: mhh
10:26 karolherbst: hakzsam: would bisecting nouveau help?
10:26 karolherbst: I could do that later
10:27 Tom^: i could help bisect things too if you want
10:27 Tom^: twice the bisecting twice the findings.
10:27 karolherbst: well I need to buy some stuff, so :D
10:27 Tom^: yea i wont be back until late tonight :P
10:27 hakzsam: Tom^, sure, because that revert makes use of the old interface (not nvif)
10:27 hakzsam: karolherbst, not sure actually
10:39 karolherbst: mhhh
10:39 karolherbst: will try that out anyway
10:40 gryffus_: Any news or roadmap on Fermi reclocking support?
10:40 imirkin_: no
10:40 gryffus_: ok
10:50 karolherbst: ...
10:51 karolherbst: hakzsam: guess what: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=f799923a6cfe5f1392d942d9b3302ecc3b4bc086
10:59 imirkin_: that's what enables the nvif stuff ;)
12:08 karolherbst: imirkin_: why don't you just ignore that guy :D
12:09 imirkin_: ?
12:09 karolherbst: you know, the guy that said that nouveau uses a lot of stuff done by others :p
12:10 imirkin_: oh
12:10 imirkin_: i think it's a prevailing view held by many that i'm trying to disspell.
12:10 karolherbst: mhhh
12:10 karolherbst: it doesn't matter
12:11 karolherbst: I wanted to write something too, but I was thinking he will just bitch back again: "He meant, that your statement is just not true in the meaning you intented it would. There is _no_ issue building your stuff on top of other work. Kernel devs are also not bitching around because _everybody_ just use their work without contributing to the kernel."
12:11 karolherbst: so I won't
12:12 karolherbst: he just threw a "yeah, so what?" statement into the room :p
12:12 hakzsam: karolherbst, I don't know what you did for but your personal nouveau repo doesn't seem to be up-to-date... maybe you did not correctly rebased it or something. Please try out this (in your nouveau repo) 'git checkout master && git remote add darktama git://people.freedesktop.org/~darktama/nouveau && git fetch darktama && git reset --hard darktama/master && clean && build && reload nouveau'
12:12 karolherbst: hakzsam: did you check my master branch?
12:13 hakzsam: yes
12:13 karolherbst: this should be like ~darktama/nouveau just without the 4.4 patch
12:13 hakzsam: what is that 4.4 patchN
12:13 hakzsam: ?
12:13 karolherbst: I removed this one: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=d55c3200d876032f6149c83045eea96c05472dc9
12:13 karolherbst: causes compile errors against 4.3
12:13 hakzsam: sure
12:14 karolherbst: I can diff it though to make sure
12:14 hakzsam: why don't you compile with 4.4? :)
12:14 karolherbst: I just had bad experience with rc kernels and I use some custom patches which don't get ported so fast
12:15 hakzsam: I bet you won't hit your error with darktama tree compiled with 4.4
12:15 karolherbst: ohhh wait
12:15 karolherbst: there is something else different :O
12:15 karolherbst: something nvif related
12:16 karolherbst: where does that come from
12:16 hakzsam: that might explain your weird issue
12:16 karolherbst: yeah
12:16 karolherbst: this really looks like it too
12:18 karolherbst: I am missing that one: http://cgit.freedesktop.org/~darktama/nouveau/commit?id=358c45c68e739e0e51b27169720d1252d9068560
12:18 karolherbst: but how...
12:18 hakzsam: try out with that patch applied
12:18 karolherbst: ohhhh I think I know
12:18 karolherbst: I just picked the new patches from the top
12:19 karolherbst: and I bet he repushed his tree with some changes done earlier
12:19 hakzsam: sometimes ben uses git push --force ...
12:19 karolherbst: yeah I know
12:29 karolherbst: imirkin_: seems like I really messed up rebasing my stuff on bens tree :/
12:29 imirkin_: yeah that happens
12:29 imirkin_: esp when he force-pushes
12:29 imirkin_: which is often
12:30 hakzsam: karolherbst, is your issue fixed?
12:30 karolherbst: still rebuilding mesa, but I assume it gets fixed by this
12:30 karolherbst: the changes are related to the issue
12:30 hakzsam: yeah
12:30 karolherbst: sorry for the troubles though
12:31 hakzsam: np
12:31 imirkin_: karolherbst: ah, so you really did have rebase fail?
12:31 karolherbst: well I just picked the newest commits from the tree on top of mine :D
12:31 imirkin_: yeah that doesn't work
12:33 hakzsam: imirkin_, the edgeflag patch still needs your attention btw :-)
12:38 imirkin_: hakzsam: so it is........
12:38 imirkin_: sorry
12:39 karolherbst: yep, it's working now
12:40 hakzsam: imirkin_, and sorry for annoying about that patch, I just try to not forget it
12:40 hakzsam: karolherbst, cool
12:40 imirkin_: hakzsam: no, please continue
12:41 imirkin_: karolherbst: can you reply to that email i sent saying it's all good now?
12:41 imirkin_: karolherbst: i guess my patch is unnecessary btw?
12:41 karolherbst: already did
12:42 imirkin_: cool
13:21 imirkin_: ok. i think ssbo/atomic is getting semi-done.
13:21 imirkin_: now it's a matter of refactoring all those shit commits
13:21 imirkin_: into a few logical ones.
13:23 imirkin_: but on the off chance that people have a burning desire to have ssbo or atomic counters, take a look at my atomic3 branch on github.
13:23 imirkin_: oh i should probably test something with dolphin... maybe i can harass someone into giving me a dff which needs them
13:33 karolherbst: imirkin_: for what could I use it?
13:34 hakzsam: imirkin_, I will be glad to have a look once your branch is a bit more refactored :-)
13:35 imirkin_: karolherbst: absolutely nothing
13:40 karolherbst: imirkin_: so why are you doing this? :D
13:40 imirkin_: karolherbst: i dunno, maybe something uses it for something
13:40 imirkin_: karolherbst: also atomic counters are part of GL 4.2, ssbo is part of GL 4.3
13:40 imirkin_: and at least ssbo is pretty essential to making ARB_compute_shader useful
13:41 karolherbst: ohh okay
14:33 glennk: imirkin_, i guess atomic counters are more useful on radeon hw than on nv?
14:33 imirkin_: glennk: well, something either uses them or it doesn't
14:33 imirkin_: glennk: i'm unaware of anything using them :)
14:33 glennk: i've heard of dolphin wanting to use them, but not actually doing so yet
14:34 imirkin_: they use ssbo now... they want atomicMin/max
14:34 glennk: yeah, and thats real slow on radeon
14:34 glennk: memory atomics that is
14:35 imirkin_: well i've reordered my commits now into a gallium + st chunk and a nouveau chunk
14:35 glennk: latency = round trip to vram, stalls the shader a few hundred cycles
14:35 imirkin_: if you want to play with it on r600, be my guest
14:35 glennk: if i can get <redacted> sb working with tess that was my next project
14:36 imirkin_: hehe ok
14:36 imirkin_: by then i might actually have clean-looking commits
14:54 karolherbst: imirkin_: I thought I look over those patches, but then I saw there are many of them and now I am too tired for this
14:55 Tom^: that was that, not as good as the first 3 ones. oh well :P
14:57 Tom^: karolherbst: will the stable_reclocking_kepler get updated too?
15:00 Tom^: oh nvm seems the changes went in 3 hours ago, yet there wasnt a commit
15:18 karlmag: oh yeah... hate those marketing people... :-P
15:19 imirkin: karlmag: yeah, and lots of them need to be combined
15:19 karlmag: ... and I'm just half way through Curie
15:19 imirkin: karolherbst: --^
15:19 imirkin: karolherbst: it wasn't really an invitation to review
15:19 karlmag: imirkin: probably.. and also, I suspect I am misreading some stuff
15:19 imirkin: and i actually remembered that i totally forgot about barriers... gr. unfortunately ssbo has basically 0 piglit coverage.
15:20 imirkin: karlmag: that note was meant for karolherbst re my commits
15:20 karlmag: oh, right :-D
15:20 imirkin: karlmag: but it sounds like it applies to your situation quite nicely :)
15:20 karlmag: tru dat
15:20 imirkin: i'm used to typing the first 2-3 letters + tab... doesn't work for you guys
15:21 karlmag: imirkin: sorry for coming in and making life difficut for you ;-)
15:21 imirkin: lol
15:21 karlmag: *rotflol*
15:22 karlmag: *difficult even.. can't spell.. :-P
15:22 karTom^: imirkin: hi.
15:22 imirkin: hehe
15:23 karlmag: but after using my nic for about 20 years I don't think I'll change it any time soon.. :-P
15:23 karlmag: nick even
15:24 karlmag:looks for his missing 'l's under the desk
15:28 karlmag: meh.. "GS, GT, GTO, GTX, GX2, Go, Go GTX" why? I mean, really? Why..?
15:28 imirkin: forgot about GTS?
15:29 karlmag: this was a particular one - 7900
15:29 imirkin: and MX/Ti
15:29 imirkin: no... 8800 GTS was a thing
15:29 imirkin: as was GTS 250
15:29 karlmag: and there are several others too..
15:31 Tom^: imirkin: nope sorry fps drop still there
15:31 imirkin: Tom^: heh ok. well it was a long shot
15:32 Tom^: hm Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
15:32 Tom^: spamming my steam terminal
15:35 karolherbst: Tom^: back
15:35 karolherbst: Tom^: I updated all my branches
15:36 herbstkarol: :p
15:36 karlmag: haha
15:36 karolherbst: imirkin: well on amd there was also stuff like XL and XXL and XXL Pro and stuff :D
15:37 karlmag:starts to wave a big clue-by-four...
15:39 Tom^: imirkin: not entirerly sure why its only 360p , silly youtube. but thought id give you a video of what happends after ~5 minutes. every shot seemingly no matter if its mine or someone else drops the fps from 120 to 30-60
15:40 Tom^: imirkin: https://www.youtube.com/watch?v=IKRHGhB9PtI
15:40 karolherbst: "This video is private."
15:40 imirkin: Tom^: "this video is private"
15:40 Tom^: uhm
15:40 imirkin: anyways, how we know how you get your framerates...
15:40 imirkin: you play at 360p :)
15:40 imirkin: now*
15:41 Tom^: https://www.youtube.com/watch?v=IKRHGhB9PtI&feature=youtu.be still private?
15:41 karolherbst: :D
15:41 Tom^: if so i give up with youtube
15:41 imirkin: Tom^: good now
15:41 imirkin: i dunno, 1080p comes up as an option for me
15:41 Tom^: at the beginning the fps never flickers
15:41 Tom^: oh so it does
15:42 Tom^: and thats just me alone shit really goes low when its like 4 people firing :P
15:42 karolherbst: mhhh
15:43 Tom^: its so weird tho that it doesnt happend the first ~5 minutes, because according to the gallium hud im not nearly running out of vram either
15:43 Tom^: its using like at most 500mb total
15:43 Tom^: so yea *shrug*
15:43 karolherbst: Tom^: did you enable multicore rendering? :D
15:44 Tom^: yea otherwise im on like 50fps average constantly
15:44 Tom^: or did you mean some mesa env var imirkin havent told me about?
15:44 Tom^: :<
15:44 karolherbst: no
15:44 glennk: anything in dmesg?
15:44 karolherbst: ingame
15:45 Tom^: oh look and behold ive actually found some output useful
15:51 Tom^: imirkin: https://gist.github.com/anonymous/a96fca3e00e5748ba9a6 both that gl_invalid_enum and the "Leaking 701 vertex shaders" "Leaking 2847 pixel shaders" sounds interesting.
15:52 imirkin: Tom^: interesting, yes. but that's purely application-side
15:54 karolherbst: Tom^: apitrace and maybe glretrace tells you something
15:54 karolherbst: or maybe this is just normal
15:54 karolherbst: :D
16:17 karlmag: hmm.. just noticed.. on CodeNames page; Heading "General code names (supported cards)", the "Code name" links. First five doesn't go anywhere, because the links are wrong. They are (on the form) "#nv10family", but should be (on the form) "#nv10familycelsius"
17:11 karlmag: "NV63 (MCP73)" is that correct or should the latter be 63 too?
17:12 imirkin: probably correct
17:12 imirkin: check lspci
17:12 imirkin: or rather, pci.ids
17:16 karlmag: ok.. guess it's correct then..
17:16 karlmag: was kind of "the odd one out"
17:17 imirkin: all the onboard stuff is odd
17:18 karlmag:bangs head on the desk..
17:19 karlmag: so the "GeForce <something> / nForce <something else>" is actually the same card then.. *sigh*
17:20 karlmag: also means the CodeNames page is a bit incomplete I suppose..
17:20 imirkin: you see why i want people to just use the damn chip code?
17:21 karlmag: Looking at NV63 - in the pci.ids I find the three gforce numbers listed have one corresponding nforce number *each*
17:21 karlmag: no kidding...
17:21 karlmag: It's more than a mess..
17:23 karlmag: It also looks to be listed as C73 in pci.ids
17:23 karlmag: lovely, just lovely..
17:24 karlmag: I think I'll just use what's on CodeNames page for now..
17:30 karlmag: not sure I can take more than one family at one time now.. :-P
17:31 karlmag: but I guess tesla (the next) is the biggest one.
17:32 imirkin: ha ha ha
17:34 karlmag: imirkin: you won't laugh when you will have to proofread it *lol*
17:34 karlmag: :-P
17:34 imirkin: you'd be amazed how much useless information is in my head
17:35 karlmag: yes and no (based on own experience :-P )
17:35 karlmag: did you see my "bug report" btw?
17:36 imirkin: mmmm
17:36 imirkin: probably, but i've forgotten it by now if i have
17:36 karlmag: the link errors on the CodeNames page
17:36 imirkin: oh that
17:37 imirkin: yeah i should probably fix it
17:37 karlmag: It would look (or at least feel) better for anyone trying those links
17:40 imirkin: karlmag: updated.
17:41 karlmag: cool, thanks
17:42 karlmag: ah, you link to "name=", not "id=" I haven't done much html since last part of 1990 I think :-P
17:43 karlmag: 1990s that is
17:43 karlmag: decade, not year
17:43 karlmag: especially since html wasn't invented in 1990 IIRC
17:43 imirkin: hehe
17:43 imirkin: netscape 1.1n -- the network edition of netscape. good times.
17:44 karlmag: I do remember the first time I saw the www
17:44 karlmag: 1994
17:44 karlmag: at uni
17:45 imirkin: ah, you're older than me :)
17:45 karlmag: someone summoned a small group (me included) to show us this new cool program he had come across..
17:47 karlmag: imirkin: might be
17:47 karlmag: I'm 41
17:47 imirkin: yeah, i was in grade school in 94
17:51 karlmag: imirkin: hehe.. well, still starting to be a while ago now..
17:51 imirkin: yes... ancient times
17:51 imirkin: the days of 40MB hard drives
17:54 karlmag: hehe.. well.. bigger actually.. Got my (or technically family) PC in '91 or '92 and that had 210MB disk. And I remember one could get 430MB disks then too. (Worked part time at a computer store)
17:56 karlmag: Was before nVidia existed. Had a Tseng ET4000 card.
17:57 karlmag: One of the more fancy cards one could have at the time.
18:53 Tom^: 3dfx voodoo !
18:53 Tom^: i miss that card and era :P
18:54 imirkin: alternate scanlines... the original SLI
18:56 karlmag: heh
18:58 imirkin: back then you could actually do SLI
18:58 Tom^: really?
18:58 Tom^: didnt even know that
18:59 imirkin: or was it alternate frames? i forget
18:59 imirkin: either way, well before off-screen rendering was a thing
19:00 karlmag: interlaced you mean?
19:01 imirkin: yeah
19:02 imirkin: except there was a passthrough cable
19:02 imirkin: which would combine them into a single picture
19:02 imirkin: with voodoo2
19:02 karlmag: I remember "non-interlaced" was a big thing. (as being better than interlaced))
19:03 imirkin: i remember 1152x864 as being the ultimate cheat-code to getting higher res on a 1024x768 monitor
19:03 Tom^: i remember CRTS running at 150hz or even more
19:03 Tom^: =D
19:03 imirkin: heh
19:04 karlmag: hehe.. 1152x864 was a standard resolution on sunos/solaris
19:04 imirkin: i ended up with a nice sony trinitron 1600x1200@85hz. it was awesome.
19:06 karlmag: my first monitor was a 14" 1024x768 non-interlaced. I *think* I might have it stashed away somewhere still :-P
19:07 imirkin: karlmag: time to clean :)
19:09 karlmag: oh.. very true, but there's *lots* before that in the queue.
19:09 karlmag: :-P
19:12 imirkin: well, if you haven't gotten to it in 20 years, i doubt it'll pop to the top of the list anytime soon :)
19:13 karlmag: don't think I've used it much the past 15 at least :-P
19:13 Tom^: lol :P
19:14 Tom^: ive just planned to throw away 2 cheapass benq leds 21" 1920x1080 because i got IPS monitors instead.
19:14 karlmag: I have a huge pile of old *nix computers that will go before that monitor I think (if it's actually still here)
19:14 Tom^: i hate garbage and i hate piles of it.
19:14 karlmag: Tom^: give them to someone who wants them if nothing else then. If they work at least.
19:14 imirkin: give them to karlmag
19:14 Tom^: sure come and get them
19:14 karlmag: Tom^: and you could use them for nouveau testing. :-)
19:15 Tom^: my 22" eizo IPS does just fine for nouveau :P
19:15 karlmag: multi monitor setups?
19:15 Tom^: two monitors yes
19:15 karlmag: 4+ monitors?
19:15 imirkin: i should probably get a new monitor at some point... still using a dell U2406 or so... ancient, no hdmi/dp inputs, only 1 dvi
19:15 Tom^: i was using three but it was horrible with games and X
19:16 Tom^: could never get it to sync to the right one, games wouldnt open fullscreened on right one etc. :P
19:16 karlmag: sounds like you have issues that needs solving then ;-)
19:16 imirkin: make that 2407WFP
19:16 Tom^: karlmag: gl with closed source games.
19:16 karlmag: still
19:17 Tom^: but yea these IPS ones are beautiful, the TTY has never been so colorful.
19:17 Tom^: xD
19:18 karlmag: hmm.. using 2x 1680x1050 at the moment.
19:18 karlmag: 22"
19:19 karlmag: have 3x 24" 1920x1080 lined up when I manage to clean my desk and find room to set them all up :-P
19:20 Tom^: i feel like such a hobo, drunk, drinking beers and karolherbst looting the entire town for our and mine wealth.
19:20 imirkin: bleh. all this x1080 junk is so annoying
19:20 imirkin: i want my extra 120 pixels!
19:20 Tom^: imirkin: actually when i got the refurbished t60p i got to say 4:3 is so much better then 16:9
19:20 imirkin: esp since an 80-char wide window tends to be ~600 pixels, so it just doesn't fit on a rotated x1080 monitor
19:20 imirkin: well yeah. but i can't go against market trends
19:20 karlmag: I do have one 1920x1200 monitor actually.
19:21 imirkin: i don't buy enough monitors to make them build 4:3 monitors
19:21 imirkin: (since the last one i bought was in 2007 or so)
19:23 Tom^: i mean if you want the 21.5" 1920x1080 cheapass LED i could actually send it to you if you simply pay for the shipping cost :P
19:24 karlmag: I did have some <whatever>x900 19" 16:9 monitors (well, still have them). those 900 is more annoying than 1050 (or 1080)
19:25 karlmag: I'd love a couple of 28" 4k monitors.. Not sure where I would put them, but hey.. luxury problems are also problems :-P
19:26 Tom^: there is just one problem with 4k
19:26 karlmag: and that is?
19:26 Tom^: or well two, i got bad eyesight. and nothing is released in 4k and not even my 780ti beastie can handle games at it.
19:26 Tom^: i think that makes 3 actually
19:27 karlmag: I think I have something that should be able to drive them
19:28 karlmag: a 960
19:28 Tom^: i dont want to boast but the 780ti is twice as powerful :P
19:28 Tom^: my standards perhaps is a bit over the edge
19:28 karlmag: if you say so
19:29 karlmag: I also have a Radeon R9 390 that should be able to drive them I think
19:29 Tom^: but yea as long as you dont game and require them fps i guess 4k is fine at the moment
19:30 karlmag: but there is that.. I don't really game much, so..
19:30 Tom^: i also saw some guy in #archlinux having issues rendering 4k on a 58xx something i7
19:32 karlmag: given I don't have a 4k monitor I can't really test
19:33 Tom^: so yea 4k takes its toll on the HW :P
19:40 karlmag: I guess
19:47 orbea: where is the right place to ask about mesa? I'm stuck on building their git with llvm 3.7.0 and their git mirrors are in a perpetually broken state...
19:48 Tom^: orbea: well pastebin the errors and we might give you a hint or two
19:48 orbea: it just doesn't find the shared libs
19:48 orbea: in teh configure
19:48 orbea: they're in a standard location
19:49 orbea: disabling them to use the static llvm instead works, but that is not really a fix
19:49 imirkin: orbea: who are "their"? afaik mesa git always works fine...
19:49 orbea: llvm, their upstream is broken
19:49 imirkin: oh. that sucks
19:49 imirkin: you can fix that glitch by just not using llvm
19:49 imirkin: nouveau has little to no use for it
19:50 imirkin: --disable-gallium-llvm iirc shoudl do the trick
19:50 orbea: im considering that, Im not sure how much I'd have to recompile without it on slackware yet
19:50 imirkin: just mesa
19:50 orbea: im trying
19:53 orbea: yep, that disabled llvm, thanks
20:00 Tom^: imirkin: horrible gist i know, but what of this do i actually need?
20:00 Tom^: https://gist.github.com/anonymous/fff47367eea6a857b125
20:01 Tom^: osmesa, gles, xa etc all is just greece to me :P
20:03 imirkin: Tom^: you can nuke osmesa, omx, gles1
20:03 Tom^: nuked! im probably nuking svga, wayland too.
20:04 Tom^: and vdpau since i aint using that
21:00 karolherbst: Tom^: --with-dri-drivers=
21:00 karolherbst: you don't need any dri drivers
21:00 karolherbst: and disable classic
21:01 imirkin: who knows, perhaps he has a Riva TNT plugged in next to his GTX 780 Ti
21:01 imirkin: for a nice SLI speedup :)
21:01 Tom^: LOL
21:33 karolherbst: imirkin: maybe I should start doing some stuff on the mesa side, cause I got tons of stuff pending kernel side and I just don't want to have there even more stuff :/ any good idea what I could check out?
21:34 karolherbst: mhh maybe I could also try to figure that nvenc thing out
21:40 imirkin: karolherbst: that'd be pretty awesome
21:40 karolherbst: well at least the nvidia api isn't that hard to use
21:40 imirkin: take a look at the trello for inspiration
21:41 karolherbst: basically it gets yuv frames as input and you read just the output back, but no idea what the nvidia library is doing
21:41 imirkin: mmt to the rescue
21:41 imirkin: use mmiotrace to grab the firmware it most likely uploads
21:42 karolherbst: I don't find the nvenc trello entry
21:43 imirkin: karolherbst: added ;)
21:43 karolherbst: :D
21:50 karolherbst: imirkin: but for the case I give up, any other interesting task?
21:54 imirkin: hehe
21:54 imirkin: i dunno... define interesting
21:55 imirkin: what are you interested in?
21:55 karolherbst: stuff which somehow helps stuff I might want to do with my gpu :D
21:56 karolherbst: well anyway it should be doable on my gpu, don't want to depend on other hardware for the most parts
21:56 imirkin: you could pipe ARB_framebuffer_no_attachments through to gallium on top of my atomic/ssbo branch -- should be moderately easy
21:56 karolherbst: mhh are there any piglit stuff for that ready?
21:56 imirkin: i think i played with it at one point but reverted my changes
21:56 imirkin: because the primary purpose of my branch was atomic/ssbo, and this was just a distraction
21:57 imirkin: but i think i was fairly close
21:57 imirkin: yeah, there should be piglit tests for it
21:57 imirkin: i965 supports it
21:57 imirkin: it's the sort of ext that makes no sense until you have one of atomic/ssbo/images
21:57 imirkin: same with ARB_compute_shader, but that might be a harder one to start with :)
21:59 imirkin: but it's basically like a "compute shader lite" extension
21:59 imirkin: all you have to do is add a couple of params to pipe_framebuffer_state, and a teensy little bit of backend work
22:00 imirkin: [and actually you might not even have to add the fb state params... not 100% sure]
22:00 karolherbst: mhhh
22:00 karolherbst: I think OpenGL stuff is still a bit out of my reach. I just read the extension spec and don't really get what this ext is doing :D
22:00 imirkin: sooo
22:01 imirkin: normally you use GL to draw things
22:01 imirkin: these things are drawn on a framebuffer
22:01 imirkin: a framebuffer is made up of various attachments, which actually hold the drawn data
22:01 imirkin: this ext allows you to have a purely virtual framebuffer
22:01 imirkin: i.e. you still rasterize primitives, do all the usual stuff, but... you don't output a color. or depth. at all.
22:02 imirkin: normally the viewport size is inferred from the framebuffer attachments, but if there are none, there needs to be a way to pass that along
22:03 imirkin: anyways, all this stuff can be a bit tricky
22:04 imirkin:&