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