01:24 karolherbst: now I am wondering how I ended up with a "intrinsic load_var" allthough nothing seems to use it...
01:35 karolherbst: mhh, everybod lowers it away.. nice
01:38 karolherbst: well I will figure it out tomorrow
04:16 bjrohan: Hello all. i have a Dell xps with Nvidia 1050 card. I am running the nouveau driver I think, how can I tell if it is working, as I also have an Intel gpu that could also be rendering my desktop
04:19 imirkin: bjrohan: pastebin dmesg
04:19 imirkin: bjrohan: i believe people have had tons of issues with the recent crop of Dell XPS's btw
04:20 imirkin: [wrt getting nouveau working]
04:22 bjrohan: imirkin, https://dpaste.de/H0Dp
04:23 bjrohan: can't seem to get it to work with the nvidia drivrs as well using xorg (instead of the new wayland)
04:23 imirkin: bjrohan: there appears to be no mention of nouveau
04:24 imirkin: this leads me to believe that you're either running a kernel with nouveau, or you've built it as a module and then prevented the autoloader from loading it
04:24 imirkin: er, make that "a kernel without nouveau"
04:25 imirkin: [and you probably know this, but this chan is about nouveau, not blob driver -- if you need support for the latter, you'll have to go ... not here.]
04:28 bjrohan: imirkin, I'm working on getting a screenshot over. in Ubuntu software manager Additional I have the Nvidia as optons as well as noveau, of which I have the latter selected
04:28 bjrohan: How may I tell if it is kernel built-in
04:28 imirkin: based on your comments i'm guessing that you don't build your own kernel?
04:29 imirkin: if you're using a distro kernel, it is most probable that nouveau is built as a module
04:29 bjrohan: nope :-)
04:29 perfinion: imirkin: dunno if you got my updates about the 7900GT, setting AccelMethod none made it work, but kernel 4.1[234] made not no difference with the crashes
04:29 imirkin: if you at one point had nvidia drivers installed, it is probably they added something to prevent loading of nouveau to your config
04:29 imirkin: which you have not un-done
04:29 bjrohan: Gotcha. So to get the Nvidia to work, would need to disable nouveau?
04:29 imirkin: can't have 2 drivers drive the same hw
04:30 bjrohan: makes sense
04:30 imirkin: perfinion: yeah, i saw your comments. makes sense that disabling accel would "fix" your issues
04:30 imirkin: perfinion: the question is ... why is accel fubar'd
04:30 perfinion: imirkin: hehe yeah, it "works" for now, turning off compositing in xfce is kinda required tho lol
04:31 imirkin: bjrohan: not sure what you're trying to achieve, but i think that as an end user you want nothing to do with nouveau on a mobile GTX 1050, except if you plan on never using it and just want to use nouveau to power it off.
04:32 bjrohan: OK
04:32 imirkin: bjrohan: and think of AMD for your next purchase :)
04:32 perfinion: imirkin: weirdly, NoAccel yes vs commented out made no diff, only the AccelMethod none vs exa
04:32 imirkin: perfinion: hmm.... iirc NoAccel should work
04:32 imirkin: perhaps we broke it when messing around with the AccelMethod thing?
04:32 perfinion: i wouldh ave thought so
04:33 perfinion: i assumed NoAccel means nothing at all, so it would override AccelMethod no matter what
04:34 perfinion: is there any other type of accel other than exa i could try? whats the whole gallium stuff?
04:35 perfinion: or glamor maybe
04:36 imirkin: glamor was an attempt to integrate glamor into nouveau as an accel backend. the attempt was backed out.
04:37 imirkin: gallium is a driver framework (internal to mesa) for writing GL (and other API) drivers
04:37 perfinion: ah right, i mixed the two up then
04:37 imirkin: [rather, glamor is an implementation of a lot of the internal X api's with the use of OpenGL]
04:38 perfinion: the nouveau man page mentions glamor under the DRI option, but AccelMethod only mentions none or exa
04:39 imirkin: thanks for mentioning
04:40 imirkin: i probably just grepped for 'GLAMOR' when removing it
04:41 imirkin: perfinion: if you want a reported-by in the commit, pm me your name/email so i can include it
04:41 imirkin: if not, i can just push out without that
04:47 perfinion: imirkin: so for the accel stuff, if you do happen to need testing i'd be up for it, but i dont really care all that much so no need to put it high on your priorities
04:47 perfinion: its an ancient card anyway
04:48 imirkin: perfinion: yeah ... i mean it should work. no idea why it doesn't.
04:48 imirkin: perfinion: i can always blame the MSI boogey-man
04:48 imirkin: i like to blame things i don't properly understand
04:48 perfinion: hehe
04:48 imirkin: have i already had you try disabling msi? boot with nouveau.config=NvMSI=0
04:48 perfinion: ive not tried that
04:48 perfinion: just put on the kernel cmdline?
04:48 imirkin: yea
04:49 imirkin: (or set the config=... as an option when loading the nouveau module)
04:49 perfinion: i can do that next time i reboot then
04:52 perfinion: "options nouveau config=NvMSI=0" in /etc/modprobe.d?
04:52 imirkin: yeah. well presumably in a *file* in there, but yes
04:53 imirkin: i'd advise against echoing that into the directory inode
04:54 perfinion: imirkin: alternatively, the thing seems like some color issue, is there a way to drop it to a lower color depth?
04:54 perfinion: heh yeah i meant a file ;)
04:55 imirkin: mmmm ... are you trying to do 30bpp?
04:55 imirkin: the most tested is 24bpp
04:55 perfinion: i have no idea tbh
04:55 perfinion: i havent set anything manually
04:55 imirkin: yeah, so 24. pretty much nothing works at 30
04:56 imirkin: we (i.e. open-source graphics devs) are just starting to look into making that workable
04:56 imirkin: with the semi-recent availability of mass-market "deep-color" screens
04:56 perfinion: would dropping to 16 be worth a shot? or ugly colors not worth it? :P
04:56 imirkin: would be *very* unlikely to help
04:56 imirkin: and much more likely to hurt
04:56 perfinion: okay
09:40 sphalerite: Is it possible to run nouveau and nvidia simultaneously, one for each card, on a system with two identical GPUs?
09:40 gnarface: now that's a good question
09:41 gnarface: i'd bet the answer is no, but i'm curious
09:48 karolherbst: sphalerite: interesting idea
09:48 karolherbst: sphalerite: I think in theory it might be possible
09:49 karolherbst: but nvidia also tries to detect nouveau and possibly unload it
09:49 gnarface: i think you might have to disable KMS?
09:50 sphalerite: wasn't mind to be perfectly fair, someone else asked in another channel (because they want a full-resolution tty at the same time as running X with nvidia)
09:50 sphalerite: I don't think nouveau (or high-res tty) works without KMS?
09:50 gnarface: well, specifically high-res tty doesn't work with the nvidia official drivers
09:51 gnarface: i'm not sure if KMS is the only way to do it anymore, but it is the new way to do it
09:51 sphalerite: yeah, that's why the person who gave me this idea wants to use both nouveau and nvidia
09:51 karolherbst: sphalerite: yeah, basically every open driver uses KMS nowadays
09:52 karolherbst: sphalerite: well, the easier way is to have an intel GPU on the CPU
09:52 karolherbst: than to have like two nvidia GPUs
09:53 sphalerite: yeah, someone else suggested that on the other channel and that would make sense if possible
09:53 sphalerite: Still curious if nouveau and nvidia could coexist though :)
09:53 karolherbst: well, I think nvidia tries hard enough to bail out if it detects nouveau, no idea what nvidia does if let say nouveau only uses one GPU
09:54 gnarface: even before kms, various framebuffer drivers could set a high-res virtual terminal, and nvidia's drivers were allergic to all those too though, just for the record
09:54 karolherbst: is there a reason why nvidia never implemented high-res ttys?
09:54 gnarface: a big f-you to nerds?
09:55 karolherbst: well there are nerds at nvidia as well
09:55 karolherbst: and I am sure some nvidia dev would just implement it, because why not
09:56 karolherbst: or maybe there are too big nerds and say that fancy high-res terminals are fancy new stuff nobody needs?
09:56 karolherbst: whatever it is, I am sure there is a reason for it
09:58 gnarface: well they don't actually develop ON linux, do they?
09:58 gnarface: i'm sure it's an irrelevant concern in Windows
09:59 gnarface: to them, it'd just be some dumb extra useless thing that only Linux users care about
10:03 karolherbst: imirkin: nouveau is pretty much broken on every newer dell XPS
10:03 karolherbst: like really broken
10:39 karolherbst: are all uniforms stored in c0 space in Nouveau?
10:39 karolherbst: pmoreau: do you know something about how I can know where an uniform is stored?
10:39 karolherbst: ohh, I think I know
10:40 karolherbst: I think the nir already tells me, nice
12:09 pmoreau: karolherbst: No clue, sorry
12:10 karolherbst: pmoreau: okay, then I assume it is like with TGSI and I will make the code produce loads that fit this
12:12 karolherbst: pmoreau: it is kind of fun working with nir, because you can push a lot of the stuff into scalar form and forget about most of the vector stuff :)
12:36 karolherbst: pmoreau: do you know if we can merge 4 regs to a b128 value?
12:38 pmoreau: There are definitely 128-bit loads instructions, so the hardware can do it. I think Nouveau supports it, as it has a TYPE_B128 IIRC.
12:38 karolherbst: yeah, I was more asking like can we do it on input and add merges there already?
12:39 karolherbst: in the nir I have this: "vec4 32 ssa_75 = vec4 ssa_19, ssa_10, ssa_20, ssa_21"
12:39 karolherbst: which basically means create a vec4 value out of the 4 sources
12:39 karolherbst: which is basically wha OP_MERGE does
12:39 karolherbst: *what
12:40 karolherbst: and later on I get this: intrinsic store_output (ssa_75, ssa_18) () (0, 15, 0) /* base=0 */ /* wrmask=xyzw */ /* component=0 */ /* gl_FragColor */
12:40 karolherbst: ssa_18 is 0, but no idea what that means right now
12:41 karolherbst: uhm
12:41 karolherbst: it means gl_FragColor...
12:41 karolherbst: I think
12:42 karolherbst: ohh, from_tgsi also uses merges, so it should be fine I guess
13:43 karolherbst: pmoreau: in nir sources can actually have modifiers on them... this will get a bit annoying, but shall be fine I guess
13:43 karolherbst: I mean live would be much easier if we could just fold them in, but I think we shouldn't do that for now
14:09 imirkin: normally you should let the MemoryOpt pass join stuff together
14:09 imirkin: i'd avoid fanciness on input into the ir
14:09 imirkin: remember - you're feeding stuff into an optimizing compiler
14:11 karolherbst: yeah, I know
14:12 karolherbst: just wondering if we might fix up some places to be able to deal with that
14:12 karolherbst: we might want to do that anyway if we want to allow opts to be run multiple times
14:12 karolherbst: with random input basically
14:12 karolherbst: for now I would just lower OP_ABS and OP_NEG in such cases
14:12 karolherbst: *to
14:14 karolherbst: imirkin: a type OP_MOV only makes sense for debugging and immediates, right?
14:14 karolherbst: *typed
14:16 imirkin: correct
14:16 imirkin: same with OP_PHI
14:17 karolherbst: yeah, I kind of hope I won't have to handle OP_PHIs here.... but I kind of get the feeling I will
14:17 imirkin: you shouldn't
14:17 karolherbst: I know
14:17 imirkin: see the email i sent you
14:18 karolherbst: to my old/private address?
14:21 karolherbst: okay, got it
14:30 karolherbst: imirkin: radeonsi doesn't seem to use from_ssa though... I currently follow what vc4 and freedreno does and it works out quite well
14:30 karolherbst: I already do those things though, except maybe nir_index_ssa_defs, but I will have to see how usefull this turns out to be
14:31 imirkin: ok, fine, don't do it the way i suggested
14:31 imirkin: but then don't complain to me about how it's SSA and it doesn't work :)
14:31 karolherbst: well, I already call from_ssa ;)
14:32 imirkin: just make sure that phi's are lowered by the time you see it
14:32 karolherbst: yeah
14:33 karolherbst: it is still nice to do the partial from_ssa, where you have all those ssa values and don't need to care about registers or order or anything like this. But still without phi nodes.
14:33 karolherbst: otherwise you will have both
14:33 karolherbst: ssa values and regs...
14:33 karolherbst: still no phi nodes though
14:33 imirkin: welll ... once you don't have phi nodes, you don't have ssa.
14:33 imirkin: so you need to index the "ssa" defs
14:33 imirkin: so that you know which thing is which.
14:34 karolherbst: yeah
14:34 karolherbst: they have an index field
14:34 karolherbst: I already do all that
14:34 karolherbst: I am basically one instruction away from my first frag shader, which does a few max calls
14:34 karolherbst: only need to write into gl_FragColor now
14:35 karolherbst: I think I got that load_uniform wrong, but... vc4 and freedreno seems to do different things and my output was more like what freedreno expects...
14:36 karolherbst: but I think I could even skip this indexing thing, because all the src/dest use the same nir_ssa_def* value in the end
14:37 karolherbst: so I could just build a map of nir_ssa_def->LValues*
14:37 karolherbst: but as I said, even if I do a full from_ssa, some SSA values were still there... I am sure I just use it wrong or maybe that is intentional
14:41 karolherbst: fun, nir explicitly exports outputs of fragment shaders
14:42 karolherbst: mhh, actually TGSI as well
14:42 karolherbst: why do we have that exportOutputs() function then?
14:42 imirkin: because tgsi is annoying.
14:42 karolherbst: ahh
14:42 karolherbst: I see
14:42 imirkin: oh, but i think the depth clamping thing has to happen no matter what
14:42 karolherbst: MOV OUT[0], TEMP[0] putting it in there would be annoying I assume
14:43 imirkin: well the issue is that OUT[0] gets written multiple times and read as well
14:43 imirkin: so one needs to put a "buffer" in between them
14:43 karolherbst: imirkin: I will come to it when I run into the issue :) currently I just want that tests/spec/glsl-1.10/execution/fs-max-max-max.shader_test passes
14:43 karolherbst: ohhh
14:43 karolherbst: I see
14:44 karolherbst: in nir I get "intrinsic store_output (ssa_11, ssa_12) () (0, 15, 0) /* base=0 */ /* wrmask=xyzw */ /* component=0 */ /* gl_FragColor */" :)
14:44 imirkin: when you run into the issue, it won't be so obvious you forgot to implement that one bit of it
14:44 imirkin: it took me a lot of debugging to figure that out
14:44 karolherbst: I will take a note then
14:44 karolherbst: thanks
15:05 karolherbst: imirkin: is there a problem if the exports are not in the BB with the ret?
15:05 karolherbst: other than that, the shader result is the same as with TGSI
15:06 imirkin: no
15:06 imirkin: as long as they happen.
15:06 karolherbst: nice :)
15:06 karolherbst: now I have to fix the vertex shader
15:21 karolherbst: imirkin: mhh, how do I know that I have to read the vertex input from a[0x80] and not from a[0x0]?
15:21 karolherbst: or is there a static offset of 0x80?
15:22 karolherbst: ahh
15:22 karolherbst: info->prop.cp.inputOffset
15:26 karolherbst: ohh wait, that is just for compute shader
15:27 karolherbst: info->in[idx].slot[c] it is
16:42 karolherbst: nice... we are having TGSI depended code outside codegen
16:43 karolherbst: imirkin: what do you say should we do about assignSlots? there are a lot of TGSI checks in there. I could just pass TGSI values down, or would you prefer to add an abstraction layer?
16:45 karolherbst: mhh, but that code isn't that complicated, so maybe I just do a nir version and leave it inside from_nir
17:31 karolherbst: imirkin: mhhh. both shaders are the same now, but still no output. I guess depth clamping?
17:44 karolherbst: oh no, it was just the masks of the vp input/outputs
17:44 karolherbst: nice
17:44 karolherbst: tests/spec/glsl-1.10/execution/fs-max-max-max.shader_test: PASS :)
20:33 tobijk: karolherbst: didnt you fix temp reporting for newer hw generations? i had mine report 551°C a while today :D
20:41 karolherbst: tobijk: yeah, ping skeggsb about it and tell him he should take a look at those patches :p
20:42 tobijk: karolherbst: ah they did not yet get merged? nvm then
20:42 karolherbst: tobijk: I think this might be a regression done by the hwmon rework
20:43 tobijk: mhm, will see if i can repro somehow...
21:21 karolherbst: imirkin: can we use varyings in fragment shaders? and if not, could we support it or would i be quite some work for no real benefit?
21:22 karolherbst: *it
22:12 karolherbst: mhh, now I have to care about swizzling and writemask...
22:35 mjg59: ~/
23:19 Exagone313: Hi, since I updated the kernel and/or mesa (I don't know, exactly, and I just think it's caused by this), nouveau randomly crashes (meaning, screen is frozen, sometimes mouse not, keyboard seems ignored - can't go in tty - music does not stop) and I have to reboot via ssh... I'm on Arch Linux, linux 4.14.4, mesa 17.2.6, xf86 nouveau 1.0.15, GTX 960 (NV126). Here is a log of what I get when it happens: https://bpaste.net/raw/0ab6289fe622 What do you think
23:19 Exagone313: about it? Thanks for your help.
23:53 karolherbst: imirkin: I can't do a bra based on a float boolean value. can I simply convert it into a predicate or what would be a super smart thing to do here?
23:53 karolherbst: I kind of don't want to use selp.... but if it
23:53 karolherbst: 's the only way, I would use selp
23:54 karolherbst: Exagone313: well, you could try out an older kernel and/or mesa
23:55 Exagone313: yeah probably
23:56 karolherbst: ohh wait, I can do a bra based on a reg :O
23:56 Exagone313: but I can't trigger the thing
23:56 Exagone313: maybe it'll fix magically in a next update :3
23:57 karolherbst: Exagone313: I doubt it