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