00:00 imirkin: yay!
00:00 imirkin: unless it's actually a rebranded GF108
00:00 skeggsb: hopefully not, since nvidia sent it :P
00:00 imirkin: (didn't you go through like 3 laptops before you got the GK106 you needed?)
00:00 skeggsb: yeah, can't remember what board it was, but, that happened
00:00 skeggsb: i figure nvidia *should* know better :P
00:01 skeggsb: (than another vendor)
00:03 skeggsb: oh. wow.
00:03 skeggsb: first nv board (that's not a laptop) i've seen with mini-dp
00:03 skeggsb: wonder if dcb will say that now, unlike every laptop i've seen
00:03 imirkin: single-slot?
00:03 milesrout: hey sorry I said I'd take a look at some stuff for video encoding a while ago, but I have been super busy. I am still planning to look at it.
00:03 skeggsb: yeah
00:07 imirkin: probably conserving space
00:07 skeggsb: yeah, amd have been doing it for ages, just haven't encountered it on nv yet
00:07 imirkin: i almost picked up a quadro 2000 - but it ended up being about 2x as expensive as i wanted... 2x DP + DVI. that's all that fits.
00:24 whompy: skeggsb: just curious, do you have your mmu work posted anywhere or is it still on a private wip branch somewhere?
00:25 skeggsb: it's not posted anywhere as of yet, definitely not in a respectable shape :P
00:26 whompy: Tis what I figured.:)
00:28 skeggsb: i've been slowly rebasing (it's from pre-pascal times)/getting it into shape over the last couple of months whenever i need a break from other work
00:32 whompy: I'm sure that'll be fun to dive back into after a nice vacation.;)
00:32 skeggsb: it would be.. but mesa comes first :P
00:33 whompy: Haha. Does the mmu stuff end up in being kernel/libdrm/mesa heavy? Something I was curious about.
00:35 skeggsb: it's all kernel work. mesa could take advantage of a few improvements too, but, that's beyond the current scope :P vulkan will use it
00:36 skeggsb: (actually, it kinda *has* to, to support some of vulkan's memory model)
00:37 whompy: Gotcha. Have you played with vulkan much yet or still on the prep work side?
06:21 hanetzer: heyo. Quickish question, when you guys reversed nvidia's stuff, did you actually reverse the kernel modules themselves or what? Basically, I have a shitty situation in that a SoC I'm programming for has 29 binary kernel modules for 3.10, which sucks obviously.
06:21 airlied: that's a lot of kernel modules for one SoC, nuts
06:22 hanetzer: yeah, and its all a/v h264 craziness.
06:22 airlied: hanetzer: mostly either REing the bios, kernel module or userspace binary pieces
06:23 airlied: hanetzer: mmiotrace was the most used tool I think for kernel stuff
06:23 hanetzer:really hates his life right now :/
06:24 airlied: hanetzer: that's one of those pick a different SoC situations
06:24 airlied: what SoC is it?
06:24 hanetzer: hisilicon hi3521a
06:25 hanetzer: it and its family are pretty much the core of most consumer security devices
06:33 hanetzer: airlied: have a bit of a fantasy of making competing products, but quite literally there is no way I'll get that done. one, I don't know EE very much, the SoC I'm interested in I can't find where I'd even buy the chips at, and I seriously lack capital :/
06:54 gnarface: hanetzer: how about Texas Instruments?
06:56 hanetzer: gnarface: do they have socs that can handle mutimedia codecs and aren't absolutely retarded?
06:57 gnarface: hanetzer: i don't know, it's above my level of expertise, but on the note of good linux support... near a decade later, the guts of this little thing have impressed me greatly: https://en.wikipedia.org/wiki/GP2X_Wiz
06:58 gnarface: hanetzer: i think TI makes good stuff still, but they don't market it for shit
06:58 gnarface: hanetzer: sure, i get that nvidia tegra stuff is really slick, but man... linux support from Nvidia is always gonna be an uphill battle against an entrenched enemy
06:59 hanetzer: oh, I don't want to deal with nvidia, ever.
06:59 hanetzer: I both admire and pity you guys.
06:59 gnarface:can't take any credit for nouveau
07:02 hanetzer: I wouldn't even care too much about these blobs if their damned hardware was adequately documented.
07:03 gnarface: yea, i think the deal is with TI you get the documentation, you get the support, you get the specs, and they don't care if you're competing against windows, but they WILL require you fork over that ~250$ dev kit licensing fee before they give you anything at all
07:04 gnarface: (this is all purely hearsay though)
07:06 gnarface: but what i can do on this Wiz with it's ancient and relatively low-clocked core using only the customized (GPL-violating) linux OS it came with blows the doors off more recent and supposedly much higher-specced gear (like raspberry pi)
07:06 gnarface: like, shamefully so, comparing things like MAME builds, or emulators
07:06 hanetzer: its truely a pity that half of this soc is closed source and undocumented. its actually fairly nice featurewise
07:13 pq: koz_, yeah, I play Minecraft on Nouveau with G96, was it... one of the NV50 family. After some tweaks I can get roughly 30 fps in a 1200x800 window or so, with standard textures. Second to highest re-clocked perf level.
07:41 koz_: pq: I have a GK104 (GeForce GTX680), and I cap out at about 30 frames as well. 1080p, max settings, max draw distance, 512 textures.
07:42 koz_: THis is on 0f.
07:42 koz_: I haven't tried it with boost frequencies yet.
07:45 pq: koz_, my GPU is approaching 10 years old, I think, in a laptop
07:45 pq: I'm actually amazed it's completely playable
07:45 gnarface: doesn't minecraft still use Java? how can the GPU be a bottleneck?
07:46 gnarface: pretty sure frames are drawn with software blitting
07:47 gnarface: you'd probably get the same framerate out of a PCI card
07:47 gnarface: well, s3virge dx can't do 1080p though
07:47 gnarface: but still...
07:49 airlied: minecraft uses opengl
07:50 gnarface: is that new since 2015?
07:52 airlied:thinks is has done that for a very long time, not sure when though
07:52 pq: gnarface, it's java, it uses OpenGL, my two CPU cores are not actually maxed out during steady-state rendering, i.e. while not loading new world chunks.
07:53 gnarface: ah, indeed
07:53 gnarface: i'm surprised
07:53 gnarface:wonders what the Wii-U port uses
07:54 pq: maybe my GPU is just that slow so that the slow CPU is not exhausted there :-P
07:54 pq: or maybe my "measurements" are not accurate - I don't care, 30 fps is playable :-)
08:16 koz_: gnarface: Mine*test*, not craft.
08:17 koz_: Minetest is written in C++ (or rather, it runs a C++ engine scripted via Lua).
08:17 koz_: pq: I clearly should ahve read more carefully.
08:18 gnarface: koz_: ah! good to know
08:19 koz_: gnarface: It's pretty cool actually, but I'm getting weird performance issues with it relative the blob driver. Once I have some hard figures, I'll let the nice nouveau devs know.
08:21 karolherbst: minecraft uses OpenGL since always afaik
08:35 koz_: This might seem like a stupid question, but what would be required to get OpenCL firing on NVIDIA cards using non-blob drivers?
08:37 pq: koz_, oh, I assumes minetest was a minecraft benchmark program or something. Ok.
08:38 koz_: pq: Nope, actual game: http://www.minetest.net/#
08:40 pq: nice
08:42 pq: should definitely remember to try that some day
08:53 pmoreau: koz_: Someway to process what the OpenCL compiler generates. There are some other stuff needed as well, but that is the biggest one by far.
08:53 pmoreau: s/Someway/Some way
08:55 pmoreau: koz_: I have some WIP for that which can run some simple OpenCL kernels, but there is still a lot of OpenCL functions left to support.
09:06 koz_: pmoreau: I see. Are you the only person on this at the moment?
09:07 pmoreau: I am. There have been some other people interested in helping, but they either decided not to or haven’t had time to.
09:11 pmoreau: koz_: If you want to try it, grab the branch `clover_binary` on https://phabricator.pmoreau.org/diffusion/MESA/mesa.git. This page has some information on how to setup things, though it is a bit old: https://phabricator.pmoreau.org/w/mesa/testing_opencl_through_spirv/
09:13 pmoreau: koz_: And if you want to compile from source, you will need to apply this old patch https://phabricator.pmoreau.org/rMESA2bfc0bea5b51142e3f0e500d3a3c62de88aea5af which won’t apply cleanly on the latest version…
09:13 pmoreau: koz_: As long as you use supported stuff, it should work from Tesla to Maxwell.
09:26 koz_: pmoreau: Thanks - I will keep that in mind.
15:19 imirkin: skeggsb: looks like mesa is gaining some ARB_sparse_buffer support... would be good to account for that in your updated uapi for vulkan stuff.
16:54 ccaione: hey guys, any hint how to enable backlight control for Pascal / GP100? Using the same as done for Maxwell seems to no work fine
16:55 imirkin_: gyah, they're still wiring backlights to not-acpi?
16:56 ccaione: imirkin_: yup
16:56 imirkin_: =[
16:56 imirkin_: iirc it was a trivial hookup
16:56 imirkin_: have you tried that and it didn't work? or just doesn't work out-of-the-box?
16:56 ccaione: imirkin_: I tried to hookup pascal in drivers/gpu/drm/nouveau/nouveau_backlight.c but it didn't work
16:57 imirkin_: if it didn't work, the registers must have moved
16:57 imirkin_:checks how it works...
16:57 ccaione: yeah, that's why I'm asking in case you have more info
16:57 ccaione: I tried to add a new `case NV_DEVICE_INFO_V0_PASCAL` and such, but no luck
16:58 imirkin_: right
16:58 imirkin_: give me a minute.
16:58 ccaione: thx
16:58 imirkin_: i don't think it's in the info nvidia's released
16:58 ccaione: damn
16:59 ccaione: so, no NV50_PDISP_SOR_PWM_CTL description for pascal?
16:59 imirkin_: checking, but doubtful
16:59 imirkin_: oh, but ....
17:00 ccaione: funny thing, also the proprietary drivers do no work fine
17:05 imirkin_: hmmm... based on some cursory looking in nvkm, it looks like the SOR control remains where it was
17:05 imirkin_: which means that perhaps the backlight isn't hooked up the way you think
17:05 imirkin_: or the method of control has changed more drastically
17:06 karolherbst: imirkin: feel free to merge the postraloadpropagation patches. I didn't find any regressions with a piglit run. I would be feel better though if somebody would check the instruction layouts more carefully. thanks
17:06 ccaione: for sure it's not in the ACPI since the _BCM method is empty
17:06 imirkin_: karolherbst: cool thanks.
17:06 jamm: imirkin: it seems that other than nouveau_dri_*.so, my gnome login screen also also depends on some other *_dri.so, else i'm getting a weird white screen with an error message and a logout button in the center
17:07 imirkin_: jamm: probably requires 3d accel
17:07 jamm: also, i had to set LIBGL_DRIVERS_PATH to get nouveau to load the dri from my install folder
17:07 jamm: in /etc/environment
17:07 ccaione: imirkin_: where it was == like it was done in maxwell ?
17:08 imirkin_: ccaione: not sure i get the question
17:08 imirkin_: jamm: LIBGL_DRIVERS_PATH is definitely not something you ever want to set unless you *really* know what you're doing
17:10 ccaione: imirkin_: AFAICT in maxwell & co the backlight was controlled acting on NV50_PDISP_SOR_PWM_CTL right?
17:10 imirkin_: ccaione: yeah. i don't see any indication that PDISP_SOR_* has moved on pascal
17:11 whompy: jamm: I've had similar gdm issues. How'd you go about fixing it?
17:11 jamm: imirkin_: okay, so LD_LIBRARY_PATH then?
17:11 jamm: whompy: not fully fixed yet, but i think i'm close, will share it here once i fix it
17:11 ccaione: uhm, odd it's not working fine then
17:11 imirkin_: jamm: yes, definitely.
17:12 jamm: thanks! i'll set that one instead
17:12 imirkin_: jamm: if you want it system-wide
17:12 imirkin_: you can just add it to /etc/ld.so.conf(.d) and run 'ldconfig'
17:13 ccaione: imirkin_: out of curiosity, where did you get the info for pascal?
17:13 jamm: imirkin_: ah, something new to me, thanks!
17:13 imirkin_: ccaione: i looked at nvkm/engine/disp/gp102.c
17:14 imirkin_: and saw that it's calling the nv50_sor_* functions
17:14 imirkin_: [or rather, pointing at those functions]
17:15 ccaione: yeah, makes sense
17:15 imirkin_: assuming that tmds works with pascal (dvi + hdmi). i kinda assume they do, skeggsb tends to be pretty thorough with this stuff.
17:15 ccaione: I was hoping in something more datasheet-like
17:16 imirkin_: just break into nvidia hq for those.
17:16 ccaione: lol
17:16 ccaione: while we are at it, do you know the difference between nv50_bl_ops and nva3_bl_ops in drivers/gpu/drm/nouveau/nouveau_backlight.c ?
17:16 imirkin_: ...
17:17 imirkin_: RTFS?
17:17 imirkin_: the disp stuff changed in GT215
17:17 ccaione: hahah, yeah, it is just a different way to read into NV50_PDISP_SOR_PWM_CTL
17:17 imirkin_: so yeah - could be that something like that changed in pascal
17:17 ccaione: that's my idea also. Tried both but still nothing
17:17 imirkin_: having a working blob driver to trace is pretty important to figuring that out
17:18 imirkin_: you might be interested in nvapeek/nvapoke
17:18 ccaione: well, I don't have it either yay
17:18 imirkin_: which will let you just write random values into those regs
17:18 imirkin_: and see if your display reacts
17:18 ccaione: hoooooo
17:18 ccaione: that's great
17:18 imirkin_: (part of envytools)
17:19 ccaione: useful, thx
17:19 imirkin_: i might recommend having a second computer on hand in case you succeed in turning the screen off :)
17:19 ccaione: well, hoping the HDMI works then
17:25 imirkin_: be careful which SOR you do this on :)
17:26 ccaione: well, in my case `or == 1`
17:26 imirkin_: well, HDMI will be another oen
17:26 imirkin_: could be that backlight is always wired to or == 0
17:26 ccaione: interesting
17:26 ccaione: I guess I'm going to fry this GPU :D
17:27 karolherbst: imirkin_: do you also want to look over the first patch of my other series or should I dig a bit deeper and remove the obsolte code, so that you see what was going on
17:27 imirkin_: karolherbst: sorry, i don't have time to look at it now
17:30 karolherbst: okay, then I will dig into it
17:44 jamm: imirkin: got some interesting findings
17:44 jamm: without your patch, getting "AIGLX: Screen 0 is not DRI2 capable"
17:45 jamm: with your patch, get that usual calling entrypoint failed thing
17:45 jamm: also: https://hastebin.com/urepegater.sql
17:45 imirkin_: without my patch you're not using the nouveau ddx
17:45 imirkin_: nvc0_screen_create:935 - Error allocating PGRAPH context for 3D: -22
17:45 imirkin_: ok that's bad
17:45 imirkin_: that means that you either don't have the firmware, or you don't have a recent enough mesa
17:46 imirkin_: oh, that's your system mesa
17:46 jamm: hmm, i cloned the one mentioned in the installNouveau article, seems to be the master branch
17:46 jamm: ah
17:46 jamm: are you talking about the libglx.so?
17:46 imirkin_: nouveau_dri.so
17:46 imirkin_: libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
17:47 jamm: woah, i did set the ld.conf.so.d/nouveau.conf and ran ldconfig
17:47 imirkin_: might be some sort of update-the-thing, dunno
17:47 jamm: it still seems to stick to the existing mesa installation i've had
17:47 imirkin_: i never opt for that option
17:48 imirkin_: or perhaps you added the dir below /usr/lib/x86_64-linux-gnu
17:48 imirkin_: instead of above
17:48 jamm: there's separate conf files in ld.conf.so.d and ld.conf seems to include them using a wildcard
17:48 imirkin_: right
17:48 imirkin_: so do 00-nouveau.conf
17:49 jamm: oh, yeah makes sense :d
17:49 imirkin_: so that the wildcard processes that file first
17:50 jamm: but, but, check this out, there's a x86_64-linux-gnu.conf in there which contains /usr/lib/x86_64-linux-gnu
17:50 imirkin_: and n comes before x?
17:50 jamm: shouldn't nouveau.conf come before this file? (assuming it's sorted lexicographically)
17:50 jamm: yeah, my naive mind tells me
17:51 imirkin_: jamm: /sbin/ldconfig -p | grep libGL
17:52 imirkin_: does that point at your lib dir?
17:52 jamm: imirkin_: system one
17:52 imirkin_: hence the problem
17:52 imirkin_: cat that nouveau.conf file for me?
17:52 imirkin_: [want to make sure you didn't accidentally do something silly]
17:52 jamm: sure! i don't mind at all
17:52 jamm: # nouveau default configuration
17:53 jamm: /home/jam/install/lib/dri/
17:53 imirkin_: ah yeah
17:53 jamm: only these two lines
17:53 imirkin_: you want the lib dir
17:53 imirkin_: not the dri dir
17:53 jamm: ah right
17:53 imirkin_: the dri dir doesn't actually contains libs ;)
17:53 jamm: makes sense
17:53 imirkin_: [not ones that ld.so knows what to do with, anyways]
17:54 jamm: it is then
17:54 jamm: /home/jam/install/lib/ *
17:54 jamm: (without the *)
17:54 imirkin_: yes.
17:54 jamm: i'll brb
17:56 karolherbst: imirkin_: I think this was all regarding the special limm form inside target_nvc0: https://github.com/karolherbst/mesa/commit/a8494bea83f8be0c471c21c0ffc71c0f51dab737.patch it
17:56 karolherbst: ...
17:56 karolherbst: it's obviously wrong, you can check it out whenever you have time
17:56 imirkin_: karolherbst: will do.
17:57 imirkin_: jamm: not sure what the deal with the multiple folders is there
17:57 imirkin_: jamm: but since yours is first, i suspect it's fine
17:58 imirkin_: jamm: ldd /usr/bin/glxinfo | grep libGL
17:58 jamm: libGLEW.so.2.0 => /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 (0x00007f23b5319000)
17:58 jamm: libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f23b50aa000)
17:58 jamm: libGL.so.1 => /home/jam/install/lib/libGL.so.1 (0x00007f23b4e40000)
17:58 imirkin_: yay =]
17:59 jamm: libGL: Using DRI2 for screen 0
17:59 jamm: looks good!
17:59 jamm: but, still aiglx entrypoint
17:59 imirkin_: boooo
17:59 imirkin_: when you built nouveau_drv.so, did you use a --prefix=/home/jam/install ?
17:59 imirkin_: oh wait...
18:00 imirkin_: it's stupid Xorg which has to be built with that
18:00 imirkin_: hold on
18:00 jamm: yeah, i set it to an env which was set to that folder
18:00 imirkin_: where's your other nouveau_dri.so?
18:00 imirkin_: (the system one)
18:00 jamm: i mean, i followed the tutorial here https://nouveau.freedesktop.org/wiki/InstallNouveau/
18:00 jamm: the system one is /usr/lib/x86_64-linux-gnu/dri/
18:00 jamm: within that folder
18:01 imirkin_: ok. try moving that directory out of the way, temporarily, and pointing it at your /home/jam/install/lib/dri one
18:01 imirkin_: i.e. add a symlink
18:01 jamm: alright
18:01 jamm: brb
18:02 imirkin_: airlied: how woudl you feel about making the dri dir configurable in xorg.conf?
18:02 imirkin_: airlied: iirc it's set at compile-time now =/
18:03 jamm: imirkin: that did the trick! yay! thanks a lot, i really learnt a ton in the past 20 minutes itself XD
18:03 jamm: [ 13.702] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
18:03 jamm: and many more
18:03 imirkin_: cool
18:04 jamm: so i can confirm your patch works
18:04 jamm: other than pmoreau
18:04 imirkin_: so yeah, the thing is that iirc libglx.so, or one of the other "system" modules, has a hard-coded path for where it tries to dlopen() the ${DRI2_DRIVER_NAME}_dri.so lib to check some silly things on it
18:05 jamm: ah, i suspected so.. it didn't seem to use the library path at all
18:05 jamm: well, symlink works fine for me
18:05 imirkin_: i thought it was hard-coded in nouveau_drv.so, but it's not.
18:05 jamm: i did this dual-boot just for nouveau development anyways ^^
18:06 imirkin_: =]
18:06 jamm: tomorrow i'll look into maxas and recap on what we discussed on the gpu scheduling stuff you mentioned
18:07 jamm: cheers! it's like 3am here, gotta sleep before insomnia hits
18:07 jamm: night!
18:07 imirkin_: see ya
18:33 airlied: imirkin_: which dri dir the one it finds the modules in?
18:33 imirkin_: airlied: yea
18:34 airlied: I suppose if you want X servers to load different modules it could come in handy
18:34 imirkin_: normally it doesn't matter coz it doesn't use those modules for any serious purposes
18:34 imirkin_: but when you're doing stuff like hw bringup, or when one of those few things has issues (like the visuals stuff on BE machines for a while)
18:34 imirkin_: it can be helpful to have it point to a diff place
19:12 nyef: So, I was just doing a brain-dump of stuff tangentially related to cryptographically signed (but not actually encrypted) code, and a thought occurred to me with respect to fuzzing signed inputs to signed PMU firmware: Can we run the signed firmware in a simulator to see what it does, and would that be useful?
19:13 imirkin_: sure
19:13 imirkin_: we can also just read it
19:20 nyef: So, plausibly useful to determine dynamic behavior, but otherwise not really. Okay then.
20:49 RSpliet: nyef: if you're game for building a falcon simulation model go for it... NVIDIA is slowly migrating to RISC-V in the meanwhile
21:38 nyef: RSpliet: I don't know if I'm game or not at this point. I'd probably learn a lot in the doing, at least, but I don't really know how useful it would be.
21:39 nyef: And I have a pile of other things that I could be working on as well, so there's opportunity cost involved.
21:52 imirkin_: skeggsb: any luck with the GP107?
21:53 skeggsb: imirkin_: i've "finished", but also realised i might have subtly screwed up gr init on all pascal boards.. re-confirming (and fixing, if necessary) that this morning and i'll push the patch
21:53 skeggsb: *however*
21:53 skeggsb: gr won't work, the hw won't accept the fw
21:54 imirkin_: bbbut... whaaaa :(
21:54 skeggsb: gnurou is looking into it, seems like the wrong fw and/or signatures were provided
21:55 imirkin_: skeggsb: i assume you're aware of the use-after-free situation in 4.10 btw?
21:55 imirkin_: a few people have reported funny issues
21:55 skeggsb: i've seen the bugs go by, but haven't looked at it yet
21:55 skeggsb:doesn't see it, of course
21:56 imirkin_: i haven't hit it either - only the runpm thing.
22:18 karolherbst: RSpliet: is there anything hindering nvidia to use the falcons for this as well and just port to the RISC-V ISA?
23:08 imirkin_: skeggsb: btw, dunno if you saw the scrollback above, but looks like backlight isn't working quite right on pascal. dunno if you happen to have magical infos about that.
23:11 skeggsb: based on what i read, and that nvidia don't manage it either, i'd bet on it not being wired to the gpu
23:11 skeggsb: (ie. blame acpi)
23:11 imirkin_: the acpi method was also empty
23:12 skeggsb: heh
23:12 skeggsb: but, to more directly answer your question, i don't have any magical info that might help
23:12 imirkin_: :)
23:12 imirkin_: but plenty that won't! :)
23:13 skeggsb: i wish :P
23:14 imirkin_: skeggsb: btw, does your userspace-nouveau thing work well with multi-gpu setups? i'm thinking of using it to help debug the G92 BSP thing
23:14 skeggsb: yeah, should be fine
23:15 imirkin_: so i'd detach that one from nouveau
23:15 imirkin_: and then somehow tell it to only use the G92 one?
23:15 skeggsb: hmm, let me check if that's possible.. nvkm will probably bind to them all
23:15 imirkin_: i kinda have 4 in my box :)
23:16 imirkin_: one of which drives the display
23:17 skeggsb: oh, no, it'll *probably* be fine.. unless you create a device object for a GPU, nvkm will only read regs to identify it
23:17 skeggsb: i think
23:17 skeggsb: maybe
23:17 skeggsb: ;)
23:17 imirkin_: ok. i'll read some code.
23:18 skeggsb: unless there's a bug, that's what should happen
23:19 imirkin_: also ... if it's easy, sample code to create a channel/fifo/etc that will work on a G92 would be much appreciated. or a pointer at code i can copy.
23:19 skeggsb: do you just want to create it, or be able to use it too?
23:19 skeggsb: if it's the former, something like the mpeg example i pasted is what you need
23:19 imirkin_: submitting fifo commands would be ideal
23:20 skeggsb: yeah that's slightly more challenging :P
23:20 imirkin_: hm ok. well i'll figure it out then
23:20 imirkin_: if libdrm can do it, i can too
23:20 skeggsb: using nvif directly is a bit harder than libdrm :P
23:20 imirkin_: as if that's a thing :p
23:21 imirkin_: [being harder than libdrm]
23:21 skeggsb: haha
23:21 skeggsb: well, it's more explicit and verbose than libdrm.. and missing some rather important interfaces still
23:21 skeggsb: like, you know, allocating memory
23:21 skeggsb: but who wants to do that!
23:21 imirkin_: yeah, i'm not going to allocate memory
23:21 imirkin_: i'm just oging to use it :)
23:22 imirkin_: (ugh, probably have to figure out the stupid dmaobj interface too...)
23:22 skeggsb: if you want to use the channel, you have to :P
23:22 imirkin_: [and hope the memory's there]
23:22 skeggsb: oh, hmm, you might be able to get away with that prior to fermi actuallt
23:23 imirkin_: he he he
23:23 imirkin_: well wtvr. i'll play with it. should be a good learning experience
23:23 imirkin_: [on what not to do]