00:02 imirkin: gnurou: thanks again for all your help btw :)
00:04 imirkin: wow. *and* it powers off when i did "halt". amazing.
00:07 gnurou: see, when we tell you this ARM board is one of the best supported upstream ;)
00:08 gnurou: log looks ok, but Nouveau failed to probe interestingly
00:08 gnurou: [ 9.009901] nouveau E[ PFIFO][57000000.gpu] unsupported engines 0x00000030
00:08 gnurou: [ 9.081112] nouveau E[ DRM] failed to create ce channel, -22
00:08 gnurou: [ 9.169737] nouveau E[ PFIFO][57000000.gpu] unsupported engines 0x00000001
00:08 gnurou: [ 9.237512] nouveau E[ DRM] failed to create kernel channel, -22
00:08 gnurou: the first error is expected, but not the second
00:08 gnurou: ah of course
00:09 gnurou: that's because you have no firmware
00:09 imirkin: :)
00:09 gnurou: if you plan to play with Nouveau, make sure you are using my tree though, or at least the one in the tegra-nouveau-rootfs git project
00:09 imirkin: hmmm... darktama's isn't good enough?
00:10 imirkin: i was going to get it to just load the nouveau firmware, see if it works
00:11 imirkin: (i don't really see why it wouldn't, but... who knows)
00:11 gnurou: I *think* darktama's has all the required patches, but just to be safe
00:11 gnurou: ah and my repo has two patches that load the firmware from the weird format we published it so far
00:11 imirkin: that archive thing?
00:11 gnurou: last, you will probably need to use my kernel tree as well
00:11 gnurou: yeah, I think we won't use it in the end
00:12 gnurou: but for now they are published this way
00:12 imirkin: what's in your kernel tree?
00:12 gnurou: errr lemme check...
00:12 imirkin: [that i would need to play with nouveau]
00:13 imirkin: thing is i'm already using the qcom kernel tree... obviously no law that says i can't use 2 trees, but i was hoping a single kernel would cover all the devices
00:13 gnurou: DT nodes to enable the GPU (oh - so how come your kernel probed it?)
00:13 imirkin: nouveau got auto-loaded no less
00:13 gnurou: a fix for 64-bit TTM (so not a problem on TK1)
00:14 gnurou: two patches that make 3.19 compatible with some of the latest Nouveau changes
00:14 imirkin: ooh, i'll want those... the qcom tree is still based on 3.19 for now
00:14 imirkin: where can i find them?
00:14 gnurou: right
00:15 gnurou: https://github.com/Gnurou/linux/commits/drm
00:15 gnurou: take everything that is above 3.19 to be safe
00:15 imirkin: excellent, thanks!
00:15 gnurou: that's funny though
00:16 gnurou: then you can compile darktama's repo (or mine) and have the module loaded
00:16 gnurou: don't forget to get the firmware file from https://github.com/Gnurou/linux-firmware/
00:17 imirkin: hmm... i guess i should just play the game and make sure that it works with your fw before hacking on that ;)
00:17 gnurou: that's what I would suggest, yes :)
00:18 gnurou: then apply https://github.com/Gnurou/nouveau/commit/b5f14aa756a6bd6634d22d8a430a5fb592e88cf8 and https://github.com/Gnurou/nouveau/commit/abfab9dd96f45c860c4bf95261ac584a4b6d318f on top of darktama's tree, and I believe you should be set
00:19 imirkin: why not just extract the fw from your archive?
00:19 gnurou: you can do that as well if you prefer
00:19 gnurou: at the end of the day that's probably the solution I will submit to linux-firmware
00:19 imirkin: seems easier... esp since step 2 will be "try to use nouveau fw instead"
00:20 gnurou: nice! if you can get a replacement fw then I won't have to submit ours :)
00:20 imirkin: i can't think of a reason it wouldn't Just Work with the gk208 firmware
00:20 gnurou: I think we tried and it did not
00:20 gnurou: IIRC
00:21 imirkin: iirc you tried the gk104 firmware, which was of course a mega-fail
00:21 gnurou: maybe we should try gk104/gk107 instead
00:21 gnurou: oh right
00:21 imirkin: since you were insisting that it was similar to a gk104
00:21 gnurou: GR is gk2, not gk1
00:21 imirkin: even though in every respect it's actually similar to gk110/gk208 rather than gk104
00:22 gnurou: yeah well it's a weird beast :P
00:22 gnurou: (not too weird obviously since Nouveau brilliantly supports it)
00:22 imirkin: anyways... iirc you needed the fuc5 stuff
00:22 imirkin: although you *might* need the gk104 logic. we'll see.
00:23 gnurou: ah, when you will want to test it, be also aware that user-space also requires a few changes
00:23 imirkin: anyways, it's past my bedtime... ttyl
00:24 gnurou: see the repos in tegra-nouveau-rootfs for the patches to apply
00:24 imirkin: i plan on using X :)
00:24 imirkin: and/or gbm
00:24 gnurou: may I suggest kmscube as a first test ;)
00:24 imirkin: well, remember -- i won't actually have a visual plugged in
00:25 imirkin: this is just for piglit & co
00:25 gnurou: ah, right
00:25 gnurou: we never tried X, all we know is that it won't use Nouveau as-is
00:26 gnurou: the display being handled by tegradrm and not Nouveau, getting acceleration working might be a challenge if that's what you are aiming at
00:26 imirkin: yeah, a modest amount of hacking may be required
00:26 gnurou: anyway, glad you got Jetson to boot! good night and let me know if you have further issues
00:26 imirkin: meh... same as intel + nouveau
00:26 gnurou: roughly yeah
00:26 imirkin: except intel has its own accel which can be used for 2d
00:27 imirkin: but it may also be possible to run X on a screenless nouveau directly... since i don't actually care about screens... :)
00:27 imirkin: anyways... nite!
00:28 gnurou: 'night!
00:34 mlankhorst: nite
00:52 pmoreau: Yeah! Finally managed to figure out how the EVO commands were represented in demmt format!
00:52 pmoreau: joi: Thanks for the help!
07:18 Svenska: Hi. Please excuse if this is way too off-topic here, but I believe this is a good place to ask. I am thinking of writing a video decoder for a special, non-GPU hardware, and would like to know if VDPAU can be used just for video decoding (not displaying), and if there are restrictions on software support.
07:19 mlankhorst: sure why not?
07:20 mlankhorst: GL_NV_vdpau_interop is the fast way to do it, getbits slow way..
07:20 Svenska: It seems that e.g. mplayer does not support decoding with VDPAU unless you also display using VDPAU. The platform I work on only has a non-accelerated framebuffer to display...
07:23 mlankhorst: you still need a x11 server because of the way vdpau works
07:26 buhman: mlankhorst: that's unfortunate
07:27 mlankhorst: but if you want to use nouveau you could work around it :P
07:27 buhman: O.o, is that documented?
07:28 mlankhorst: not really
07:29 buhman: :(
07:30 Svenska: The X11 restriction is something we could live with, but currently it would require the video player to read the decoded frames from memory, and display them in the way it sees fit. Do you know if the applications do that?
07:30 Svenska: I mean, in the worst case, the library could just write to /dev/fb0 (accelerating yuv-rgb on its own), but this seems somewhat stupid to hardcode.
07:30 mlankhorst: the call you want is VdpVideoSurfaceGetBitsYCbCr
07:31 Svenska: Do video players use it? :-)
07:31 mlankhorst: nope
07:32 mlankhorst: they display it directly to the screen
07:32 Svenska: that's bad.
07:33 urjaman: thats actually good for them
07:33 Svenska: if course it is, but since my accelerator is not connected to any display, it's kind of hard to implement
07:41 zogi: Hello!
07:42 zogi: I'm a beginner interested in the Google Summer of Code project about SPIR to codegen conversion.
07:42 zogi: I've taken a look at the source code of codegen and if I read correctly it transforms TGSI to Tesla ISA (NV50 IR).
07:42 zogi: So am I correct in that SPIR should be transformed to TGSI (which is hw-independent), and then it will be transformed to Tesla ISA by codegen?
07:47 Svenska: mlankhorst: Do you know if video players using VA-API support fetching the decoded video from the library and displaying it themselves? Or do you have any idea on how to implement this in a useful way?
07:48 mlankhorst: nope
07:48 mlankhorst: no idea
07:48 Svenska: Do you know who to ask? :-)
07:49 mlankhorst: neither
07:49 Svenska: OK, thanks for your information anyway.
08:46 imirkin: zogi: my idea was to translate SPIR (or the cool new SPIR-V) directly into nv50 ir. this IR is then compiled into all of the (g80+) ISA's that nouveau supports.
08:47 imirkin: zogi: the nice thing about it is that clover already supports passing LLVM IR around, and it'd be only a minor change to get it to generate the SPIR
08:47 imirkin: zogi: the downside is that it doesn't seem like SPIR will be the long-term winner, but rather SPIR-V. however i'm not aware of any tooling at present to compile OpenCL C into SPIR-V
08:47 imirkin: zogi: fwiw i'd started on a converter about a year ago... didn't get too far though. https://github.com/imirkin/mesa/commits/spir
08:48 Svenska: how different is SPIR-V from SPIR ?
08:48 imirkin: Svenska: other than the name, they are entirely unrelated
08:49 imirkin: i mean... they are both formats for conveying programs :) that's where the similarities end
08:49 Svenska: I see. I've started on the SPIR-V specs, but since I've never looked at SPIR, it only tells me that they are different.
08:49 imirkin: SPIR is a literal copy of LLVM IR
08:50 imirkin: with certain things a little more specified (like these are the opcodes that will be used, and these are the annotations that will always be present)
08:51 imirkin: the nice thing about SPIR is that it fits nicely into clover's current tooling
08:51 imirkin: i.e. (a) run llvm, (b) feed llvm output to state tracker
08:52 Svenska: won't this be the same for SPIR-V?
08:52 Svenska: I mean, LLVM got a SPIR-V backend?
08:52 buhman: https://www.khronos.org/spir; speaking of game engines, if gpus can execute arbitrary code, why not do 100% of the game logic on the gpu?
08:52 imirkin: Svenska: well, clover still expects it to be llvm ir... it modifies it in various ways... linking/etc. i think.
08:53 imirkin: buhman: execution model is different
08:53 buhman: 'different'?
08:53 imirkin: gpu's aren't designed to have long-running programs execute on them
08:53 Svenska: vectorized, parallel. not sequential code like common game logic.
08:55 imirkin: uhm. i would imagine that common game logic is the opposite of those 3 things
08:55 imirkin: oh wait. that's what you're saying.
08:55 buhman: heh
08:55 imirkin: misparsed.
08:55 Svenska: sorry :)
08:56 Svenska: I wonder if Vulkan will succeed
08:58 mlankhorst: why not?
08:59 Svenska: no idea. to me, as an outsider, it looks good
08:59 Svenska: now people have to "just" provide drivers and games...
11:21 mlankhorst: ok I definitely get a boot on tegra...
11:21 mlankhorst: argh again forgot a network cable
11:21 imirkin: the one cable i have!
11:31 mlankhorst: oh well I'll have one tomorrow, getting there slowly :p
12:46 imirkin_: RSpliet: where's the rest of the series? :p
12:46 RSpliet: imirkin_: not finished I'd say
12:47 imirkin_: how 'not finished' are we talking about
12:47 imirkin_: (just curious how much progress you've made)
12:47 RSpliet: nothing since this weekend
12:47 RSpliet: full reclocking on my NVA0, nobody stepped up and help me test so far on other NVA0
12:48 RSpliet: no attempts yet to go back in time, lacking those GPUs in my collection
12:48 imirkin_: when mupuf's back he'll probably be able to
12:48 RSpliet: if I have one or two other NVA0s tested I might be able to push it and enable *just* for NVA0
12:48 imirkin_: if you want i can plug it into my G98 over the weekend which boot into the higher level, but has a *mega low* level too
12:49 imirkin_: like... 700mhz vs 100mhz or something
12:49 RSpliet: think my NVA0 has 100MHz too
12:49 RSpliet: but yes please
12:49 RSpliet: is the VBIOS in the repo?
12:49 imirkin_: mmmmmaybe
12:49 imirkin_: it's a nvs 290 or so
12:49 RSpliet: nothing in the repo
12:49 RSpliet: let me update and check again
12:50 imirkin_: oh no, it's a Quadro FX 370 LP
12:50 imirkin_: ... i think :)
12:54 imirkin_: might be ddr2 though. i forget. we'll see.
12:55 RSpliet: that's even more interesting
12:55 imirkin_: definitely *some* of my nv50's are ddr2
12:55 imirkin_: maybe even all
12:55 imirkin_: but they tend not to have perf levels either
12:56 RSpliet: yeah I know
12:56 RSpliet: and the ones with perflvls don't all have memory params either
12:56 imirkin_: iirc xexaxo has a nv96 with a few perf levels
12:56 imirkin_: (laptop ones tended to have more)
12:56 RSpliet: yep
12:57 RSpliet: and are more likely to have DDR2
12:57 imirkin_: but also harder to plug into reator :)
12:58 RSpliet: ... yes
12:58 RSpliet: that's why I have a "very special" bootable HDD that lets me RE stuff
13:07 imirkin_: iirc 100da0 was for gddr3 while ddr2 used 100753 or so
13:07 imirkin_: er, that can't be right
13:07 RSpliet: well, the 3 sounds off
13:07 imirkin_: 100754? dunno
13:07 imirkin_: and it was a single reg, not per-part
13:08 imirkin_: or is there a distinction between ddr3 and gddr3? maybe that was it...
13:08 RSpliet: imirkin_: I'm sure there's differences I haven't seen yet
13:08 RSpliet: not sure if there are DDR3 pre-GT215 cards
13:08 imirkin_: should be in the traces i sent you
13:09 imirkin_: maybe not
13:09 imirkin_: been like a year since i looked at it, getting hazy :)
13:09 RSpliet: same for me
13:11 imirkin_: weren't you *just* looking at it?
13:11 RSpliet: hardly
13:11 imirkin_: [i mean the nv50 reclocking stuff]
13:11 RSpliet: well, NVA0
13:11 imirkin_: not the thing you did last summer
13:11 RSpliet: NVA0 is surprisingly similar to NVA3/5/8
13:11 RSpliet: the clock tree isn't, the memory controller seems to be
13:12 imirkin_: well they added a bunch of engines, so makes sense that the clock setup would be different
13:12 RSpliet: the whole clock region was revamped
13:12 RSpliet: don't think pre-GT215 had these "RPLL" things
13:13 imirkin_: is that already handled by the current code?
13:13 imirkin_: i didn't see any patches in your tree about fixing that stuff up
13:13 RSpliet: what, the clock tree? yes, Ben did all that
13:13 imirkin_: kk
13:14 RSpliet: there's some myseries in the PLL control regs, but... well, it works the way it does
13:14 imirkin_: :)
13:17 RSpliet: I just lost mountains of time with this new job where I actually need to think, I'll waste time on it when it causes actual trouble :p
13:18 imirkin_: hehe
14:09 pmoreau: RSpliet: I'll get you a mmiotrace with reclocking of a G96; it seems I deleted the one I had for some reason... --"
14:10 RSpliet: pmoreau: excellent!
14:11 RSpliet: take your time ;-)
14:11 pmoreau: Well, it should be quick enough. :)
14:11 pmoreau: Any wishes on how I should proceed to have a clean one?
14:11 imirkin_: pmoreau: DDR2 on your board right?
14:11 pmoreau: Nop, GDDR3 iir
14:11 pmoreau: *iirc
14:11 imirkin_: oh cool
14:12 zogi: imirkin: thanks! Another question: does exposing compute support means implementing the get_compute_param for the drivers (besides nvc0)?
14:12 imirkin_: zogi: you would pick one piece of hardware and enable it for that piece of hardware
14:12 pmoreau: imirkin_: Do you have some Mesa patches that need some testing btw?
14:12 imirkin_: you're not expected to make it work for everything
14:12 imirkin_: pmoreau: if you have portal, can you check on the thing that RSpliet was complaining about?
14:12 RSpliet: ah yes
14:13 RSpliet: now in fairness, I have mesa-libGL-10.4.3-1.20150124.fc21.i686
14:13 imirkin_: zogi: actually if you have a kepler chip, i think most of the work in the nvc0 driver is done for supporting (basic) compute on there. fermi's are moderately supported as well i think though
14:13 pmoreau: I don't have it, but I'd like to play it sometimes when I have time.
14:13 pmoreau: The first one I guess?
14:14 imirkin_: RSpliet: can you provide repro steps (like exactly which portal, and what goes wrong, and how you achieve that)
14:14 pmoreau: RSpliet: Did you open a bug for that I could look at?
14:14 RSpliet: portal from steam, just play Eric Anholts timedemo
14:14 RSpliet: it crashes as soon as you zap the first portal
14:14 pmoreau: Ok
14:15 imirkin_: is that portal 1 or 2?
14:15 RSpliet: 1
14:15 zogi: imirkin_: rigth, just trying to get a rough mental image of the task :)
14:16 imirkin_: zogi: well, you can define your own task too -- these are just suggestions
14:16 pmoreau: RSpliet: No need to reclock for it to crash, right? Should I test it on the MCP79 or the G96 - or mmaybe it doesn't matter?
14:17 RSpliet: I don't know which cards this affects
14:17 RSpliet: I just tried NVA0
14:17 imirkin_: zogi: which hardware do you have on-hand?
14:17 RSpliet: so likely it crashes on either
14:17 RSpliet: no need to reclock
14:17 pmoreau: imirkin_, RSpliet: In case I can reproduce it, do I need to produce any special kind of debug info?
14:17 pmoreau: Ok
14:18 imirkin_: pmoreau: backtrace would be hugely helpful to me
14:18 imirkin_: and/or an apitrace so that i can repro locally
14:18 pmoreau: Most likely an X backtrace than a kernel one?
14:18 imirkin_: i assumed it was just portal that crashed
14:19 RSpliet: yep
14:19 imirkin_: so the backtrace that wine spits out
14:19 RSpliet: there is no wine
14:19 imirkin_: btw nva0 supports ARB_tf2 while nv96 doesn't -- might be the difference
14:20 RSpliet: does NVA3 support that too?
14:20 imirkin_: pmoreau: but you also have a nvac which also has ARB_tf2 -- that card's more similar to the NVA0 in terms of features
14:20 imirkin_: RSpliet: yeah. and a whole bunch of other stuff
14:20 pmoreau: Ok, I'll test on both then to be sure :)
14:20 imirkin_: well, just saying, if you don't see a crash on the nv96, test your nvac :)
14:20 imirkin_: more than likely it's something dumb and generic
14:21 imirkin_: but just wanted to mention it on the off-chance it was related
14:23 pmoreau: Let's see when I have time for that.
14:23 pmoreau: Time to go home though, bbl
14:24 RSpliet: doesn't crash on NVA3
14:24 zogi: imirkin_: actually I'm about to buy a new card, so probably some kind of Maxwell
14:25 imirkin_: zogi: ah, that'll be an uphill battle for all nouveau stuff
14:25 imirkin_: zogi: the GM107 is sorta supported, but the GM20x stuff has no acceleration atm
14:28 zogi: imirkin_: I see. So it would be better to have older hardware. ATM I only have a 5-year-old Radeon card, sadly
14:28 zogi: imirkin_: although I have access to a Tesla at the university
14:28 imirkin_: zogi: which radeon card? which tesla?
14:29 imirkin_: zogi: btw, when i talk about nvidia tesla, i'm talking about the family, not the marketing term for their super high-end gpu's
14:29 zogi: imirkin_: Mobility Radeon HD 5850
14:30 imirkin_: well, tons of stuff left to do for evergreen/ni cards too if you're interested
14:30 zogi: imirkin_: I don't know the nvidia card precisely, but it's not high-end, thats for sure :)
14:30 imirkin_: not a lot of stuff left to do for the nv50 (tesla) family though... compute and that's about it
14:32 zogi: imirkin_: So which family would be optimal for the sake of nouveau development?
14:32 zogi: imirkin_: or which card
14:32 imirkin_: zogi: probably a kepler card... has a good combination of things to do and workingness level
14:33 imirkin_: although GM107 will be up there soon too
14:33 imirkin_: (that's the GTX 750)
14:34 imirkin_: but the GTX 960/970/980 are a while away from being particularly useful
14:47 RSpliet: damn it
14:47 RSpliet: imirkin_ it only crashes when I don't hook portal up to GDB
14:48 RSpliet: there might be something else at play
14:48 imirkin_: stupid heisenbugs
14:48 imirkin_: are you using a 32-bit gdb?
14:48 RSpliet: what I find more interesting is that I get 192fps on the NVA0
14:48 RSpliet: WITH gdb somewhere in between ish
14:49 imirkin_: nva0's were monsters...
14:49 RSpliet: I know
14:49 RSpliet: it doesn't even fit in my chasis
14:49 RSpliet: I had to unscrew the hard drive bracket
14:49 imirkin_: ;)
14:50 imirkin_: i won't even ask about the GTX 295's
14:50 imirkin_: (2x nva0 on a single board iirc)
14:50 imirkin_: Maximum Graphics Card Power (W) - 289 W
14:50 imirkin_: hehe
14:51 RSpliet: gheh
14:51 RSpliet: yeah
14:51 RSpliet: reclocking effect is pretty brutal on Portal too
14:51 RSpliet: 92fps -> 190fps
14:51 imirkin_: who knew -- faster clocks translates to higher fps
14:51 RSpliet: well yes
14:51 imirkin_: will wonders never cease!
14:52 RSpliet: I haven't seen a "times more than two" before though
14:52 RSpliet: then again
14:52 RSpliet: memory clock goes almost *4
14:52 imirkin_: hehe
15:18 newb123: Anyone have experience in running nouveau headless in a VM without a monitor attached?
15:20 imirkin_: newb123: what are you trying to achieve?
15:33 newb123: imrikin_: Well I'm testing pci-passthrough in a VM. The VM doesn't have VGA support, so I wanted to run xorg to see if the VM can use the GPU (passed-through) hardware acceleration.
15:33 imirkin_: which gpu is it?
15:33 imirkin_: and do you have a iommu?
15:34 imirkin_: afaik for g80+ with an iommu on pcie, it should Just Work (tm)
15:40 newb123: I have iommu, I have a GK106 nvidia card.
15:40 imirkin_: afaik it should be possible to make that setup work
15:40 imirkin_: i.e. have the VM use the card directly for regular VGA output
15:41 newb123: Right. I tried setting modeset=0, but I'm having some trouble starting up xorg. Nouveau has been modprobed.
15:41 imirkin_: (and accelerated output too of course)
15:41 imirkin_: you need to make sure it's not being used by the host machine
15:41 newb123: oh.. hmm
15:41 newb123: it's not
15:41 newb123: well hmm
15:41 imirkin_: and you need to do the whole IOV thing
15:41 imirkin_: add a pci stub driver for it
15:41 newb123: IOV?
15:41 imirkin_: etc
15:41 imirkin_: http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM
15:42 newb123: Actually you brought up a good point. I think I still have the VGA connected to my host machine.
15:42 imirkin_: i assume you're using kvm btw. if you're using something else, it'll probably fail.
15:42 newb123: but I assigned the card to the VM.
15:42 imirkin_: [like virtualbox or some bs like that]
15:42 newb123: oh it's kvm dependent? I'm using bhyve
15:43 imirkin_: well, it's not kvm-dependent
15:43 imirkin_: but afaik kvm is the only thing that actually gets virtualization right.
15:43 newb123: i can "see" the card and load the drivers. But I suppose the VGA is still being connected.
15:43 imirkin_: everything else comes with mildly prettier ui's but doesn't actually work
15:43 newb123: Is there a simple test I can perform that's even easier than starting up xorg with nouveau?
15:43 imirkin_: lspci
15:44 newb123: it shows up in lspci
15:44 imirkin_: can i see?
15:44 imirkin_: lspci -nnvvv -d 10de:
15:45 newb123: http://pastebin.com/itw1ahA0
15:46 imirkin_: erm, that's odd... BAR1 seems messed up
15:46 imirkin_: perhaps it only gets set up when a driver enables it
15:47 imirkin_: so what happens when you load nouveau?
15:48 newb123: you mean modprobe?
15:48 newb123: it shows up in lsmod
15:48 newb123: but i didn't check dmesg
15:48 imirkin_: what do you see in e.g. dmesg
15:48 imirkin_: and that lspci output
15:49 imirkin_: also, you didn't assign the audio subfunction to the VM
15:49 newb123: is that necessary?
15:49 imirkin_: while that may not matter, it's definitely awkward
15:49 newb123: you're talking about hda right?
15:49 imirkin_: yea
15:49 newb123: okay
15:49 newb123: give me a moment restarting the host.. i'll assign the hda too
16:04 newb123: okay
16:04 newb123: imirkin_: what am I looking for in dmesg
16:04 imirkin_: nouveau-related messages
16:05 imirkin_: but the fact that BAR1 wasn't listed is definitely a bit surprising
16:05 newb123: hmm I don't see anything from nouveau even though the driver is loaded. I see some messages about nvidia
16:06 imirkin_: do you have modeset=0?
16:06 newb123: yes
16:06 imirkin_: if so, that disables nouveau entirely
16:06 newb123: oh
16:07 newb123: okay let me modify that.. i do seem to get a lot of "can't derive routing for PCI INT A" errors though
16:07 newb123: http://pastebin.com/shjak6eK
16:07 imirkin_: right... so you're using the nvidia blob driver
16:07 imirkin_: and it's unhappy
16:08 imirkin_: moral of the story -- use kvm
16:08 newb123: restarting the VM without the modeset
16:08 newb123: give me as econd
16:08 imirkin_: nouveau will fail in the same way
16:08 imirkin_: perhaps even more spectacularly
16:08 newb123: okay.. so the pci is just broken then in bhyve
16:09 imirkin_: dunno
16:09 newb123: so if i were to use kvm. on the host i can connect the monitor to my graphics card
16:09 imirkin_: but i definitely wouldn't trust it
16:09 newb123: and if i pass through the gpu to the vm
16:10 newb123: would it display on the monitor? what happens to the shell/terminal output?
16:10 imirkin_: huh?
16:10 newb123: earlier you mentioned about how the host can't use the VGA.
16:11 imirkin_: host can't use the pci device being passed through to the vm
16:11 newb123: so i'd need to use the integrated intel graphics card then..
16:11 newb123: and then the VM would run "headless" but be able to perform compute capabilities
16:11 newb123: ?
16:12 imirkin_: headless meaning what?
16:12 imirkin_: meaning no monitors connected? sure
16:12 imirkin_: or you could connect a monitor to it
16:12 newb123: yeah no monitors and not even VNC.. just like cuda compute or hardware accelerated decoding
16:12 imirkin_: (in fact, probably the same monitor if it has multiple inputs)
16:12 newb123: ahh i see
16:13 newb123: but the host is using a separate graphics card
16:13 imirkin_: as headless as any computer that has a video card that doesn't have a monitor attached to it :)
16:15 newb123: hmm i guess i should try swapping monitors then on the host.. i have the gpu connected right now..
16:15 newb123: but most likely.. the passthrough is broken since the wireless card didn't pass through too well either
16:15 imirkin_: use kvm.
16:15 imirkin_: kvm works
16:15 imirkin_: things that are not kvm don't work
16:16 newb123: true.. but I can't use kvm.
16:16 imirkin_: make sure that you have a iommu of course.
16:16 imirkin_: why not?
16:20 newb123: at the moment I just can't because all of my stuff is integrated with bhyve
16:21 newb123: anyways thanks for the help. I'm pretty sure the pci passthrough is just broken on the version of bhyve I have at the moment
16:22 newb123: bhyve also uses libvirt, so hopefully at some point kvm and bhyve can benefit together
16:22 imirkin_: did you do the pci stub thing?
16:30 newb123: yes on freebsd i used pptdev loader variables. I think the PCI is just broken in FreeBSD 10.1 bhyve. I might get around to try kvm for kicks though.
16:35 imirkin_: the link i sent you
16:35 imirkin_: with telling the host os to use the pci stub driver
16:36 imirkin_: on the device being passed through
16:36 imirkin_: you need to do something like that, or it won't work
16:54 newb123: right i did that.. but on freebsd
16:55 imirkin_: ah ok
16:55 imirkin_: dunno what the freebsd situation is with all that
16:58 newb123: here's the output with nouveau, after i reattached the monitor and a restart on the host. http://pastebin.com/CBzuu1AT
16:58 newb123: after that section.. there's a vm error and subsequent call trace
16:59 newb123: so looks like it doesn't work in the version of bhyve that i have
16:59 imirkin_: yeah, coz BAR1 isn't there
16:59 imirkin_: we really need BAR1 :)
16:59 imirkin_: i guess technically we don't, but in practice the driver sorta assumes its presence
17:01 imirkin_: basically in lspci output, you should see something like Region 1: Memory at e0000000 (64-bit, prefetchable) [size=128M]
17:02 skeggsb: imirkin_: actually, we kinda do *need* it on gf100 and up, pfifo's user area poller looks there :P
17:02 skeggsb: (for user control regs)
17:03 imirkin_: but does it *have* to look there?
17:04 imirkin_: i mean, gk20a doesn't have a BAR1 and it manages to function
17:04 skeggsb: we plug a bar offset directly into a register, so i presume so
17:04 imirkin_: (or was it a diff bar that it was missing?)
17:04 skeggsb: it's BAR3 that's missing there
17:05 imirkin_:forgets what the various bar's do
17:05 skeggsb: BAR1 is FB, BAR3 is PRAMIN
17:05 imirkin_: and the difference between those of course is...
17:06 skeggsb: BAR1 is meant for user mappings, BAR3 is meant for instance memory mappings (and is a lot smaller)
17:07 skeggsb: also need BAR1 to handle some of the more complicated tiling reshuffling etc
17:07 skeggsb: (for cpu mappings of tiled buffers)
17:07 skeggsb: not that we actually use those these days anyway
17:07 imirkin_: right ok
17:08 imirkin_: i should just stop asking questions... my lack of knowledge knows no bounds :)
17:08 skeggsb: i think we can all say that :P
17:08 imirkin_: but i can't say i ever really understood "instmem"
17:08 imirkin_: seems randomly inserted at various points, and appears to work
17:09 imirkin_: but beyond that, its distinction from a regular vram gpuobj is a little lost on me
17:09 skeggsb: it's somewhat of a legacy thing now (mostly, PDISP still uses the pre-G80 model)
17:11 skeggsb: er, pre-GF100, G80 still had some similarities there
17:12 imirkin_: it's somehow related to those dmaobj things?
17:12 skeggsb: those live in instance memory
17:13 skeggsb: as do other context objects, when they still had "physical" representations (before gf100)
17:15 skeggsb: prior to g80, the end N bytes of VRAM were mapped over PRAMIN (in BAR0 at the time, though nv4x kinda hacks the same thing up through BAR3 too)
17:15 skeggsb: and addresses of objects weren't vram addresses, but offsets from the start of PRAMIN
17:16 skeggsb: g80 extended this into giving each channel its own private area from which objects were addressed relative to
17:17 skeggsb: gf100 got rid of context objects alltogether (except PDISP, which still has them to this day)
17:17 imirkin_: that's all the 0x180 fifo methods on the G80?
17:18 skeggsb: yeah, methods 0x180-0x1fc lookup the handle passed to it in RAMHT (also lives in instance memory and maps handles to instance memory offsets)
17:18 skeggsb: and used for various things, depending on the method
17:19 skeggsb: for dma objects, they describe the limits for the types of accesses that are allowed etc
17:20 skeggsb: that concept is rather deprecated since gf100, and we don't use it on nv50 for much really either, and just plug in "rw access to entire vm" objects
17:20 imirkin_: right
17:20 skeggsb: (except for some stuff like semaphores, that don't have offset fields large enough to address the whole thing)
17:21 skeggsb: ... until g84 :P
17:21 imirkin_: hehe
17:21 imirkin_: right, with the separate fifo semaphore methods
17:21 skeggsb: but, PDISP uses the old-school model still for some reason i haven't quite figured out yet
17:23 imirkin_: no reason to change and it works as-is?
17:23 imirkin_: it's its own little world... its own fifo, its own everything, right?
17:26 skeggsb: yes, true
17:27 imirkin_: speaking of which... what was that "disp/nv50-: fix push buffers in vram" fix?
17:28 skeggsb: nothing relevant to drm, i noticed the bug when working on atomic code
17:29 imirkin_: ah ok
17:29 skeggsb: (which i'm testing the functions from userspace, so have to use vram)
17:34 skeggsb: btw, i'm somewhat making progress on buhman's bug.. cutting down a trace replay to find out what makes the GPCs not ignore the GPCCS fuc upload
17:34 imirkin_: nice
17:34 imirkin_: so replaying the blob trace makes it work i assume?
17:34 buhman: :DDD
17:34 skeggsb: once you cut out the pieces that make the system hardlock, yes :P
17:35 imirkin_: hehehe
17:36 imirkin_: so i guess they must be doing something right that we're doing wrong...
17:36 skeggsb: shock :P
17:36 skeggsb: having access to the actual information on how to program the hw must be nice :P
17:36 imirkin_: i bet it's a double-edged sword
17:37 imirkin_: they might have docs, but we have something they don't --
17:37 imirkin_: traces from their driver to copy from :)
17:37 skeggsb: haha
17:37 imirkin_: now having *both* would certainly be an improvement
17:38 imirkin_: but coming up with the original sequence might not be the easiest thing in the world when you have books and books worth of detailed docs on the various regs
17:38 imirkin_: and the problem you're trying to resolve is "it doesn't work"
17:39 buhman: heh
17:39 airlied: imirkin_: you generally have simulators as well :)
17:39 imirkin_: yeah. and they have tons of debug registers too
17:40 imirkin_: it's a lot easier than not having docs and not having a trace to copy from ;)
17:40 imirkin_: just saying... don't underestimate the usefulness of a working example to copy from
17:41 imirkin_: airlied: e.g. the whole dp audio thing... you looked at the docs, saw hda verbs, and moved on. we see "write x to register y" and just copy that
17:42 imirkin_: harder for us to account for every scenario, but getting _some_ scenario working is a lot easier
17:43 skeggsb: it's not always that simple. for the first hda audio stuff on hdmi, that required reading the eld spec etc as simply copying register writes makes it work for exactly my gpu+monitor combo etc
17:43 skeggsb: and i don't think DP would've been possible to make work without reading the DP spec too
17:43 imirkin_: right, but eventually you noticed that it was "copy edid data here
17:44 imirkin_: anyways, i'd be perfectly happy to have working dp audio on just my monitor :)
17:44 skeggsb: yes, making stuff work in one scenario is easy enough the way we do things (sometimes...), it's the generalising it into something useful to merge that's rather difficult still
17:44 imirkin_: but yeah, sometimes traces don't cut it
17:45 skeggsb: like gk106 gddr5, for example :P i know the bits i need to copy from the binary driver to make it work on my machine+monitor combo.. but not (yet) how to come up with the many magic values myself
17:46 imirkin_: gddr5 is like the most finicky thing in the world though
17:47 imirkin_: you're picking counter-examples. which is fine. they exist.
17:47 skeggsb: just playing devil's advocate :)
17:47 skeggsb: i definitely agree with your point
17:53 imirkin_: bbl
19:13 whompy: I saw something about Portal crash testing earlier. I planned to fire that up this weekend anyway on my Tesla.
19:13 whompy: Anyone know how to reproduce?
19:15 imirkin: i think RSpliet had some repro steps... replay some timedemo or something
23:41 gnurou: imirkin: re: version checks in libdrm, could you elaborate on what is expected? Should libdrm check the kernel driver version and only enable flags that it does recognize?
23:42 imirkin: gnurou: i guess it's a good question as to whose problem this should be
23:43 imirkin: e.g. we have kernel checks in mesa re compression support
23:43 imirkin: but... _someone_ should be able to find out whether it's supported or not
23:43 imirkin: since just swallowing this flag is kinda... not great
23:43 imirkin: [right?]
23:43 imirkin: the way it's usually done is by bumping the drm version
23:44 imirkin: which is then accessible from... somewhere
23:44 imirkin: src/gallium/drivers/nouveau/nvc0/nvc0_screen.c: if (dev->drm_version >= 0x01000101) {
23:44 imirkin: for example
23:44 gnurou: this particular flag should not give us surprises, since older Nouveau drivers will ignore it, and they don't support gk20a anyway
23:45 imirkin: what if i want to use this flag on non-gk20a?
23:45 imirkin: [i haven't thought about whether that makes sense]
23:45 gnurou: Ben bumped the kernel driver minor version after merging the kernel patch though, so we can use that to check if it is supported though
23:45 imirkin: yeah, i think that's ideal
23:45 gnurou: for older kernels it would not make sense
23:45 skeggsb: imirkin: we probably should actually, avoid the overhead of snooping
23:45 skeggsb: radeon proved that it's faster
23:46 skeggsb: iiuc
23:46 gnurou: for the sake of consistency it seems reasonable to perform a version check though
23:46 imirkin: seems to make sense... not-snooping seems faster than snooping :)
23:46 gnurou: so now, what should libdrm answer if Mesa attempts to use that flag, but the kernel version reports it doesn't support it?
23:47 skeggsb: so many layers that have to agree :P the binary driver has it easier
23:48 imirkin: skeggsb: yeah, until someone upgrades the blob software without rebooting :)
23:48 imirkin: i think they try to not fail horribly, but they do complain fairly loudly
23:48 imirkin: of course those complaints tend to fall on deaf logs
23:49 imirkin: gnurou: good question... i guess i dunno. but we should figure out what should happen in that case and enforce that. perhaps the answer is "silently swallow", but i want us to arrive at that answer deliberately rather than randomly :)
23:50 gnurou: I will look at what the code does in similar cases
23:50 skeggsb: perhaps: enforce mesa to *require* the new libdrm version, and have mesa not use the flags in the case of an old kernel
23:50 gnurou: I'd like to flush the remaining user-space patches so you guys can work with upstream repos instead of mines
23:51 skeggsb: i'm starting to think that with the ddx becoming irrelevant (for current hardware that can do modesetting+glamor), perhaps mesa should swallow the bits it needs from libdrm
23:52 imirkin: skeggsb: i'd rather it remain possible to write standalone applications that use nouveau
23:52 imirkin: it was very useful when i was getting vp2 to work, for example
23:52 skeggsb: right. i tend to use my userspace build for such things, but, you've got a point
23:53 imirkin: [obviously it'd still be _possible_, just... more complicated]
23:53 imirkin: also the ddx isn't going anywhere
23:53 imirkin: even if one accepts the glamor argument (not sure that i do), there's the older hw
23:54 skeggsb: and that'd still work with the libdrm stuff that currently exists
23:54 imirkin: oh i see
23:54 imirkin: you're just arguing for leaving libdrm alone and continuing dev inside mesa
23:54 skeggsb: right
23:55 imirkin: not the worst idea... dunno. it gets touched so rarely :)
23:55 skeggsb: though... i guess that also depends on what happens with vulkan, and whether that is done inside mesa or not..
23:55 skeggsb:would love to get his hands on those alpha headers and prototype some stuff in his spare time
23:56 imirkin: and there's the theoretical project someone might do some day of getting a libXvMC going for nv1x/nv3x hardware :)
23:56 imirkin: although that again could rely on existing libdrm
23:58 skeggsb: imirkin: btw, current status of buhman's bug is: all my trace bisecting was a waste of time
23:59 imirkin: doh
23:59 imirkin: how come?
23:59 skeggsb: imirkin: i got it down to having just the binary driver's devinit + the test code, and it still worked...
23:59 imirkin: wtf
23:59 imirkin: devinit as in the vbios init table running?
23:59 skeggsb: imirkin: then, i noticed that it actually *wasn't* working and that the old value from some time that it *did* work stuck across reboots