00:58mlankhorst: bleh parallel piglit still broken :(
01:03mlankhorst: skeggsb: ping for libdrm patches
01:04mlankhorst: can you review them, or at least ack?
01:20airlied: mlankhorst: he's on holidays
01:20airlied: what is broken with paralllel piglit btw? libdrm or kernel?
02:47mlankhorst: probably generic code
02:47mlankhorst: since it affects all my cards equally, at some point eviction fails and the fence bo contains random garbage
03:11mlankhorst: I've tried a bunch of things, like adding vm guard pages, making all vm spaces only have a single entry for the fence bo (that happened to be at a fixed location), and trying to debug it, but ran out of ideas :/
12:26pmoreau: So, blacksmith it will be
14:01joystick21: hello boyz and gals, I'm eagerly back, this time i'd want to know where are the ioctls of nouveau defined?
14:04joystick21: imirkin: i am very dissapointed that you lag on such a clearly formed question!;)
14:09imirkin_: joystick21: i think you're looking for http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nouveau_abi16.c
14:12joystick21: imirkin: but is the PUSH_DATA also an ioctl?
14:12imirkin_: it's a macro
14:12imirkin_: which roughly does a = b
14:13imirkin_: perhaps you were asking about the libdrm interface which drives those ioctls?
14:13joystick21: but does it write to some mmio reg?
14:14imirkin_: in which case you're looking for http://cgit.freedesktop.org/mesa/drm/tree/nouveau/nouveau.h
14:14imirkin_: PUSH_DATA? no. look at its definition
14:16joystick21: allright, but something that submits this data (i.e submits PUSH_DATA contents to kernel), should be an ioctl right, like a pushbuf ioctl, however i have not found how they define those ioctls?
14:17imirkin_: they're in abi16
14:17imirkin_: check what libdrm does, that's the userspace end of it
14:35joystick21: but none of those libdrm files even include ioctl.h
14:42joystick21: http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nouveau_drm.c#L884 ah yeah right, ok
14:45joystick21: so it looks like they dont have to include, they just need to send a code to the device
15:57imirkin: if anyone has a nva3-nvaf plugged in, i'd love to get 'glxinfo -l -s' output against mesa 10.5-rcX. this is for my glxinfo page (http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html)
16:47buhman: how about nve6? :3
16:48imirkin: someone sent me kepler already
16:48imirkin: i'm only missing the nva3-nvaf column
16:49buhman: heh, I meant https://bugs.freedesktop.org/show_bug.cgi?id=70354
16:51buhman: imirkin: why are some blocks empty and grey, while others are empty and colored?
16:51imirkin: gray means "unsupportable"
16:51imirkin: [without major shenanigans]
16:52buhman: so then why do the vendor drivers support it then?
16:52imirkin: they don't
16:53imirkin: there should never be a dot on a grayed out block
16:53buhman: ARB_compute_shader for example on R600
16:53imirkin: let me know if i messed up
16:53buhman: is colored dot on vendor
16:53buhman: and grey square on 10.5
16:53imirkin: please read the column headings.
16:54imirkin: (i couldn't get anyone to send me a glxinfo from catalyst on r600/r700)
16:54buhman: too bad I don't have a r600 anymore
16:54imirkin: catalyst 14.x doesn't support it anymore either
16:54buhman: well then
16:55imirkin: i wasn't too worried, that page is mostly about mesa... the vendor was just a fun little distraction
16:55buhman: I think it's cool
16:55airlied: I had an fglrx once from rv635 somewhgere
16:55buhman: might be nice to clarify multiple vendor versions?
16:56airlied:can't find it now, will generate again someday
16:56imirkin: airlied: ok, make sure to do -l -s :)
16:57buhman: imirkin: I'd run you glxinfo every day if you made it so nouveau doesn't explode when it loads on my hardware ;p
16:58imirkin: unfortunately i don't have the skills, time, or hardware required
16:58imirkin: [in approximately that order of importance]