00:00biker_rat: is karol herbst here?
00:11biker_rat: anyone know the current stick on kepler reclocking?
00:14biker_rat: I will return with the same question tomorrow. Good bye.
00:24pseudomind: Would anybody here have an idea of how difficult it would be to get a Geforce 940MX (GM108) working in a preliminary fashion under nouveau?
00:25pseudomind: I was just checking around online and from what I can tell, there only appear to be a couple of differences between the 940MX and the 940M, namely the clock speed and the memory clock speed.
00:28pseudomind: I just recently acquired a laptop which has this video card in it and I would be willing to try and make changes to the source code to see if I can get it working... but, since I don't have any experience in driver development and haven't recompiled a linux kernel in years. I'm wondering if this may be a larger task than I should attempt.
00:36ilia: pseudomind: have you tested, 940M doesn't work with nouveau driveres?
00:51imirkin: pseudomind: afaik it should work
00:51imirkin: pseudomind: if it doesn't, have a look at ... this bug (sec)
00:52imirkin: pseudomind: https://bugs.freedesktop.org/show_bug.cgi?id=95188
01:01pseudomind: I don't have that computer on my at the moment, but from what I remember, the nouveau driver was not able to recognize the device id or something to that effect.
01:03pseudomind: When I get home tonight I'll take a look at what the exact message I was getting from dmesg and post it here.
01:13imirkin: pseudomind: that would imply your kernel is too old - you may need 4.7-rc in order to get GM108 support
01:23pseudomind: yeah, that might be the case... I think I am running 4.6.4-XXX on that system right now.
01:25pseudomind: That's really exciting news actually. Thanks for taking the time to answer my questions, imirkin.
01:42imirkin: pseudomind: with karol's branch, you should also be able to get reclocking on that gpu, so you should be able to get some perf out of it
01:51pseudomind: Dang, that's great! Are there plans to mainline that re-clocking support? If so on what sort of time frame are we looking at?
01:52imirkin: sure, there are plans. but thus far it doesn't seem imminent.
01:52imirkin: in the meanwhile, you can use nouveau from https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler_v5
02:24gnurou: imirkin: interesting... it is as if the WPR region was not set properly
02:26gnurou: could be a bug which only manifests itself with 4GB RAM? I think all the GM20x I have only embed 2
02:29gnurou: but I cannot find where the WPR region would overflow...
02:29gnurou: ... oh oh. or a bug in the firmware we provided?
03:20Keringar: Anyone know why envytools cant probe my graphics card?
03:22Keringar: And I am running it as root
05:44gnurou: Keringar probably needs to boot with "iomem=relaxed" (kernel 4.6 according to his log). Too bad he quit irc...
06:21Keringar: gnurou: Thanks
06:23gnurou: Keringar: meh, how come you can see my answers even though you are not online...
06:23gnurou: Keringar: thanks for the log with Ben's patch btw. I won't have access to a board before Monday but the information in it will be useful to understand what is going on
06:24gnurou: if this turns out to be a bug in the ACR firmware (the address looks like it could overflow), maybe we can just allocate the WPR region on a lower area to workaround this
06:29Yoshimo: gnurou: the channel is logged
09:00karolherbst: pseudomind: there? :p
09:52Lekensteyn: karolherbst: what is (unknown) chipset 118010a2? (boot0 & 0x1ff00000) >> 20 gives 0x10001, and 0x10001 & 0x1f0 gives 0...
09:52Lekensteyn: found in http://pastebin.com/MGBjH3wT, PCI device ID is 1341
09:55karolherbst: it was enabled in 4.7 I think
09:57RSpliet: Lekensteyn: "118010a2? (boot0 & 0x1ff00000) >> 20 gives 0x10001" - you might want to double check how shifting and masking works, 0x10001 doesn't sound right ;-)
09:57Lekensteyn: euh oops, I used bin(...) instead of hex(...) :P
09:58Lekensteyn: yes that is more reasonable :p
12:58mslusarz: rhn: if you want to find the size of CREATE argument you can use --mmt-ioctl-create-fuzzer=1/2
12:58rhn: mslusarz: thanks, I will make use of it
15:13karolherbst: finally got a new keyboard :)
15:57hakzsam: imirkin, if you want to look at the MS bs on gm206: https://people.freedesktop.org/~hakzsam/mmt/maxwell/gm206/gm206-arb_texture_multisample-texelfetch-2.mmt.xz
15:58imirkin: hakzsam: can you do one with 4 too?
15:58imirkin: that way i can diff and see where 2 -> 4 :)
15:59hakzsam: imirkin, glxinfo -s -l against blob on gm206 http://hastebin.com/ihomuwulik.pl
16:01hakzsam: imirkin, https://people.freedesktop.org/~hakzsam/mmt/maxwell/gm206/gm206-arb_texture_multisample-texelfetch-4.mmt.xz
16:13imirkin: we have to configure sample locations now.
16:13imirkin: i suspect that's highly relevant
16:14hakzsam: probably yeah
16:15hakzsam: let me know if you need me for testing a patch :)
16:15imirkin: do those look familiar?
16:15Yoshimo: did someone think about the codename page on the wiki and added the pascal cards there?
16:15imirkin: anyways... you should be able to come up with a patch.
16:15hakzsam: I added them
16:16imirkin: if not, let me know, i can put something together
16:16imirkin: the idea is that you can configure the sample positions in a 2x2 pixel grid
16:16imirkin: right now those are all configured the same way for each pixel
16:18hakzsam: I will have a look later maybe :)
16:19imirkin: you should be able to just take the offsets in that get_sample_position function and program them in directly
16:19imirkin: in nvc0_validate_fb
16:19imirkin: [the function returns stupid floating point versions, so either refactor it, or something else]
16:20imirkin: and eventually we can hook up NV_sample_positions or that AMD one, or perhaps there's an ARB version as well
16:20imirkin: that should be feasible on GM200+
16:25hakzsam: I see
16:31hakzsam: imirkin, what this float factor is for?
16:31imirkin: to make it into a floating point offset
16:31imirkin: which is required (a) by gallium and (b) by gl_SamplePosition
16:35imirkin: right now the sample locations all get left as "0", which explains why stuff fails
16:36imirkin: i'd leave the f64 thing alone though - i suspect that's something else
16:37hakzsam: I will add nvc0_get_sample_location() which will be called by bot nvc0_validate_fb() and nvc0_get_sample_position()
16:37hakzsam: to get rid of this float factor
16:41imirkin: i guess you'll need to trace it for msaa8 as well
16:41imirkin: coz i'm not 100% sure how to fit 8 sample locations in there
16:41imirkin: maybe you can only define it for a 2x1 block in that case
16:41imirkin: instead of 2x2
16:43imirkin: yeah. i think the grid is different depending on the MS level
17:22imirkin: hakzsam: neat. there's a GL_EXT_shader_image_load_formatted that's supported on maxwell.
17:23imirkin: hakzsam: maybe you can use SULDP on there instead of the manual conversion
17:23imirkin: hakzsam: or perhaps that's GM200+ only. although i doubt it.
17:29imirkin: Leftmost: if you end up looking into NV_conservative_raster, you may also be interested in glancing at GL_NV_conservative_raster_dilate -- i guess they're highly interrelated.
17:30imirkin: Leftmost: another easy ext to hook up on GM20x would be GL_NV_fill_rectangle
18:56imirkin: hakzsam: you figure it out?
19:24imirkin: hakzsam: hopefully the rnndb commit i just pushed out should help
19:28mwk: imirkin: shouldn't these be counted from 0? :)
19:28imirkin: mwk: what did i screw up?
19:28imirkin: [sorry, it's not obvious to me]
19:29imirkin: oh, you mean X0..X3
19:29imirkin: vs X1..X4?
19:29imirkin: heh, wtvr
20:10lolzinventor: #hi all, ive found a bug in #nouveau. it may be my TV, but it doesnt happen with the nvidia drivers
20:11lolzinventor: with HDMI, if I turn my TV off and on again my PC does not send any HDMI signal to the screen and it does not wake up
20:13lolzinventor: If I use a VGA cable everything is fine. also nv driver is OK with wake up, but has other bugs which is why I want to use nouveau drivers
20:13lolzinventor: works well apart from HDMI wake up. Happens with latest debian and Mint 17.3 and 18.
20:14imirkin: which GPU do you have?
20:14imirkin: i suspect if you plug/unplug the cable, the TV would come back on btw
20:15lolzinventor: NVIDIA Corporation GK107 [GeForce GT 640] (rev a1)
20:15lolzinventor: I tried plugging the cable
20:16lolzinventor: its a one shot deal, have to reboot
20:17lolzinventor: it only happens with power on off. if I logically change tv input then no problems
20:18imirkin: what linux kernel are you on? i remember we used to do bad things with hdmi, but that was ages ago
20:18imirkin: however "latest debian" tends to be "ages old", so... who knows
20:19lolzinventor: im on mint 18 right now
20:19lolzinventor: debian was 3.16
20:20imirkin: ok, definitely fixed in 4.4
20:20imirkin: dunno about 3.16
20:20imirkin: but probably
20:20imirkin: very surprising that plug/unplug doesn't do anything
20:21lolzinventor: yeah, the only reason I'm reporting it is because nvidia driver is ok in this respect
20:22imirkin: well, you could make a mmiotrace of the nvidia driver while performing those actions with the TV
20:22imirkin: and we could see what it does differently
20:22lolzinventor: very wiered. tv quite old. could probably replace and use vga for now.
20:22imirkin: oh, and actually ... hm
20:22lolzinventor: that'd be interesting to try
20:23imirkin: no, that was for dp. nevermind.
20:23imirkin: so yeah, mmiotrace would probably provide the necessary info
20:23imirkin: you can find a guide at https://wiki.ubuntu.com/X/MMIOTracing
20:24lolzinventor: ah thanks, i haven't used it before, let me see what I can do
20:58agrecascino: skeggsb, i was reading a bugzilla post from a few months ago, and you were talking about fixing page sizes in nouveau
20:59agrecascino: i was wondering if you had made any progress on that, since i'm trying to use an nvidia card with a sparc64 machine
20:59agrecascino: which has an 8kb page size
21:00imirkin: agrecascino: you filed a bug about that, right?
21:00agrecascino: no, that wasn't me
21:00imirkin: were you trying to use a NV34 in a sparc64 box?
21:00imirkin: which gpu are you trying to use?
21:00agrecascino: pretty sure it's a gt 520
21:00imirkin: ah, so a fermi. yeah, the page size thing is almost definitely going to be an issue.
21:02agrecascino: i was trying to use an xvr-2500 with it, and while it works, it has some major issues
21:02agrecascino: such as:
21:02agrecascino: bus errors with opengl applications
21:02agrecascino: stuck at 1024x768 with a broken pixel format
21:02imirkin: oh, but it loads, and screen comes up and everything?
21:02agrecascino: and a broken console font
21:02imirkin: hmmm... that means no hpd
21:02agrecascino: imirkin, yeah
21:02imirkin: 1024x768 is the default resolution
21:03imirkin: or edid otherwise doesn't load
21:03imirkin: what's your level of experience with all this?
21:03imirkin: i mean ... are you comfortable writing code, compiling kernels, etc?
21:03agrecascino: imirkin, it's an fbdev kernel module
21:03imirkin: oh. the nvidiafb one?
21:04imirkin: i'm surprised that'd load on a fermi at all.
21:04agrecascino: imirkin, oops
21:04agrecascino: i thought you were talking about the xvr-2500
21:04imirkin: i wasn't sure what xvr-2500 is :)
21:04agrecascino: i tried nouveau with the 520
21:04imirkin: i assumed it was a sparc
21:04agrecascino: it fails loading
21:04agrecascino: xvr-2500 is a gpu for sparc
21:05agrecascino: the point is that the situation is bad
21:05agrecascino: with the 520 it fails on load
21:06imirkin: do you have logs?
21:06imirkin: i would have expected it to load but then not work
21:06imirkin: and hang the system and whatnot
21:06agrecascino: i'll quickly switch it out to get the logs
21:06agrecascino: imirkin, no hang, just fails
21:06imirkin: while you're at it, boot it with nouveau.debug=trace
21:06imirkin: that'll capture the maximum amount of useful info
21:17agrecascino: [ 280.628600] nouveau: probe of 0000:12:00.0 failed with error -12
21:17imirkin: whole log would be great :)
21:18imirkin: file a bug with the info
21:18keringar: Try launching with iomem=relaxed set
21:40hakzsam: imirkin, I will have a look
21:41hakzsam: maybe you can all your ideas on trello? :)
21:41imirkin: trello isn't big enough :p
21:43hakzsam: imirkin, if they are not there I won't remember for sure
21:43imirkin: meh, that's ok
21:43imirkin: btw, the fact that we're not programming 0x8888888 in there is probably messing up regular rendering
21:43imirkin: although perhaps those locations are only used when MS rast is enabled
21:44hakzsam: no idea
21:51hakzsam: imirkin, btw http://hastebin.com/soramixoke
21:52hakzsam: no objections I guess? :)
21:52hakzsam: I did fix some ms tests according to your advices, but it's still a bit hacky
22:05hakzsam: imirkin, what do you want to do for that assert in emitUADD(), I would suggest to remote it but you don't seem to agree
22:06imirkin: the assert is legit.. the whole OP_SUB handling is idiotic
22:06hakzsam: btw, there is no such assert for gk110 and gm107 emitters
22:06imirkin: either flip it
22:06imirkin: so that it's
22:06imirkin: if (op == OP_SUB) assert() else assert()
22:07imirkin: or .. do soemthing lesel
22:07imirkin: or get rid of OP_SUB entirely, which imo is the right direction to go in
22:07hakzsam: I was thinking to do that yes
22:07imirkin: but that will take more work
22:07hakzsam: I mean, the assert with if/else
22:09imirkin: ok. i think that getting rid of op_sub would enable a bunch more optimization opportunities
22:09imirkin: since right now we don't CSE add(a,-b) and sub(a,b)
22:09imirkin: but ... it's more effort
22:09imirkin: woudl have to teach AlgebraicOpt some new tricks
22:09hakzsam: I will just fix up that assert for now
22:09hakzsam: because this regresses arb_shader_image_size-builtin on gf100/gk104
22:25hakzsam: imirkin, heh, did you look few lines below in emitUADD()? because we already check for that case
22:27hakzsam: so if(op == OP_ADD) assert() should be enough
22:29imirkin: i did not
22:29imirkin: ah yea
22:29imirkin: just move that assert out of the if
22:29imirkin: and drop the first one
22:31hakzsam: which asserts are you talking about? because they are 2 :)
22:32hakzsam: this should do the job
22:34imirkin: or you could drop that assert entirely, and move the assert(0x300) out of the if below
22:34hakzsam: imirkin, right
22:39hakzsam: do you have time to look at the bgra issue? ;)
22:39imirkin: sorta ... but i don't have a fermi plugged in
22:39imirkin: it works on kepler
22:40hakzsam: you unplugged your gf108?
22:40hakzsam: okay, fermi issue
22:40imirkin: yeah, i have GK208, GT215, and NV34 plugged in
22:40imirkin: oh, you wanted me to test something on tesla... do you have a specific piglit for hte OP_SUB thing?
22:41hakzsam: I have no idea which test is going to use that opt
22:41hakzsam: but I hope it doesn't regress anything
22:47mwk:managed to find a HCF triangle for the NV01 rasterized
22:48imirkin: mwk: having a good time?
22:48imirkin: sure is easier than writing hwtests for nvc0...
22:49mwk: yeah well
22:50mwk: simulating a NV01 graph engine in software is tractable; NVC0 is not
23:07hakzsam: imirkin, looking at the CB aliasing bug again, and calling CB_SIZE on compute is fine while CB_ADDR fails like this http://hastebin.com/liluvezeze
23:09hakzsam: and forcing the driver cb to be re-bound doesn't fix the thing
23:10imirkin: you mean CB_POS messes it up, right?
23:10hakzsam: no, CB_ADDR
23:10hakzsam: CB_POS is not even called in the paste above
23:11imirkin: ok right
23:11imirkin: that makes sense
23:13hakzsam: I would sugges to just call init_compute() before uploading the MS stuff for 3d
23:14hakzsam: because the driver cb should be correctly re-bound for compute
23:14hakzsam: [in theory]
23:14imirkin: i'd prefer to figure this out...
23:14hakzsam: that would be better, indeed
23:15imirkin: nvc0_blitctx_pre_blit -- try adding it there
23:15imirkin: (DRIVERCONST, that is)
23:16hakzsam: you mean forcing the driver cb to be re-bound?
23:17hakzsam: ah okay, I see
23:17hakzsam: imirkin, I assume this is what you meant http://hastebin.com/uvuveheguw
23:18hakzsam: if so, still fails
23:19imirkin: that is what i meant.
23:20imirkin: also add it to the overall dirty state?
23:20imirkin: what if you just always execute it?
23:20hakzsam: already tried, same issue
23:24hakzsam: really annoying
23:32imirkin: well, if you want to solve it by moving nvc0_compute_init up, feel free
23:34hakzsam: I will spend time before :)