02:13 imirkin_: skeggsb: why doesn't GF117 have pmu hooked up?
02:35 mlankhorst: oversight probably
03:21 mupuf: it may even be my fault
03:21 mupuf: wait, no, I only added it for maxwell, not fermi
03:26 RSpliet: mupuf: well I guess the problem is that nobody added it :-P
03:26 RSpliet: the whole world is at fault :-D
03:26 imirkin_: quickly! determine who's at fault!
03:27 RSpliet: blame all the things!
03:27 imirkin_: except yourself, naturally
03:29 imirkin_: mupuf: when 11.1 gets branched, i'd like to do another big piglit run... just a heads up :)
03:40 mupuf: imirkin_: naturally :)
03:40 mupuf: imirkin_: definitely, when is it expected?
03:41 mupuf: I would also like to check the evolution of performance on some benchmarks too
03:41 imirkin_: mupuf: a few weeks i guess
03:41 mupuf: ack, very good
03:41 imirkin_: mupuf: always up for that... i also sent shader-db patches to make it all work with nouveau
03:41 mupuf: I have seen that
03:42 imirkin_: gonna start putting stuff into that private repo
03:42 mupuf: I was hosting a friend for 9 days so I was mostly mute but I followed what happened on the nouveau side
03:42 mupuf: very good
03:42 imirkin_: i have a ton of traces hanging around locally, will start by extracting those
03:43 mupuf: I should ask if I can copy the shaderdb we have at Intel into this private repo too
03:43 mupuf: hopefully, it is fine
03:43 imirkin_: that'd be convenient :)
03:43 imirkin_: it has been offered to me privately, but it was unclear whether it could be shared
03:44 mupuf: yeah, need to check that
03:44 mupuf: legally, I am sure we can't, but in the end, who cares as long as it is kept private, right?
03:44 imirkin_: hehe
03:44 imirkin_: ianal
03:44 mupuf: lawyers would say no :p
03:44 imirkin_: good thing ianal then
03:45 mwk: I'm pretty sure you shouldn't be saying these things on a public channel, you know :p
03:46 mupuf: really? Why? O;-)
03:46 mupuf: In the mean time, we can always extract shaders from the few games we actually care about
03:48 imirkin_: that's what i've been doing locally
03:48 imirkin_: i'm gonig to be using it for future compiler improvements
05:04 imirkin_: hakzsam-: are you still working on https://trello.com/c/LUcK89ey/86-nv50-bin-point-vertex-id-auto ?
05:06 hakzsam-: imirkin, no
05:07 hakzsam-: this is really a low priority for me :)
05:07 hakzsam-: are you updating the board?
05:09 hakzsam-: imirkin, I left the item
05:10 imirkin_: hakzsam-: i was just lookign at it and wondering if you were still lookign at it :)
05:11 imirkin_: we need new contributors....
05:11 hakzsam-: imirkin, this should not be too difficult but I have more interesting stuff to complete :)
05:11 hakzsam-: yeah...
05:12 imirkin_: or old ones :)
05:12 imirkin_: i'm not picky
05:14 hakzsam-: :)
05:17 mupuf: imirkin_: :p
05:19 imirkin_: i'm just looking at the list of items, and it ain't getting smaller
05:19 imirkin_: and i can only dedicate so much time towards this stuff
05:31 RSpliet: imirkin_: not that it helps, but I think it's always been like that... with trello it's just more visible
05:31 RSpliet: we do have Hans on board now though! :-)
05:31 imirkin_: RSpliet: you're right, it doesn't help :p
05:32 imirkin_: yeah, but he's looking at llvm/tgsi now i guess
05:32 imirkin_: seems quite capable... figured out that double immediate thing in no time
05:32 RSpliet: he's very capable at doing... everything
05:32 RSpliet: seriously, I keep bumping into him every project I do
05:32 imirkin_: hehe
05:32 imirkin_: he's done a lot of input stuff too afaik
05:32 RSpliet: yep
05:32 RSpliet: and allwinner
05:33 imirkin_: ah :)
05:33 RSpliet: I had a patch a while ago for gtkterm. Nothing big, but when I looked through the repo, the most recent commit to it was... Hans
05:34 imirkin_: a redhat project apparently
05:34 RSpliet: didn't use to be
05:35 RSpliet: rather a red hat salvaged project
05:35 imirkin_: right
06:54 karolherbst: imirkin_: I think I am done with the sysfs -> debugfs conversion now. I changed it a bit, so that the seq_file->private object is now the same withing the drm debugfs stuff and the nouveau debugfs stuff to make it easier to write something for it
06:54 karolherbst: want to take a final look at it?
06:55 imirkin_: i'm no expert in that stuff...
06:55 imirkin_: send it out, get feedback, repeat
06:55 karolherbst: I mean something like: if a new dev looks at it, does he know what to do to add a new file?
06:55 imirkin_: yeah, just look at how the other files are done
06:56 karolherbst: right, an in my previous version, it was different depending on how you add that debugfs file
06:56 karolherbst: private was drm_info_node for the "simple" files through drm and drm_device for the complicated ones
06:56 karolherbst: and I thought, this is a bad design
07:24 karolherbst: imirkin_: any idea? https://gist.github.com/karolherbst/964f3cbebd7db9d34af6
07:25 imirkin_: some sort of pushbuf screwup probably
07:26 imirkin_: probably everything after the write fault is fake
07:26 karolherbst: imirkin_: I was trying to run a game through wine/gallium nine with the "thread_submit=true" option, no idea what it does
07:26 karolherbst: I just got this
07:26 karolherbst: the nine gues just told me it helps with prime setups and frame ordering
07:27 imirkin_: dunno what thread_submit does, but if it causes the driver to do things from multiple threads, then it'll fail pretty badly
07:27 karolherbst: mhhh
07:28 imirkin_: iirc it just starts up another thread to submit swaps though, so that should be fine
07:28 imirkin_: dunno. maybe not.
07:28 karolherbst: though here is no OpenGL involved at all anymore, so mhhh
07:28 imirkin_: huh? why does that matter?
07:28 karolherbst: no idea :D
07:30 karolherbst: imirkin_: somehow they wait on a fence until it can push data
07:30 karolherbst: and they might do it multithreaded though instead of collecting stuff and work that up in one thread, not really sure though
07:32 imirkin_: yeah i dunno
07:33 imirkin_: i'd have to look at the code
07:33 imirkin_: to see what exactly they do in the "other" thread
07:36 karolherbst: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/nine/swapchain9.c
07:36 karolherbst: pend_present
07:36 karolherbst: also in line 747 is the decision made how to handle the frame
07:52 pmoreau: imirkin_: I'll try to understand how if/else if/else blocks should be represented in NV50 IR (I got something to work, but the compiler doesn't optimise it away, even if all conditional are known at compile time, so I'm most likely doing something wrong).
07:52 pmoreau: And then I could pick one item from the todo list :-)
07:53 pmoreau: But, I'll see that later today, have to run to my swedish course first…
07:53 imirkin_: uhm... well if the compiler knows the result of the condition, iirc, that's optimized... not very well though
07:53 imirkin_: control flow manipulation is kinda sucky
07:55 pmoreau: I don't have any "join at" or things like that, so could be it doesn't realise it's one if/else if/else block, and think of it as multiple if blocks? Or I didn't set the tree properly, or whatever
07:55 pmoreau: Still learning on how it should work
07:58 imirkin_: yeahhhh i forget how that all works
07:58 imirkin_: iirc the joins get dropped in automagically
08:29 bozsikarmand: Hi! Maybe my following question will be a bit noobish - and also theoretical because I do not have the card yet - but I would like to see things clearly: I have ordered a GTX960 to use it under Windows. Then is thought it would be nice to use it under Ubuntu too. nVidia made its newer cards cooling system to work in a fanless mode until a specified heat level is not reached. My question is that, is this functionality implemented to
08:29 bozsikarmand: the opensource driver so under a higher heat level or heavier lad will the fans turn on? During Ubuntu livecd install nouveau is active, so that is why i am asking. I do not want to cook it. :/ Or is it controlled by the hardware itself? Thanks
08:30 imirkin_: bozsikarmand: GTX 960 is basically unsupported by nouveau
08:30 imirkin_: not sure what the fan situation is with it tbh
08:31 imirkin_: but you should definitely not be expecting to use the opensource stack on top of a GTX 9xx gpu anytime soon
08:31 RSpliet: bizsikarmand: I'm guessing that you wouldn't fry your card in a ubuntu installation for the same reason that you probably wouldn't fry your GPU when changing BIOS settings
08:32 RSpliet: fan is running at audible speed, clocks remain low
08:33 bozsikarmand: imirkin_, that's interesting. My sources (google and so on) were a bit silly as it seems. :D
08:33 bozsikarmand: Thanks for the answer.
08:33 imirkin_: bozsikarmand: modesetting works, but no acceleration
08:34 imirkin_: bozsikarmand: lots of people equate "acceleration" with 3d games, but the reality is that a ton more stuff depends on it
08:36 ekaron: since nvidia doesn't say how their stuff works, it has to be worked out blind, so it will take a while with the new GPUs.
08:37 karolherbst: ekaron: yeah, but that's not the issue here
08:38 mwk: ekaron: they now sign firmware with crypto signatures, so you *can't* use free software even if you figure stuff out
08:39 mwk: until and unless they take pity on you and give you packaged binary blobs that you can talk to from your free driver
08:40 mwk: welcome to the brave new world
08:40 imirkin_: mwk: well, an additional problem is our tooling isn't able to capture the fw :)
08:41 mwk: imirkin_: not in mmiotrace?
08:41 imirkin_: mwk: no, it's DMA'd in from the looks of it
08:41 mwk: eh
08:41 mwk: PDAEMON has always been uploaded like that, no big deal
08:42 imirkin_: i don't personally have the hw, so i dunno
08:42 mwk: you can just extract it from nvidia.ko if you know where to look (and what deflate streams look like)
08:42 imirkin_: yeah... they changed that around too
08:42 imirkin_: no more searching for gzip headers :)
08:42 mwk: not gzip, raw deflate
08:42 imirkin_: starting with the 350 series, no longer compresed
08:42 imirkin_: yeah wtvr
08:42 mwk: huh.
08:43 mwk: that's going to be fun
08:43 mwk: still, that part is solvable... legal issues surrounding it are not
08:43 mwk: ditto for replacement firmware
08:44 karolherbst: couldn't we just search for stuff we are sure of is inside the firmware?
08:44 mwk: karolherbst: not if it's compressed
08:44 mwk: ... or encrypted
08:44 mwk: who knows what they're doing now.
08:45 karolherbst: ohh mhh :/
08:58 ekaron: Wow, they block the card from loading anything not signed, so is there a cleanroom way to get the keys they use to sign stuff and sign it ourselves?
08:58 ekaron: brute force?
08:59 ekaron: and as all villains do, they smile and say it's for 'security'
09:00 imirkin_: mwk: afaik it's not encrypted... just signed.
09:03 mwk: *shrug* not like it matters much
09:03 mwk: ekaron: of course, it's called "secure boot"
09:04 mwk: and you've heard of iphone jailbreaking exploits fun, right? something similiar would be required here
09:05 mlankhorst: to be honest secure boot would be a good thing if you have the keys..
09:06 mwk: ... for a fucking GPU?
09:06 mwk: it's not a *boot* device in the first place
09:10 prettychimp: mwk: what does that firmware signing means, does not nvidia driver itself also have to send a string to unlock the hw?
09:10 mwk: I don't know of any unlocking string
09:11 mwk: except for some trivial ancient stuff, but that's more of a protection against accidental damage to VGA regs..
09:11 mwk: firmware signing means that the management software that runs on the GPU will only be accepted if it comes with an nvidia signature
09:12 mwk: and without the management software, you cannot do anything interesting with the GPU
09:12 mwk: as in, no 2D/3D acceleration, no GPGPU
09:12 mwk: although basic display is ok
09:15 imirkin_: ugh. stupid hw is too smart for its own good. won't let me clear a depth/stencil storage type attached to a color rt.
09:18 prettychimp: mwk: yeah it really should be sophisticated to trace how that string is being sent anyways, it is likely sent in small hunks, not the whole string together, via whatever mechanism, its probably almost impossible to crack
09:19 mwk: prettychimp: there is no unlocking string
09:19 mwk: seriously, that sounds like a conspiracy theory
09:20 mwk: why would they have an unlocking string, when they have a solid AES-CMAC signature...
09:21 prettychimp: mwk: hmm, but this aes-cmac is not some sort of encryption string or something?
09:22 mwk: prettychimp: it's a cryptographic signature, practically undefeatable if implemented correctly
09:23 mwk: even if you know exactly how it works
09:23 prettychimp: mwk: but where does it unlock the hw, maybe in bios instead?
09:24 mwk: prettychimp: the driver unlocks the hw by uploading the signed firmware and hitting the "start" button
09:24 mwk: if the signature matches the firmware, it starts running, and you can use the card... if not, nothing happens, and you can't do much
09:25 prettychimp: aaah ok, thanks for explanation mwk:
09:26 mwk: and it's a *very* solid mechanism
09:26 mwk: it's been present since G98, but it only covered actual video decryption stuff back then... but on Maxwells they extended it to cover all firmwares
09:27 ekaron: even if we get lucky and they write the plaintext key to memory it's fixed in a revision and you're back to square one. Game consoles have done this for a while.
09:27 mwk: yup
09:27 mwk: old story, new location
09:31 prettychimp: ekaron: you mean if you are mistaken with the key it entirely locks and secondary string must be sent, i.e card needs to be sent to nvidia to unlock it?
09:32 mwk: prettychimp: nah, it means if you crack GeForce 5, they will just fix the bug in GeForce 6, and use a new key
09:32 mwk: so you need to start over
09:33 ekaron: no
09:35 ekaron: nothing so trap-like, just that the signatures make it easy for them to break any workarounds we find.
09:37 ekaron: or half the cards wont work or something depending on when they're made, etc.
09:38 mwk: ... and GPUs tend to have more models/year than game consoles
09:38 ekaron: it's taking control away from an owner and withholding info to keep the power
09:39 ekaron: we 'sell' you this product, but it's got secrets from it's owner that may not be in their best interest.
09:39 ekaron: trust us, it's safer.
09:39 ekaron: : {P
09:41 prettychimp: anyways, i bought a card that works very fine with nvidia, just in case, low-end card but it's been running for a while without troubles, i bought ddr3 version of gt730, i still do not know which one it is of them but, but the driver suites for my experiments i intend to do, nouveau driver is a backuplan and very seriosuly taken candidate to
09:41 prettychimp: be the main one for this cards usage
09:42 prettychimp: i'd want bindless and compute support for it, and i do not need anything else, but its not urgent, i read samuel landed compute support for fermi allready
09:44 prettychimp: i mean gl_arb_compute_shader is the thing that has DISPATH_INDIRECT_BUFFER , that would be the last addition that is semi-needed, and for my projects nouveau is number one
09:47 prettychimp: there was maxwell also offered, but i got kepler, cause i new maxwell had trouble working with nouveau, so fairly myself need the nouveau driver to work
09:55 prettychimp: knew i fairly
09:59 imirkin_: skeggsb: gr, another crash in runlist_update... http://hastebin.com/avawavayib.xml
10:09 imirkin_: skeggsb: grrr. just happened a second time. when i launch a parallel piglit on this GK208
10:20 xexaxo: imirkin_: concurrent piglits... heresy :P
10:20 imirkin_: i forgot -1 ... twice, apparently
10:50 l4mRh4X0r: Hey, I responded to bug 90632 (regarding PRIME), and glxinfo actually says it's using my discrete graphics, but when I try to run a GL application, only the background colour gets drawn
11:03 Wolf480pl: l4mRh4X0r, are you using a compositing window manager?
11:13 sjattah: the binary driver for nvidia does not work for f23, so the only option was to use the nouveau driver. I've had bad experience with it in the past (the screen froze). The same problem is still present
11:13 sjattah: 595.180418] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0007180000 [UNSUPPORTED_KIND] from CE2/GR_CE on channel 0x007f36b000 [unknown]
11:14 imirkin_: ajmitch: what kernel / mesa version?
11:14 imirkin_: er, sorry. sjattah --^
11:14 sjattah: kernel 4.2.5, mesa 11.0.3
11:14 sjattah: (git b4bfea0)
11:15 imirkin_: sjattah: any other errors in dmesg before that one?
11:15 l4mRh4X0r: Wolf480pl: Probably, yeah
11:15 sjattah: it's reported to be NVE4
11:15 imirkin_: that's not an error :)
11:16 sjattah: whas is not an error?
11:16 sjattah: that was from glxinfo, of course it's not an error
11:16 imirkin_: are there any errors before the one you pasted?
11:16 sjattah: the last time I got 2 lines:
11:16 sjattah: [ 481.892167] nouveau E[ PFIFO][0000:01:00.0] write fault at 0x0009200000 [PTE] from GR/GPC1/PROP_0 on channel 0x007fa1a000 [Xorg[1201]]
11:16 sjattah: [ 481.892175] nouveau E[ PFIFO][0000:01:00.0] PGRAPH engine fault on channel 2, recovering...
11:17 Wolf480pl: l4mRh4X0r, well, if you weren't using a compositing WM, then it would obviously show blank windows with DRI_PRIME=1
11:17 imirkin_: sjattah: hm. nothing about set_domain failing?
11:17 sjattah: I was actually able to use several programs for a while. I started steam, and was about to change workspace, and then it all froze
11:17 imirkin_: i'm just trying to see if you're getting hit by a specific bug that i fixed... sounds like not though.
11:17 imirkin_: and mesa 11.0.3 includes all the various resource lifetime fixes
11:18 sjattah: no set_domain
11:18 imirkin_: which means... congratulations! you have a bug that i have no idea why it's being caused
11:18 Wolf480pl: l4mRh4X0r, but if you're using a compositing WM, and windows are still blank, then dunno, ask the devs (I'm just a user)
11:18 sjattah: and that means that fixing it will be *very* hard?
11:19 imirkin_: sjattah: i'm told virtualbox can cause problems too -- so can other applications presumably
11:19 imirkin_: are you running anything odd?
11:19 sjattah: not really
11:19 l4mRh4X0r: Wolf480pl: well, glxspheres works with DRI_PRIME=1 ;)
11:20 sjattah: this time, I started with a shell, and glxgears. then I started spotify (that caused a crash earlier in gnome, I've changed to xfce) and used google chrome for a while, and like I sad started steam
11:20 sjattah: and no, nothing else
11:20 imirkin_: sjattah: you could try kernel 4.3... a boatload of stuff got rewritten, perhaps some bug got fixed randomly too
11:22 sjattah: I'm not going to start compiling kernels (that's a thing of the past for me). I guess I'll just use my laptop in the meantime (until the binary driver is fixed)
11:22 sjattah: however, I am willing to check later at some point, since others use the same gpu a sme
11:25 sjattah: if the problem is not in the kernel, then I guess I'll never be able to use nouveau?
11:26 Wolf480pl: isn't 4.3 kernel already released though?
11:26 sjattah: it's not in f23 yet, will probably not be there until atleast 4.3.1 is out
11:27 imirkin_: sjattah: well... the problem is somewhere. i doubt there's a problem that's unique to your configuration
11:27 imirkin_: people have been reporting various errors that i can't account for
11:27 imirkin_: but i need a clean bugreport with a detailed trace in order to do anything about it
11:28 sjattah: in this case, it's not software, so what exactly are you talking about?
11:29 sjattah: is there some program I run in the backgroun when using X?
11:41 imirkin_: sjattah: well, ideally you get an application that's *not* X to cause the problem
11:41 imirkin_: unfortunately in one of your traces, it's X, in the other it appears to be the background ttm bo mover thing
11:42 imirkin_: if you can get an actual application to trigger the issue directly, a valgrind-mmt trace of it along with the message will tell me which buffer is getting screwed, and i can hopefully figure out why by inspection fo the code
11:43 imirkin_: anyways, if you want a working desktop, i suggest removing complexity
11:43 imirkin_: like no gnome-shell, etc
11:43 imirkin_: or boot with nouveau.noaccel=1
11:56 karolherbst: imirkin_: what do you think about the idea to leave the last line out in the pstate file while the gpu is off?
11:57 imirkin_: karolherbst: dislike. i'd rather it say ---- or something
11:57 karolherbst: --: core --- MHz memory --- MHz ?
11:57 imirkin_: AC: ---
11:57 karolherbst: well
11:57 imirkin_: or ...
11:57 imirkin_: AC: powered off
11:58 karolherbst: AC depends on the power source
11:58 karolherbst: it isn't always AC
11:58 karolherbst: but we should know that right
11:58 karolherbst: mhh
12:01 karolherbst: how does that look? https://gist.github.com/karolherbst/7597fa76dd4eabc7bd52
12:01 karolherbst: mhh
12:01 karolherbst: it looks kind of strange though
12:08 karolherbst: imirkin_: the problem is, that the interface still calls nvkm_clk_read and somehow I don't want to move that is on check that much down
12:09 karolherbst: imirkin_: or what it be fine to do that inside nvkm_control_mthd_pstate_attr?
12:10 karolherbst: I would then just return -EAGAIN as the clock and the debugfs can handle that error then
12:13 imirkin_: right
12:22 karolherbst: okay, that sounds much more reasonable, because I plan to remove all those device interactions while the card is off
12:22 karolherbst: currently you get a lot of fun if you write something into pstate while the card is off
12:31 karolherbst: I start again doing hacky things :/
14:10 imirkin_: skeggsb: could there be more chans than expected on that list?
14:14 imirkin_: skeggsb: i wonder if there's some locking missing... dunno. it's weird. but running piglit in parallel triggers it pretty reliably
14:58 airlied: anyone use mmiotrace replay stuff?
14:59 pmoreau: I used it a couple of times, but it wasn't really helpful IIRC
14:59 hakzsam_: never used
15:00 airlied: yeah it only seems to run some of the writes
15:00 airlied: probably have to write my own
15:01 airlied: skeggsb: how do you bisect traces?
15:01 airlied: load it into a C file and run it?
15:02 imirkin: airlied: note that reads can be important in some cases
15:02 imirkin: afaik there are some tools that replay the pre-mmiotrace format
15:41 skeggsb: airlied: manually.. i generally turn them into a shell script (or C, if i want it to execute faster), and #ifdef the crap out of it :P
15:46 airlied:crosses his fingers he hasn't toasted his filesystem
16:18 rardiol: my computer sometimes hangs when I start a game called factorio and I have http://pastebin.com/raw.php?i=daWJ6svt on my logs, does that look a nouveau problem? something to do with https://bugs.freedesktop.org/show_bug.cgi?id=59069 ?
16:21 imirkin: rardiol: fail ttm_validate points to not having enough vram... nouveau doesn't handle this case well.
16:21 rardiol: imirkin: I think that explains it. thanks
20:56 airlied: gnurou: ping, can you ack the patch on dri-devel for fixing builds on some arches
20:58 gnurou: airlied: oops, haven't seen you guys had a fix and wrote my own...
20:58 airlied: gnurou: oh I'll take that if it's good :)
20:59 gnurou: ah it's on dri-devel... that's why
21:00 gnurou: airlied: I'm really not sure which solution is best - I simply casted the DMA handle to a physical address since that's what dma_to_phys() does anyway
21:00 airlied: yeah I mostly think to ignore it on non-ARM/arm64
21:00 gnurou: on the other hand this code should never been used on something other than ARM, so your fix should be good too
21:01 airlied: it's unlikey that code will ever run on that
21:01 gnurou: but! actually dma_to_phys() should never be called outside of arch/ (as we have been told), so I think I will send my fix anyway
21:02 airlied: yeah send yours and I'll look
21:02 gnurou: otherwise the dma API people will rap my knuckles again :P
21:11 gnurou: airlied: sent - and apologies for the trouble
21:21 gnurou: airlied: ah sorry, forgot to add a drm/nouveau/ prefix to the subject title >_<
23:18 imirkin: skeggsb: ping
23:25 skeggsb: imirkin: hey
23:29 imirkin: skeggsb: any idea on that runlist overrun?
23:29 imirkin: skeggsb: there's too much indirection in the code, and i don't even know what it's attempting to do in the first place, so i couldn't really make sense of it
23:35 skeggsb: i don't know how that could possibly happen tbh
23:35 skeggsb: i'll see if i can reproduce myself tomorrow and track it down though
23:35 imirkin: skeggsb: it happens quite reliably on that GK208 with 8 piglit threads
23:36 skeggsb: what about other boards? or is it just that one?
23:36 imirkin: skeggsb: it's a secondary GPU, piglits executing over DRI3, in case it helps
23:36 imirkin: skeggsb: i've only done it by accident on that comp. i def know that parallel piglit = pile o fail, but normally not that quickly
23:37 skeggsb: i've only got the original nv50 plugged into the test box i can access from here, which is asking for even more trouble :P
23:37 imirkin: G80 does ok with piglit actually
23:38 gnurou: skeggsb: pingidyping on the secure boot series? :)
23:38 skeggsb: gnurou: getting there, slowly, sorry :)
23:38 imirkin: skeggsb: you need to clone() yourself
23:38 skeggsb: gnurou: it'd help if i was able to test on dGPUs too ;)
23:39 gnurou: skeggsb: that will be as soon as I manage a get usable firmware binaries myself :/
23:39 gnurou:should not vent his frustration here
23:39 imirkin: gnurou: where else? :)
23:39 skeggsb: gnurou: i'm pretty sure we're all at that point anyway :P
23:40 aaronp: gnurou, I'm frustrated just reading your emails about it.
23:41 skeggsb: gnurou: in any case, i'm just jesting, i fully intend on getting the review done regardless
23:42 imirkin: ... but having it work on dGPUs *would* light more of a fire to get it done...
23:42 skeggsb: haha ;)
23:43 gnurou: aaronp: ah damn, you're here! :P
23:44 imirkin: skeggsb: fwiw that crash is in gk104_fifo_*, and the GK208 is the only board i use that'd hit that. (i guess i also have a GK20A, but i've yet to get into the habit of powering it on...)
23:59 gnurou: skeggsb: I am also wondering what was your general stance regarding the drf macros - if you are not against them I'll like to push them in so we can start using them in the code