00:37zZap-X: i have a strange problem
00:37zZap-X: i am running Slackware 14.2 with a 4.4.x kernel
00:38zZap-X: i am using a old Nvidia FX5200 PCI graphic (for MAME)
00:38zZap-X: when the box starts booting, half-way through the screen turns black
01:57imirkin: zZap-X: anything interesting in dmesg?
01:57imirkin: zZap-X: sounds like this happens when nouveau tries to take over from vgafb
01:58imirkin: a full dmesg should provide some info.
02:00imirkin: snkcld: depends i suppose. the providers stuff is necessary for dri2-based offloading. is that what you're trying to do?
03:23imirkin: wow, int64 was a surprising quantity of typing in from_tgsi code.
03:23imirkin: hopefully it works.
03:24imirkin: pmoreau: didn't you have some helpful patches for some stuff? or only cvt's?
03:34imirkin: oh hrm. at least comparisons need fixing.
03:47imirkin: gr. ILLEGAL_INSTR_ENCODING
03:47imirkin: pmoreau: does I2I.S64.S64 not work? :(
03:48imirkin: [for abs]
03:50imirkin: mwk: any clue with IMNMX.LOW/MED/HIGH mean? the former 2 consume a CC
06:07zZap-X: gonna test the fx5200 again in a bit
06:07zZap-X: also does the nouveau support xorg custom modelines?
06:08zZap-X: i will be generating lots of arcade low-res modelines listed here: http://www.geocities.ws/podernixie/htpc/modes-en.html#avga
06:08zZap-X: for MAME
06:27zZap-X: found these errors in dmesg: http://sprunge.us/
06:28zZap-X: must be conflicting with the internal onboard graphic card? i915?
06:37mwk: imirkin: I don't know *how* they work
06:37mwk: but they are used for multi-precision min/max
06:38mwk: you start with the high parts, and do IMNMX.HIGH
06:38mwk: and it computes high part of the result, storing some intermediate state to CC
06:39mwk: then you do IMNMX.MED as many times as you want for the middle parts, this eats CC and produces CC
06:39mwk: and finish with a LOW
09:30zZap-X: right managed to get nouveau working in xorg
09:30zZap-X: how can one get nouveau to ignore EDID?
11:48glennk: zZap-X, https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID
11:49zZap-X: thanks will read
11:49zZap-X: glennk: i dont want nouveau to respond to edid as i will be using custom modelines
11:49zZap-X: for mame 15khz
11:53glennk: the idea is you supply a custom edid with the modelines you want in it, and tell the kernel to use it instead of the detected ones
12:00zZap-X: glennk: cant i just put in custom modelines in xorg.conf
12:06glennk: the kernel is in charge of programming the display timings, not xorg
12:06zZap-X: glennk: when i use the nvidia driver i can turn off edid detection in xorg.conf
12:08glennk: the blob driver does its own thing
12:10zZap-X: aye ok
13:24mlankhorst: imirkin_: you mean vram or gart?
13:48mlankhorst: imirkin_: vram is managed through TTM, iirc bar has its own vm so the active pages have a mapping to it
15:25imirkin: mlankhorst: i mean vram... i think there's some core misunderstanding on my end about how all this works, perhaps you can un-confuse me
15:26imirkin: so you have a CPU, and it has instructions like read/write from memory. some of those memory addresses are claimed by the PCI bus, and reads/writes to those addresses end up there.
15:26imirkin: but my understanding is that that's a fixed window
15:27imirkin: so... no amount of a VM on the GPU will change that
15:28imirkin: unrelated to all that, my understanding is that it's possible to map an arbitrary quantity of vram on g80+. how can that be?
15:30imirkin: zZap-X: nouveau (and every other KMS driver) will try to set a mode on load, to be used for backing fbcon/fbdev. in order to do that, it will use the monitor's EDID. you can later set any other mode you like by properly configuring xorg. but the mode that fbcon runs on is going to be the preferred mode in the edid, or failing that, some fallback mode.
15:30imirkin: zZap-X: you can specify a custom edid which has the mode you want to convince nouveau to set that mode for fbcon
15:31imirkin: there are a few cooked ones for common resolutions, or you can supply your own.
15:32imirkin: mwk: this might be a silly question... wtf is multi-precision min/max?
15:33imirkin: mwk: oh, for like > 32-bit ints? so for 64-bit you'd only use high and low, but for 128-bit you'd use high/med/med/low?
15:35imirkin: i'm doing 64-bit ints in nouveau
15:35imirkin: it looks like 64-bit int support in the ISA is extremely half-hearted
15:35imirkin: among other things, there doesn't appear to be an abs :(
15:35imirkin: it's not like i can't implement these things, but ... ugh.
15:37imirkin: or neg. URGH.
15:38imirkin: [there is an I2I.S64.S64, but it doesn't appear to work]
15:41imirkin: pmoreau: have you tackled any of this stuff? if so, i'd like to avoid duplicating work...
15:43karolherbst: imirkin: you mean the modifiers or the abs/neg instructions?
15:43imirkin: karolherbst: in the ISA there are no explicit abs/neg instructions
15:43imirkin: only I2I/F2F/etc
15:46karolherbst: uhm, so convert with mod?
15:46imirkin: well, normally that's I2I
15:47imirkin: (int to int)
15:47karolherbst: I see
15:58mwk: did you check what cuda does when you neg/abs i64 things?
15:58imirkin: karolherbst: if you feel like doing some tracing on blob, you could confirm it for me...
15:59imirkin: mwk: no.
16:01imirkin: and stuff like < and >= are annoying =/
16:04karolherbst: imirkin: i am a bit busy the next days and today, but if you send me stuff I will usually do those until the next day
16:04imirkin: karolherbst: nah, don't worry about it
16:13imirkin: grrrr. ILLEGAL_SPH_INSTR_COMBO for I2F.F32.S64 R0, R0; :(
16:17imirkin: aha. that just needs the fp64 flag set.
16:56mlankhorst: imirkin: just a sec let me find the right bits again
16:56mlankhorst: imirkin: page fault handler goes into ttm, goes into nouveau for mapping
16:58imirkin: ok, so is the deal that we map arbitrary amounts, and then have a page fault handler which ACTUALLY maps those pages in, and unmaps "old" ones?
17:00mlankhorst: VM_FAULT_NOPAGE means retrying
17:00imirkin: ah, that makes a lot more sense. and is much less magical.
17:07mlankhorst: I only knew because I was working on locking
17:34imirkin: mwk: can you think of a clever way of doing < and >= with 64-bit ints?
17:38imirkin: the dumb way would be to do eq(high) ? cmp(low) : cmp(high)
17:38imirkin: of course there's various subtlety involved with signedness =/
17:39imirkin: like flipping the low bits if high is negative
17:44imirkin: oh i guess i can use the cuda compiler thingie to see what it does... hrm.
17:44imirkin: need to figure out how to make it go again
17:47imirkin: mwk: ok, it does ABS by negating (by subtracting from 0), and then SLCT by looking at the high word
17:49imirkin: and the compares are done by doing a ADD.CC + ISET.X. clever. now i know what those things do ;)
18:02mwk: ah yes, the iset.x thing...
18:37imirkin: mmkay. this is starting to come together.
18:43imirkin: just need to shr/shl and i think i'm done
20:49snkcld: i asked this yesterday but missed my answer... so i apologize for repeating. but i recently got an xps 15 with nvidia graphics... and i see the nvidia card in lspci as a "3D controller". however, when i run glxinfo it shows "OpenGL renderer string: Mesa DRI Intel(R) Kabylake GT2"., even when i add DRI_PRIME=1
20:50snkcld: why is DRI_PRIME=1 not setting it to use nouveau?
20:51imirkin: probably because you don't have DRI3 enabled, and haven't set up DRI2 offloading.
20:53snkcld: imirkin: ah, thank you! ok, i will attempt to determine if dri3 is enabled
20:53snkcld: how can i figure that out?
21:20snkcld: ah, i just noticed this
21:20snkcld: nouveau 0000:01:00.0: unknown chipset (137000a1
21:20snkcld: that could be why its not working lol
21:21imirkin: could be, yes.
21:21imirkin: you won't get any accel with it anyways
21:21snkcld: doy ou know if 137000a1 is currently in the kernel master branch?
21:21imirkin: no, but it should be easy to get modesetting going on it
21:21imirkin: but accel won't happen.
21:22snkcld: it wont? hmm... maybe im naive but whats the use of a gpu that isnt accelerating ?
21:22snkcld: and how would i get modesetting to work on it if the nouveau driver isnt recognizing it?
21:23imirkin: i dunno - you're the one who bought it...
21:23imirkin: you can get GP107 going by looking at the commit that added GP106 and doing something extremely similar. should be pretty self-evident.
21:23imirkin: [which, again, will just get you modesetting, not accel]
21:24snkcld: that is awesome! ok, this is great because ive been wnating to actually contribute to the kernel
21:27snkcld: imirkin: something like this? https://github.com/torvalds/linux/commit/1fe487d7d2858265e23f10fa6b4565112f9a17fe
21:28imirkin: yes, a lot like that.
21:28snkcld: i have no idea what those fields are in the nv136_chipset structure though
21:29snkcld: imirkin: ^ is that someone that has already submitted the patch you are proposing would work?
21:29snkcld: looks like it is
21:29imirkin: [and make sure to read the reply too]
21:30snkcld: i dont see a replay :(
21:30imirkin: "next message"
21:30snkcld: ha, ok, sorry
21:31snkcld: ah, i see. looks like he wants a "mmiotrace" , and the guy hadnt responded?
21:31snkcld: so if i do this "mmiotrace" thing and respond to the thread, perhaps it might move the patch along?
21:32snkcld: i would be very happy to do this
21:32snkcld: provided the documentation is enough taht i can figure out how to do it
21:33snkcld: "...nothing subtle has changed that needs to be handled?" what exactly is he looking for? like, does he want to compare the mmiotrace of the previous chip generation to this one, to make sure the mmiotraces are the same, thus allowing the same struct to be used?
21:34snkcld: ah ok, im learning alot here lol
21:34snkcld: ok, im going to do this whole mmiotrace thing
21:34snkcld: looks pretty simple
21:35snkcld: the nvidia driver that i choose to use... should i use the newest version to trace?
21:35snkcld: i might as well, right? the newest version in the ubuntu graphics ppa
21:37imirkin: doesn't matter
21:38snkcld: ok cool
21:38snkcld: the idea of looking at an mmiotrace is see how a proprietary driver is working is awesome
21:38snkcld: i had always wondered how one would reverse engineer closed source drivers
21:39snkcld: "It works by intercepting all the reads and writes by a driver to memory"
21:39snkcld: does that mean that it does not take into account any communication done via IO ports?
21:40snkcld: are IO ports simply not relevant?
21:46nyef: Modern hardware typically uses memory-mapped I/O exclusively.