07:56endrift: Hey, I'm having a very strange, very specific issue trying to run nouveau on my setup. Or I should say, I have a very strange setup.
07:57endrift: I'm trying to run nouveau on a PowerMac G5 that has a 6800 GT in it
07:57endrift: I'm having exactly the same issues as described in this mailing list thread: https://lists.debian.org/debian-powerpc/2016/01/msg00038.html
07:58endrift: I've built a kernel with 4K pages already, and I've tried 4.9.x and 4.10.x latest kernels, with slightly different effects but the same error message in dmesg and same screen not working properly
07:59endrift: Was hoping I could get some advice on how to get accelerated graphics working in Linux on this G5 in basically any capacity
07:59endrift: if it comes down to it, I'm probably fine trying to get a different video card, but I'd want to grab one I know would work, so I'm a bit hesitant to grab one immediately
11:53gp108: https://videocardz.com/69078/kfa2-geforce-gt-1030-exoc-white-pictured-and-detailed https://videocardz.com/69009/nvidia-pascal-gp108-300-graphics-processor-pictured please add NV138 (GP108) GT 1030 to https://nouveau.freedesktop.org/wiki/CodeNames/#nv130familypascal when possible
12:32skeggsb:is always very curious as to who that is that appears whenever a new chipset surfaces
12:39teklad:doesn't think he's ever seen skeggsb in chat til now.
12:39mupuf: teklad: that's what time difference does to you ;)
12:39teklad: mupuf: I'm an odd one... I'm up from like 5pm til 11am my time.
12:40mupuf: and where are you located?
12:40teklad: America I mean.
12:40mupuf: Ah ah, that covers ~5 hours of difference, doesn't it?
12:40karolherbst: mupuf: maybe it's a bot
12:40mupuf: why would anyone spend 10 minutes of their time to write a bot for this?
12:41teklad: mupuf: I think so.... I'm -6 CST
12:41karolherbst: mupuf: who would spend time of their live every time whenever a new chipset comes out?
12:42teklad: karolherbst: Those kinds of people exist.
12:42mupuf: karolherbst: different story ;) We write once, people use multiple times
12:43teklad: If only nouveau had unlimited funding to buy and break graphics cards.... we'd be in good shape right now.
12:43skeggsb: gp108 looks like it'll be cheap as, so, shouldn't be hard to source
12:44skeggsb: getting fw from nvidia might be challenging but..
12:44teklad: Nah... you just offer them free pie and they'll hand it right over.
12:45karolherbst: they don't like pies
12:45teklad: karolherbst: Really? What about butterfinger cake?
12:46karolherbst: no clue? ask Nvidia
12:46teklad: They must like something tough.
12:46teklad: Like russian turnips.
12:47dboyan_: btw, has anyone tried to extract fw from the blob? (I know that it's not redistributable anyway)
12:47skeggsb: dboyan_: nvidia hid it from us at some point
12:48skeggsb: it used to be in nice gzipped files, they've stripped the headers off so it's hard to find now
12:48teklad: I'm going to be old and brittle by the time they go pro open source.
12:49dboyan_: okay, well
14:11karolherbst: uhh, interesting
14:13karolherbst: segfault in emitshladd
14:14karolherbst: shladd without an immediate
14:14karolherbst: hakzsam: you implemented shladd or was it pmoreau?
14:17hakzsam: I did
14:17karolherbst: okay, I got a shladd without an immediate into the emiter. I assume shladd requires an immediate?
14:18hakzsam: yeah IIRC
14:18karolherbst: then I just check the peephole file
14:20karolherbst: currently testing alien isolation and hit a segfault
14:21karolherbst: odd, doesn't crash on master, maybe my local installation was that old?
14:21karolherbst: ohh no, got the assert no
14:23karolherbst: hakzsam: super fail :/ "shladd u32 $r0 $r0 $r63 $r36"
14:24hakzsam: looks like :)
14:24karolherbst: well kind of
14:24karolherbst: so, no 0x0 -> $r63 translation for shladd
14:25karolherbst: but this can be opted to "add u32 $r0 $r0 $r36" anyway
14:32karolherbst: is there any reason to convert an immediate 0x0 to $r63 anyway?
14:37karolherbst: ohhh, I see
14:40karolherbst: hakzsam: do you know which versions of mesa contain the shladd stuff? everything >=17.0?
14:40hakzsam: I think yeah
14:41karolherbst: 13.0 as well
14:42karolherbst: okay, so CC stable to 13.0, 17.0 and 17.1, fun
14:44karolherbst: hakzsam: how does the stable porting work? First in master then CC stable or can I just do it all at once?
14:44hakzsam: you have to add the cc tag in the commit message
14:46karolherbst: like "Cc: 17.0 <email@example.com>" and a new entry for each branch?
14:47hakzsam: "Cc: 13.0, 17.0" etc
14:49dboyan_: 0x0 -> $r63 reminds me of 0x1 -> $p7. I remember that our codegen doesn't handle pred constants like that very well
15:06Echelon9: I'll send a PR for GP108 identification support in envytools shortly
15:06karolherbst: hakzsam: can I post directly to the mesa-stable list or should I wait until the patch got reviewed and simply add the Cc tag for now?
15:06skeggsb: Echelon9: do you actually have a gp108?
15:07Echelon9: not as yet, however it looks fairly certain to launch. I'm also happy to wait until a copy of its vbios ends up on techpowerup or our repository
15:08skeggsb: yes, wait.. just because it's called GP108 doesn't mean it'll be 0x138
15:08karolherbst: allthough chances are high. Since Kepler nvidia became sane about this stuff
15:08karolherbst: (if we ignore tegra that is)
15:08Echelon9: fair enough (easy enough to tweak my written patch once it's confirmed)
15:09skeggsb: chances are high, yes.. but, there's numerous times we've been bitten by making that assumption :P
15:09karolherbst: :D, before my time (tm)
15:09hakzsam: karolherbst: you only to send the patch to mesa-dev with the cc tag
15:09karolherbst: hakzsam: okay
15:10Echelon9: I noticed there are missing pci-ids in envytools' docs, which I can work on updating now anyway
15:10karolherbst: why got it sent twice
15:12karolherbst: imirkin_: the second version is the good one, forget about the first
15:19hakzsam: karolherbst: can you show me the TGSI?
15:23karolherbst: hakzsam: https://gist.githubusercontent.com/karolherbst/62368ed56e0a93507c146e0ad2165445/raw/96cec698de18430e3d83664b6ce07f242dac64f2/gistfile1.txt
15:26karolherbst: okay, now how this shader dumping worked again...
15:26karolherbst: ahh, MESA_SHADER_CAPTURE_PATH
15:38karolherbst: nice, game seems to be playable though :)
15:38karolherbst: nearly even on 07 with my GPU
15:41karolherbst: now steam crashes
15:52hakzsam: I think it's more appropriate to do that
15:54karolherbst: why? it isn't
15:55karolherbst: or because that shl will be opted differently?
15:55hakzsam: it won't be optimized
15:55karolherbst: it is correct to do the opt
15:55karolherbst: it's just replceZero which sucks
15:55hakzsam: it's dumb to do it when src(1) is 0
15:56hakzsam: ie. (a << b) + c == a + c
15:56karolherbst: we could pimp the emiter too
15:56hakzsam: when b is 0
15:56karolherbst: but it's still is correct to do it
15:56hakzsam: the emitters are correct
15:56hakzsam: it's not wrong yeah
15:57hakzsam: but it avoids a hack in the replaceZero logic
15:57karolherbst: maybe we should just check for src1 == 1 and do a simple add?
15:57karolherbst: *src1 == 0
15:57hakzsam: this is what my patch does
15:57karolherbst: ohh, it falls back to opt shl(a, 0) to mov(a) later on?
15:59karolherbst: but it doesn't fix the crash entirely. I don't know how a shladd with src1 == 0 can happen elsewhere? The bug would still be there though
15:59hakzsam: can't happen
16:01hakzsam: SHLADD is only an optimization
16:02hakzsam: it can't be emitted directly from TGSI
16:02karolherbst: I see
16:08karolherbst: hakzsam: mhh, with your patch I get worse shaders
16:09hakzsam: you mean wuth shader-db?
16:09hakzsam: I didn't try to be honest
16:09karolherbst: I investirage
16:09hakzsam: can you show me the output?
16:09karolherbst: ..., yeah in a second
16:11karolherbst: "214: shl u32 %r1054 %r1048 0x00000000" in the final shader
16:12karolherbst: okay, I see no shl(a, 0) -> a opt
16:12hakzsam: but what about the shader-db results?
16:13hakzsam: maybe we are missing an optimization somewhere
16:13karolherbst: ? I just said. There is no shl(a, 0) to a opt and the shader-db results show something worse
16:13karolherbst: instead of shladd a 0x0 b it shows shl + add in the compiled shaders
16:14hakzsam: so yeah, this could be improved
16:15karolherbst: can shl have any mods or so?
16:15karolherbst: on src1?
16:15karolherbst: silly question
16:17karolherbst: now I get even better stuff
16:17karolherbst: looks wrong though? mhh od
16:18karolherbst: ohh no
16:18karolherbst: it's fine
16:18karolherbst: more stuff got folded in
16:18karolherbst: odd pattern
16:18karolherbst: shladd(a, 0, shladd)
16:18karolherbst: shladd(a, 0, shl)
16:18karolherbst: okay, nice
16:22karolherbst: hakzsam: https://github.com/karolherbst/mesa/commit/e167a5ebfc013b64d039753a3ac96760117e000e
16:22karolherbst: does this look fine to you?
16:28hakzsam: karolherbst: yeah, looks good
16:37hakzsam: btw, I have just added some gm107 sched code ideas to the trello board
16:37hakzsam: if someone is interested :)
16:43karolherbst: I will take care of Kepler first :p
16:43karolherbst: disappointing! "total instructions in shared programs : 4251497 -> 4251494 (-0.00%)"
16:43hakzsam: nice improvement :p
16:43karolherbst: 2 shaders
16:44hakzsam: did you run shader-db before/after my fix btw?
16:44karolherbst: with your fix
16:44karolherbst: ohh well
16:44karolherbst: before your fix it crashes
16:44karolherbst: I didn't bother
16:46karolherbst: I've uploaded the shaders by the way
16:46karolherbst: I think
16:46karolherbst: okay, now I've uploaded them
16:46hakzsam: the alient isolation ones?
16:47karolherbst: I even changed the video settings while dumping those
16:47hakzsam: I think I already have them in my private repo
16:48karolherbst: meh... right, I can't start steam anymore, and because of that I can't start the game anymore
16:48karolherbst: "dlerror(): /usr/lib32/libEGL.so.1: undefined symbol: gbm_bo_create_with_modifiers" *sigh*
16:49hakzsam: karolherbst: no need to add the nouveau ML btw
16:50karolherbst: I know. Would be nice though to do everything through Nouveau, so that I could stop mailman sending mails to me for mesa-dev
16:50hakzsam: add filters instead
16:50karolherbst: it's not about fioltering
16:51karolherbst: but my postbox getting full... and I am too lazy to delete those mails
16:51hakzsam: ah okay
16:51karolherbst: I am already at 6GB
16:51hakzsam: the worst ML I have is LLVM
16:51hakzsam: the traffic is crazy
16:51karolherbst: lkml would be something nice
16:51hakzsam: 32k unread mails :)
16:52karolherbst: mhh, but I am around that as well
16:54karolherbst: I just remove everything, why not
16:56karolherbst: hakzsam: anyway, it makes still sense. MAybe somebody really just wants to read the Nouveau mailing list and would get also all the mesa stuff. Dunno, as long as nobody minds I prefer it this way
17:24karolherbst: mhh, nice, the game is actually playable on very high settungs, ncie
19:11karolherbst: mupuf: I doubt that reator has an AGP slot?
19:22mupuf: karol would indeed rightly doubt
19:49karolherbst: hakzsam: did you add shladd to envydis?
19:49karolherbst: or does it have an odd name there?
19:50karolherbst: ohh, it is an add with special flags?
19:52karolherbst: I see, it is addop2
20:25karolherbst: hakzsam: does this look fine? https://github.com/karolherbst/mesa/commit/296c0ef3e7f887f9a590ce440f9acd479d3e01ef
22:27karolherbst: ohh right, hw can't do sqrt
22:28karolherbst: okay, but this looks super useless: "add ftz f32 $r0 $r0 0.000000"
22:31karolherbst: 192: mov u32 $r8 0x1fec1e4a
22:31karolherbst: 193: add ftz f32 $r0 $r0 $r8
22:32karolherbst: => 172: add ftz f32 $r0 $r0 0.000000
22:38karolherbst: mhh, it's 0.0000 in TGSI
22:39karolherbst: "r0.xyz = r0.xyz + vec3(9.99999968e-20f, 9.99999968e-20f, 9.99999968e-20f);" in glsl
22:39karolherbst: and because precision matters: they do this with it: "r0.xyz = mod_sat(r0.xyz * vec3(0.500000000f, 0.500000000f, 0.500000000f));"
22:41karolherbst: oh well fun
23:39karolherbst: mhh, this looks like some d3d conversion sillyness: r1.x = (r1.x != 0.0) ? float(1.00000000f)/r1.x : uintBitsToFloat(uint(0x70000000)) * sign(float(1.00000000f));