05:06 mlankhorst: imirkin: oom killer involved? :P
05:08 mlankhorst: imirkin: http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=83cd5d567b76c2dad172c0040de5fc9058f7a183
08:10 imirkin: mlankhor1t: that seems like it shouldn't be needed... is there a "nice" way of doing this? btw, i have no swap on my box, not sure if that affects things
08:44 mlankhor1t: imirkin: well else you can use more than physical memory limit as gart, since we removed any other limits..
08:45 imirkin: mlankhor1t: oh, and GART can never be paged?
08:45 mlankhor1t: it needs to be evicted to sysmem first
08:45 imirkin: right
08:45 mlankhor1t: which in most cases is removing bindings, but still
08:46 imirkin: does it have to be contiguous too? or is it "per page"?
08:46 mlankhor1t: nah
08:46 mlankhor1t: in theory you could, but nouveau doesn't use huge pages for that
08:46 imirkin: the thing is that i don't think that lxdream should be using too much memory
08:47 imirkin: as i have 6GB of ram, i doubt that's the cause of the problem
08:47 mlankhor1t: probably not :P
08:48 mlankhor1t: I'm not sure if we limit gart in libdrm right now or not
08:48 mlankhor1t: ah we do
08:48 imirkin: i thought just vram
08:48 mlankhor1t: try with NOUVEAU_LIBDRM_GART_LIMIT_PERCENT=25 ?
08:49 mlankhor1t: nouveau/nouveau.c: (nvdev->base.gart_size * nvdev->gart_limit_percent) / 100;
08:49 mlankhor1t: heh
08:49 mlankhor1t: not limited in any meaningful way
08:49 imirkin: hm, i guess lxdream did end up with a total_vm of 1203539 -- whatever THOSE units are
08:49 mlankhor1t: 1<<40 * .80
08:49 imirkin: if that's pages, that's bad
08:49 mlankhor1t: probably pages
08:49 imirkin: coz that's about 6GB :)
08:49 mlankhor1t: 4 GB
08:50 imirkin: or like 5
08:50 mlankhor1t: indeed, per process..
08:51 mlankhor1t: the patch would limit it to 1.5gb globally
08:51 imirkin: this is all such a joke... dreamcast had what, 16MB of ram?
08:52 imirkin: 16mb ram, 8mb vram
08:52 mlankhor1t: come on you're too young to say that. :p
08:53 imirkin: how so?
08:53 imirkin: first off, it's ridiculous that lxdream runs out of 6G of ram when trying to emulate a dreamcast
08:53 imirkin: secondly, i'm 97% sure i'm older than you :p
08:53 mlankhor1t: oh didn't know lxdream was a dreamcast emulator, probably
08:55 glennk: is that project still alive?
08:55 imirkin: i've been trying various options
08:55 imirkin: it does exist, and it has had recent commits, but it's basically dead
08:55 imirkin: on the bright side, it seems to work fine until it crashes with fire
08:56 imirkin: reicast took some doing to get up and running on my box, but it freezes before the intro of doa2
08:56 glennk: 32 bit build?
08:56 imirkin: nulldc works fine, but it's wine, and has some audio sync issues (i think)
08:56 imirkin: 32-bit build for reicast... maybe not for lxdream
08:57 imirkin: nope, 64-bit build. hm
08:59 imirkin: and naturally i can't build it on 32-bit coz it *must* have lirc which doesn't have an ABI_X86 thing on gentoo =/
11:57 knivsta: anyone here?
11:58 knivsta: How well is Nvidia GT920M or 720M supported by this driver?
12:03 imirkin: what sort of support are you looking for?
12:35 knivsta: imirkin, Like how well would it work?
12:35 imirkin: can you make that multiple choice? what does 'well' mean?
12:35 imirkin: everyone has diff requirements, difficult to guess yours.
12:35 knivsta: What do you mean?
12:35 knivsta: I am just asking if it is supported or not?
12:36 imirkin: sure, it's supported
12:36 knivsta: Thanks
12:36 imirkin: just as well as any other hw that nouveau supports
12:37 imirkin: in fact if it's the GK208 version of the 720M rather than the GF117, then better than many other cards in all likelihood
12:37 imirkin: (920M appears to be all GK208 according to pci.ids)
12:38 knivsta: I think I would go with Intel 5000 Series then
12:38 knivsta: nothing is fully supported on nouveau
12:38 knivsta: its a WIP right?
12:38 imirkin: good bet
12:38 imirkin: intel's pretty well supported
12:38 knivsta: I am buying a new laptop with i5 5th Gen
12:38 knivsta: and i trust Asus
12:39 imirkin: if you get those mobile nvidia chips, it'll be with optimus, and optimus doesn't work so well in the first place
12:39 knivsta: but Asus seems to love 920M GT for graphics and not Intel Graphics
12:39 imirkin: and on top of that, nouveau will likely have various unspecified issues
12:39 knivsta: ok thanks
12:39 knivsta: bye
12:39 knivsta: gtg
15:23 imirkin: skeggsb_: around?
15:23 imirkin: does this make *any* sense to you? http://hastebin.com/unefojekef.pl
15:24 imirkin: that's an *awful* lot of nr_push's...
15:28 imirkin: i think it has to do with nouveau_pushbuf_data usage
15:38 imirkin: interesting, it ends up doing multiple indirect draws with the same bo used for parameters, as well as the same offsets multiple times
15:41 imirkin: is it supposed to first pushbuf_refn the bo before using it in nouveau_pushbuf_data?
15:45 imirkin: skeggsb_: i added an assert(kref) in nouveau_pushbuf_data and it triggers. i assume it should not?
15:54 imirkin: ... and that fixes it (adding a PUSH_REFN)
16:09 skeggsb_: imirkin: what's this for?
16:09 imirkin: stk 0.9 crash
16:10 imirkin: i just sent a patch
16:10 imirkin: but basically cli_kref_get returns null (it finds the entry, but that entry has null .krec and .push)
16:11 imirkin: whereas pushbuf_refn initializes those
16:17 imirkin: skeggsb_: an alternative is to tell nouveau_pushbuf_data to set all of that up on its own when it sees an unknown bo.
16:20 skeggsb_: the current patch looks fine to me
16:21 imirkin: skeggsb_: how would you feel about an assert in nouveau_pushbuf_data?
16:24 skeggsb_: might make mistakes a bit more obvious ;)
16:24 imirkin: and who'd what that? :)
16:25 skeggsb_: that was a "might be a good idea" btw :)
16:26 imirkin: right, i figured
16:32 imirkin: skeggsb_: patch sent
16:44 imirkin: skeggsb_: oh, but with the PUSH_REFN will it end up doing an implicit sync on that buffer?
16:46 imirkin: on nvc0 with the noprefetch thing, that's undesirable...
17:13 imirkin: skeggsb_: is there any way to avoid the sync? looks like a pushbuf must refer to a buffer in the bo list...
17:14 skeggsb_: what's going to cause a sync? it'll only do it if it's been touched by another channel
17:16 imirkin: skeggsb_: perhaps sync is the wrong word
17:16 imirkin: the thing where it waits for a fence
17:16 imirkin: or does it only ever do that for cross-channel situations?
17:16 skeggsb_: it won't, unless the fence is from another channel
17:17 imirkin: ah clever
17:18 imirkin: (and a little surprising... but i guess it makes sense... except that it might sometimes do simultaneous draws i thought...)
17:18 imirkin: i guess ttm still checks the fence to see what all is being used, right?
17:43 imirkin: skeggsb_: not sure if you saw my comment the other day about dumping last-submitted pushbuf on gpu hang?
19:45 imirkin: gnurou: do you have a branch?
19:47 imirkin: [in case i'm extremely lazy]
19:52 gnurou: imirkin: sure, let me push one after lunch and send you a PR
19:53 imirkin: no need for anything so formal... just the thing i need to add as a remote
21:08 gnurou: imirkin: https://github.com/Gnurou/mesa.git for_imirkin
21:08 gnurou: imirkin: this is the current master with these two patches on top
21:15 imirkin: cool thanks
21:16 imirkin: fetched... in the middle of something now, but will push out either tonight or tomorrow
21:32 imirkin: gnurou: what's the status of the GM20B enablement? gotten to mesa yet?
21:34 gnurou: imirkin: thanks!
21:34 gnurou: imirkin: I will be able to test Mesa once I finally get secure FW to work (should be close now)
21:34 gnurou: imirkin: but I am confident it will work without too much trouble
21:35 skeggsb_: i suspect, unless the issues i seen were related to "secure" boot, the only likely issue will be texturing, it seemed to work otherwise on gm204/6
21:35 gnurou: skeggsb_: might give us a good incentive to have a look at this issue actually
21:35 skeggsb_: i seem to sample black from everything for some reason
21:35 gnurou: if we can reproduce it on GM20B
21:35 airlied: skeggsb_: seems pretty secure :)
21:36 skeggsb_: there's a suspicious bit of code in the gm20b work that i wonder if it could be a workaround for that issue
21:36 gnurou: mmm actually it may be related to secure boot
21:37 gnurou: although I would expect values like 0xdead5xxx instead of 0s if that was the case
21:37 skeggsb_: gnurou: 0x100ce4 looks.. possibly related
21:39 imirkin: gnurou: pretty sure the issue is that we don't do any of the sched codes stuff on maxwell
21:40 imirkin: there's all sorts of stuff in there around waiting, syncs, etc.
21:40 gnurou: yeah, we need secure boot first and foremost
21:41 imirkin: someone released docs on all that stuff, but it's kinda complex :)
21:41 imirkin: and i'm kinda lazy and don't have a maxwell
21:41 gnurou: sadly the patches are in a sad state, and I still cannot run it on my upstream branch :/
21:43 gnurou: it's kind of hard to grasp... you first load a PMU bootloader that will load the PMU secure code which will load the FECS and GPCCS bootloaders which will load the actual FW 0_o;
21:43 imirkin: if that's not security through obscurity, i don't know what is :p
21:43 skeggsb_: gnurou: that much, i've known since before gm2xx was released :P the lack of having access to the fw's has been the issue, not understanding how to use them ;)
21:44 gnurou: skeggsb_: sorry about that - I am pushing internally for a release of the dGPU fw now that we have decided a layout
21:45 gnurou: imirkin: it does make sense actually once you get to know why we do this, but it doesn't help writing an implementation indeed :P
21:47 skeggsb_: airlied: secure in the same way that locking your children in the basement for their whole lives protects them from the world ;)
21:51 gnurou: mupuf_: interesting, I did not get your reply to my coherent flag patch - had to go to https://patchwork.freedesktop.org/patch/52295/ to see it
21:51 airlied: skeggsb_: textures are just like drugs, can't sample them, keeps you safe :-P
21:52 gnurou: mupuf_: anyway, I have sent a version increase patch to libdrm, can you take it?
21:56 imirkin: gnurou: you could also just add a #ifndef coherent; define coherent;
21:56 imirkin: in nouveau_winsys.h or so
21:58 gnurou: imirkin: good point, but then you may get corruptions without any warning if you are using an old libdrm
21:58 gnurou: probably safer to make sure everything is up-to-date
21:59 imirkin: err... would you?
21:59 imirkin: why does libdrm care?
22:00 imirkin: gnurou: pushed, btw
22:02 gnurou: imirkin: if you define the COHERENT flag to 0 (which is what you are suggesting, right?) then you won't get coherent buffers contrary to what you would expect
22:03 imirkin: gnurou: no, i'm suggesting you define it to the "right" value
22:03 imirkin: seems harsh to require a libdrm bumb for something as silly as a single define
22:04 mlankhor1t: just do it..
22:04 imirkin: it's pretty annoying when you're not tracking the latest libdrm on the system
22:04 gnurou: imirkin: ah, I see - I'm fine with that if you don't mind having the same flag defined in two different places
22:05 imirkin: just stick a "todo: remove when 2.4.62 isn't quite so new" or something
22:05 mlankhorst: imirkin: wrong
22:05 mlankhorst: we always require newer versions in those cases
22:05 imirkin: i know in the past i've just reverted patches from mesa master instead of updating my system's libdrm :)
22:06 imirkin: and i hate causing annoyance for no real reason. if it was some real change, sure. but for a single define?
22:06 mlankhorst: imirkin: please, you're going to make life harder on packagers like that..
22:07 imirkin: mlankhorst: how so?
22:07 gnurou: I could also put a #ifdef to only use the flag if a new enough libdrm is detected
22:07 imirkin: everything will still work as expected...
22:07 gnurou: since this is only useful for Tegra we would not require a version bump that way
22:07 mlankhorst: no it won't, you'll cause silent failures on armhf like that
22:08 imirkin: mlankhorst: can you explain? perhaps i'm missing something obvious, but as far as i can tell, everything will work just fine
22:08 imirkin: mlankhorst: libdrm doesn't use that BO_COHERENT, it's entirely for the app. so who cares where it's defined... it's just a value...
22:08 imirkin: [obviously kernel must also support it]
22:09 imirkin: [and kernel drm version ought to get bumped]
22:10 mlankhorst: without a new enough libdrm you won't get BO_COHERENT if you specify it to the correct value..
22:11 imirkin: hm?
22:11 imirkin: why not?
22:11 mlankhorst: look at the libdrm code..
22:11 mlankhorst: if (flags & BO_COHERENT) ioctl.new_bo |= GEM_COHERENT; or something..
22:12 imirkin: gah! you're right
22:12 imirkin: gnurou: ignore everything i said :(
22:13 imirkin: someone needs to do a libdrm release before you can use that flag in mesa
22:14 gnurou: imirkin: yep, that's why I sent a patch against libdrm just a few minutes ago :)
22:15 imirkin: right, but that's not what's needed
22:15 gnurou: I should have specified it was for libdrm, since there is no hint what project it is for - sorry about that
22:15 imirkin: you don't just bump up the version via a patch like that
22:16 imirkin: you have to do a full release which includes several steps
22:16 gnurou: I don't have the power to do that, can only send a patch and hope someone will do the rest :P
22:17 imirkin: i don't think i have the power either.
22:20 gnurou: mupuf_ and mlankhorst might be able to help here
22:42 gnurou: Mesa's configure.ac: LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
22:42 gnurou: my autoconf-fu is lacking here... why not a simple version number?
23:09 mlankhorst: because as of 2.4.41 we didn't update the nouveau libdrm automatically
23:09 mlankhorst: feel free to make it 2.6.62 instead
23:09 mlankhorst: erm 2.4.62
23:13 mlankhorst: I fixed it in 2.4.42 after noticing, but there was no reason to require something newer :P
23:20 gnurou: mlankhorst: ok, so just having "LIBDRM_NOUVEAU_REQUIRED=2.6.62" will be correct, right?
23:28 mlankhorst: yes
23:32 gnurou: perfect then - now I just need someone to kindly make a release
23:33 gnurou: <crickets>