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