01:26 rhyskidd: karolherbst: i took a look and all major distros handle cython3 reasonably well (well, no worse than the general python/python2/python3 mess)
01:26 rhyskidd: Fedora appeared to be last some time ~2012
01:27 rhyskidd: not a slight on the RH team, just it looks clear to make cython3 the *actual* requirement
01:28 rhyskidd: mwk: came across your old uses of nvapy again for re'ing scalar and vector instructions
01:28 rhyskidd: nice stuff
10:04 pmoreau: karolherbst: As of when? I did a rebase on master yesterday evening, as there was some issues with the latest header files when running the test suite.
10:06 karolherbst: mhh
10:06 karolherbst: I have your changes
10:06 karolherbst: pmoreau: for_nouveau branch, right?
10:06 pmoreau: And when I compiled yesterday it worked fine.
10:06 pmoreau: Yeah
10:07 pmoreau: (which is currently the same as master)
10:09 karolherbst: I get this error: "../source/latest_version_spirv_header.h:18:10: fatal error: spirv/unified1/spirv.h: No such file or directory"
10:09 pmoreau: Have you updated the SPIR-V headers?
10:10 karolherbst: I doubt it
10:10 pmoreau: Try updating it, that should give you the unified headers
10:12 karolherbst: okay
10:14 karolherbst: *sigh* that build system is a little broken though
10:15 karolherbst: pmoreau: it doesn't use my non system installed headers ....
10:15 pmoreau: :/
10:15 karolherbst: I even set the install prefix
10:16 pmoreau: Install prefix of what?
10:16 karolherbst: the build
10:16 karolherbst: had to add "CMAKE_CXX_FLAGS=-I/home/kherbst/local/include"
10:16 karolherbst: ...
10:17 pmoreau: I usually just have my SPIR-V headers cloned in SPIRV-Tools/external/, and that works just fine.
10:19 pmoreau: Try defining: SPIRV-Headers_SOURCE_DIR to the location of your SPIR-V headers instead
10:20 pmoreau: (Well, SPIRV-Headers_SOURCE_DIR should contain an include folder, which contains those headers)
10:20 karolherbst: it doesn
10:20 karolherbst: 't check for the dep
10:20 karolherbst: ohh
10:20 pmoreau: https://github.com/KhronosGroup/SPIRV-Tools/blob/master/external/CMakeLists.txt#L16
10:20 karolherbst: static value
10:20 karolherbst: a bit annoying
10:20 karolherbst: huh
10:20 karolherbst: well
10:20 karolherbst: it didn't work
10:20 karolherbst: the else branch
10:20 karolherbst: ohh, old embedded stuff
10:21 karolherbst: right
10:21 pmoreau: Oops, gonna run! I didn’t thought it was already 11:20. Ttyl
10:46 marisn: I have hit by a serious regression between kernels 4.14 and 4.15 (NV98; screen corruption, lockups)
10:47 marisn: still I can not find source for bisect'ing as Nouveau wiki and main page point to repo with 4.4.0
11:02 karolherbst: pmoreau: do you know if OP_PINTERP can have an indirect?
11:04 karolherbst: apperantly it can
11:14 karolherbst: mupuf: I have a GPU here where we don't report the fan speed
11:14 karolherbst: a GK208
11:15 mupuf: karolherbst: is the GPIO listed in the bios?
11:16 karolherbst: oh wow
11:16 karolherbst: and it boots with a higher voltage than 0xf needs
11:18 karolherbst: mupuf: I will check
11:23 mupuf: karolherbst: lol
11:23 karolherbst: mupuf: well to be fair, it uses 1.01V on 0xf
11:26 karolherbst: also, nvalist: "0: (pci) 0000:01:00.0 ??? b17060b0"
11:27 karolherbst: mupuf: GPIO 16: line 16 tag 0x09 [FAN_PWM] OUT NEG DEF 0 SW gpio: normal SPEC_OUT 0x5e [???]
11:28 karolherbst: oh wow
11:28 karolherbst: mupuf: from the maxwell GPU: https://gist.github.com/karolherbst/2245f3e9962f740a8cac4a01ceaae226
11:29 mupuf: karolherbst: that is not the tachyometer GPIO, that's the PWM output
11:29 karolherbst: ahh
11:29 karolherbst: yeah, there is no tachyometer
11:30 mupuf: karolherbst: then no fan speed, sorry
11:30 karolherbst: well you say that
11:30 karolherbst: but
11:30 karolherbst: mhh
11:30 karolherbst: there is not even the duty -> rpm table
11:33 karolherbst: mupuf: oh wow, that kepler GPU is really something
11:33 karolherbst: highest cstate volt entry has a max volt of 1062500
11:33 mupuf: karolherbst: where is that duty -> rpm table?
11:33 karolherbst: I called it FAN_MGMT
11:33 mupuf: ah
11:34 mupuf: well, it is not exactly life-critical really
11:36 karolherbst: mupuf: not really
11:40 pmoreau: marisn: The master branch isn’t up-to-date (on https://github.com/skeggsb/linux/ which is the repo linked from the Nouveau wiki), but there are also linux-4.16, linux-4.15 etc. branches, which are definitely more up-to-date.
11:43 marisn: pmoreau: thanks. I'll try then 4.16 branch
11:49 pmoreau: I guess INTERP is for interpolation, but what is the first P for? Perspective?
11:57 karolherbst: pmoreau: nice idea? maybe?
11:58 karolherbst: *no
12:01 karolherbst: mupuf: ohh by the way, if somebody wants to play around with SLI, I have two identical G86 GPUs
12:01 karolherbst: *G84
12:11 mupuf: karolherbst: I wonder who would have time for SLI
12:12 karolherbst: no clue
12:12 karolherbst: nobody ever?
12:12 mupuf: karolherbst: we'll see, but there is no point until reclocking works
12:12 mupuf: and the driver is somewhat optimised
12:12 karolherbst: mupuf: didn't you have a 690?
12:12 mupuf: but honestly, I would say this will never be the case
12:12 mupuf: I do
12:12 karolherbst: or still have?
12:13 karolherbst: this is also a MSI card, right?
12:13 mupuf: no idea
12:13 karolherbst: well
12:13 karolherbst: it has 2 cores
12:13 mupuf: but it is a SLI board, yes
12:13 karolherbst: so yeah, reclocking works on that one
12:14 karolherbst: mhh
12:14 karolherbst: let me check something
12:14 karolherbst: mupuf: did you add the vbios of the 690?
12:14 mupuf: I think so
12:14 mupuf: but I extracted the vbios of only one gpu
12:14 karolherbst: ohh
12:15 karolherbst: I see
12:15 karolherbst: it doesn't have lower clocks for SLI...
12:15 karolherbst: which would have made actually sense
12:15 mupuf: not sure I follow your logic :)
12:15 karolherbst: well
12:16 karolherbst: you have one cooling system for both chips
12:16 mupuf: ok, I thought you mean the plevel 0 would have a lower value on SLI
12:16 mupuf: yes, makes sense now :)
12:16 karolherbst: :)
12:16 mupuf: well, I guess they can pick the best parts for these SLI boards
12:16 mupuf: and they would require a lower voltage
12:16 karolherbst: i915 is so broken on the 8700 :(
12:17 karolherbst: at least with 4.15
12:17 mupuf: 8700? really? :o
12:17 karolherbst: :p
12:17 karolherbst: why not?
12:17 mupuf: let's talk about it on #intel-gf
12:17 mupuf: x
12:17 mupuf: well, that's a super recent cpu/gpu
12:17 karolherbst: yeah
12:18 karolherbst: mupuf: but it was like 20€ more than a 7700
12:18 karolherbst: so....
12:20 mupuf: sure, good that you went for it, but still, it is odd that you would have issues
14:27 karolherbst: nice
14:27 karolherbst: homebrew guys were able to run Linux on the switch
14:28 karolherbst: with 3d acceleration using nouveau :3
14:33 mupuf: karolherbst: looking forward to the patches :p
14:33 karolherbst: :)
14:33 mupuf: or should I? :D
14:33 karolherbst: :D what should you?
14:37 karolherbst: ohh
14:37 karolherbst: I see
14:38 karolherbst: mupuf: I don't think they have any patches
14:38 karolherbst: why would they?
14:38 mupuf: I they probably had to
14:38 mupuf: it is tegra-based, isn't it?
14:38 mupuf: so, where are all the parameters?
14:38 karolherbst: well
14:38 karolherbst: it is tegra
14:38 mupuf: there is at least a device tree necessary
14:39 karolherbst: it is basically tegra just cheaper :D
14:39 mupuf: but what I meant is that do I really want to see hacks ;)
14:39 karolherbst: :D
14:39 karolherbst: right
14:39 karolherbst: but I doubt they had to touch the nouveau source
14:39 karolherbst: it is just a Tegra X1 in the end
14:39 mupuf: that was just a little sarcasm, I actually would like to see the patches
14:40 mupuf: yeah
14:40 karolherbst: well I talked with them on 34c3 :)
14:40 karolherbst: and I suggested them to just run Linux and use Nouveau :D
14:40 karolherbst: *to
14:41 mupuf: good that it worked out :)
14:41 karolherbst: and told them to maybe work on a gallium state tracker for the graphics API or something
14:41 karolherbst: which would be kind of cool to have
14:42 karolherbst: the API seems to be like OpenGL with removed validation and stuff
14:45 mupuf: well, if opengl is a superset, then there isn't much to do indeed
14:45 mupuf: well, that could indeed be fun to run games on this platform
14:45 freecoder: hi all. i was looking at gsoc 2018 project ideas (https://www.x.org/wiki/SummerOfCodeIdeas/). for the nouveau projects, it is okay if i have a notebook gpu (dont own a desktop yet)?
14:46 karolherbst: mupuf: well, they ran glxspheres :)
14:46 karolherbst: mupuf: but, the API is totally custom, it just had weirdo names like commandStreamDrawArraysInstanced
14:46 karolherbst: which is totally weird
14:48 karolherbst: or command buffer or something
14:48 karolherbst: but then you have all those OpenGL function names
14:48 karolherbst: mupuf: at first they though it was some vulkan like API
14:48 karolherbst: freecoder: yes, it is
14:51 karolherbst: freecoder: do you already have some topic in mind?
14:52 freecoder: karolherbst: i was thinking of working on outstanding reclocking issues on reclockable gpus
14:52 karolherbst: freecoder: what GPU do you have?
14:53 freecoder: geforce 820M (think its a gf117)
14:53 karolherbst: yeah, sounds about right
14:53 karolherbst: mhh
14:53 imirkin: freecoder: lspci -nn -d 10de:
14:53 karolherbst: well
14:53 karolherbst: freecoder: there is no reclocking support on those yet
14:53 karolherbst: but
14:53 karolherbst: ping skeggsb
14:53 karolherbst: he will likely like your GPU
14:54 imirkin: GF117 is a laptop-only gpu, so a bit of a pain to access through regular means
14:54 karolherbst: GF117 seems to be some mobile only chip
14:54 imirkin: it's lacking a display unit, which makes it special
14:54 freecoder: karolherbst: yeah the command imirkin gave shows gf117m
14:55 freecoder: karolherbst: thanks i will ping skeggsb and see
14:56 karolherbst: freecoder: thing is, that the reclocking suppor thing might be not really suiteable for laptops
14:56 karolherbst: because on mobile GPUs we usually don't have any severe outstanding issues
14:56 karolherbst: normally
14:56 freecoder: ok
14:57 karolherbst: and the remaining issues there are usually way too small
14:59 freecoder: karolherbst: alright. are there any other ideas which i can work on with gf117m in mind?
14:59 karolherbst: freecoder: well depends on what you are interested in
14:59 karolherbst: there is always compiler work to be done
15:00 karolherbst: "performance analysis on frameretracer" would be also a fun thing
15:00 freecoder: karolherbst: frametracer thing mentions "tesla or newer" as requirements
15:00 karolherbst: right
15:01 karolherbst: Tesla -> Fermi -> Kepler -> Maxwell -> Pascal
15:01 freecoder: ah. i always thought fermi was the oldest :D
15:01 karolherbst: well
15:01 karolherbst: there are older gens than Tesla
15:01 karolherbst: even
15:07 freecoder: karolherbst: cool! so i look into the frametracer idea. meanwhile, is there any small task/bug-fix that i can pick up to get familiar with the codebase?
15:08 karolherbst: freecoder: are you aware of some issues on your GPU?
15:08 karolherbst: maybe some missrendering or something?
15:08 karolherbst: games crashing, whatever?
15:09 freecoder: karolherbst: no, not as such.
15:11 mupuf: freecoder: well, there is not-so trivial work that needs to happen to get most performance counters exposed
15:11 mupuf: the kernel support is done, but not the mesa part
15:11 mupuf: hakzsam wrote all of this
15:11 mupuf: maybe he could brief you on this
15:12 mupuf: but otherwise, just being able to see the current performance counters on frameretracer would be great
15:13 rhyskidd: freecoder: when I was starting with nouveau, I found dumping my cards vbios through envytools/nvbios was a good overview
15:13 rhyskidd: helps mapping abstract concepts like falcons and GPIOs to specific features of your card
15:13 freecoder: mupuf: sounds good. i will start looking into it. will get in touch with hakzsam when he's available
15:14 rhyskidd: (and then look for missing info, and add that from the documentation that is out there...)
15:15 freecoder: rhyskidd: umm ok. will need to do some digging for the vbios stuff. seems like a good exercise to get started :)
15:18 mupuf: freecoder: well, there is plenty to do on Nouveau, but the GSoC is close, so I would suggest concentrating on what you want to work on and understand the vertical
15:18 imirkin: freecoder: i need some patches tested on fermi
15:18 mupuf: in your case, this means mostly performance counter's HW and software interfaces
15:19 imirkin: it would be a good way to become familiar with setting up a custom mesa, and the test suites
15:19 freecoder: mupuf: ok
15:19 imirkin: (and it'd help me... not that i'm biased.)
15:20 mupuf: imirkin: sounds like a good start
15:21 imirkin: freecoder: patch at https://patchwork.freedesktop.org/patch/202553/
15:21 imirkin: the test in question is part of VK-GL-CTS
15:21 karolherbst: imirkin: ohh right, I should have bought a Fermi GPU...
15:22 karolherbst: imirkin: if there is a Fermi GPU you want to have, is there something special? Because then I would add it to my list for when I buy more
15:23 imirkin: they're all the same(ish)
15:23 imirkin: GF119/GF108 will be cheapest
15:23 karolherbst: okay
15:25 freecoder: imirkin: got disconnected. what were you saying about the patches?
15:25 imirkin: check backlog.
15:25 imirkin: (see title)
15:26 imirkin: fuck. gtg. see ya.
16:25 rhyskidd: any comments on https://github.com/envytools/envytools/pull/119 before I merge it to master?
16:25 rhyskidd: whole bunch of DCB 4.1 GPIO tags that were missing in the vbios parsing code
16:31 mupuf: rhyskidd: wow, thanks for doing this :)
16:31 mupuf: looks good to me
16:31 rhyskidd: i have a second patch, which *corrects* or renames a few that we appeared to have wrong
16:31 rhyskidd: nothing major
16:31 mupuf: yeah, good that you split it
16:31 rhyskidd: but I wanted to get the new tags in separately, so any renames are more easily found in git history
16:32 mupuf: good on you, indeed :)
16:33 rhyskidd: great, i'll merge it
16:38 fireant: hi,
16:39 fireant: so what to do with this:
16:39 fireant: /usr/lib64/libxcb-dri3.so.0: undefined symbol: xcb_send_request_with_fds
16:40 pmoreau: According to Google, one solution is to not use DRI3: https://wiki.archlinux.org/index.php/Steam/Troubleshooting#Symbol_lookup_error_using_DRI3
16:42 fireant: I've tried to set LIBGL_DRI3_DISABLE=1 it did not work, is there any other way to disable not needed dri3
16:42 fireant: ?
16:42 pmoreau: There seems to be more information over there: https://github.com/ValveSoftware/steam-for-linux/issues/4816
16:44 pmoreau: Apparently the beta channel has an updated libxcb.so.1, no clue when it will be part of a release.
17:12 freecoder: the "Dumping Video BIOS" wiki page says i need to "cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom". my dri/0/ directory does not contain a vbios.rom file. how do i proceed?
17:13 imirkin_: try /1/
17:13 freecoder: ah. its there in /1/
17:14 imirkin_: you have multiple gpu's
17:14 imirkin_: so the id's won't always match up
17:18 freecoder: imirkin_: ah. i see i915 files in /0/ so maybe thats taken up by intel?
17:21 imirkin_: quite likely.
17:22 fireant: I've set -dri3 and now recompiling mesa xcb then I'll tell you if this worked
17:26 pmoreau: fireant: Make sure that Steam is using your recompiled xcb, and not the one it is shipped with.
17:27 pmoreau: Have you tried removing the libxcb that Steam comes with, to force it to use the system one, as suggested by multiple users on that issue?
17:28 fireant: yes its actually bitwig-studio not steam but problem is the same
17:29 fireant: anyway 0ad fails too
17:29 fireant: but glgears work ok
17:35 pmoreau: Ah, okay
19:37 karolherbst: *sigh* I found a more or less severe issue in my nir pass I didn't encounter before https://gist.githubusercontent.com/karolherbst/0732706888c3b29f572ffdf051e7007e/raw/88bcd57cdc5ed3558a50adf2eafe3d772878d199/gistfile1.txt
19:37 karolherbst: those inputs are weirdly overlapping
21:18 pmoreau: Phew, did manage to get access back to my server. It seems that compiling LLVM has been bringing it down to its knees (and made it swap a lot!).
21:19 imirkin_: karolherbst: i think there's an implicit vec4-ness to it
21:19 imirkin_: i.e. float[4] a means var0.y, var1.y, var2.y, etc
21:20 karolherbst: right
21:20 karolherbst: and that's why this part doesn't make sense: (VARYING_SLOT_VAR2.x, 1, 0)
21:20 imirkin_: this can happen with ARB_enhanced_layouts
21:20 imirkin_: hm?
21:21 karolherbst: float[4] a (VARYING_SLOT_VAR0.y, 0, 0)
21:21 imirkin_: right.
21:21 karolherbst: a[2] would be VARYING_SLOT_VAR0.y, which would be at driver_location 2
21:21 karolherbst: *VARYING_SLOT_VAR2
21:21 imirkin_: right.
21:21 karolherbst: and d is VARYING_SLOT_VAR2, but at driver_location 1
21:22 imirkin_: oh. i dunno nothing about that driver location thing ;)
21:22 karolherbst: driver_location is what I use for info->in[driver_location] and info->out[driver_location]
21:22 imirkin_: the VARYING_SLOT stuff makes sense.
21:22 karolherbst: it usually works
21:22 karolherbst: but not here
21:22 karolherbst: fun fact
21:22 imirkin_: everything else is "i dunno" :)
21:22 karolherbst: if the arrays are splitted, it works again
21:23 karolherbst: https://gist.githubusercontent.com/karolherbst/caef9646d5781526a7db69607af70649/raw/eb0b4b103b3e465817c74f6cb953594d0543033c/gistfile1.txt
21:23 karolherbst: but here some packening happened
21:23 karolherbst: (the disadvantage of the latter is, that nir uses local arrays, the former allows us to use indirect load_inputs)
21:56 pmoreau: karolherbst: ... You did have llvm-spirv working to mark builtins as Input rather than UniformConstant! :-p
21:57 pmoreau: The issue now is getting clover to accept it
22:10 pmoreau: karolherbst: Take the two top most commits of https://github.com/pierremoreau/llvm-spirv/commits/integrate_with_mesa for the llvm-spirv part, and the top most commit of https://github.com/pierremoreau/mesa/commits/nouveau_spirv_support for the Mesa part.
22:13 pmoreau: That should give you a SPIR-V binary, which passed through clover, where builtins use the Input storage class. If it still doesn’t work, then it most likely something wrong with the spirv_to_nir code.
22:15 annadane: i don't suppose nouveau has a rating system like wine has for games, how well certain hardware works on nouveau?
22:16 karolherbst: pmoreau: interesting
22:16 karolherbst: annadane: I had the idea to do that at some point
22:16 imirkin_: annadane: sure we do. function rating(game) { return 0; }
22:16 karolherbst: annadane: but if you want to work on that, please feel free to :p
22:16 annadane: every time i've tried using nouveau with my hardware and kde plasma i've gotten freezes but apparently some people run plasma just fine and it's been suggested it's because my hardware is new
22:17 karolherbst: mhh
22:17 imirkin_: nah, tons of people have issues with plasma
22:17 karolherbst: there are issues and nobody really got to fix it
22:17 annadane: it's very frustrating how nvidia refuses to help you guys
22:18 imirkin_: there are a lot of interrelated problems
22:18 imirkin_: shitty driver, lack of manpower, lack of ability to do things due to hw lockdown, lack of docs. they all reinforce one another.
22:21 karolherbst: imirkin_: but on the other hand, where would be the fun?
22:22 imirkin_: well, fun != working situation for end-users
22:22 imirkin_: also the fact that people have decided it'd be hilarious to start using GL in core system applications has greatly exacerbated the shittiness of the situation
22:23 imirkin_: like wtf is kde doing using GL? dunno.
22:23 karolherbst: imirkin_: well the main goal was higher power efficiency
22:23 karolherbst: but
22:23 airlied: imirkin_: EXA is good enough for anyone :)
22:23 karolherbst: I think nobody really measuered it
22:23 imirkin_: pretty much.
22:23 airlied: it does turn out that GL is the only graphics acceleration api we have
22:23 karolherbst: airlied: right, but I think most of the "promises" of OpenGL where never fact check
22:23 karolherbst: ed
22:24 imirkin_: airlied: indeed it does. but why do you need one in the first place?
22:24 imirkin_: for, you know, KDE.
22:24 imirkin_: it all worked Just Fine without it
22:24 airlied: imirkin_: 4K monitors are hard to composite without GL
22:25 airlied: and fullscreen apps in 4k act kinda shit without it
22:25 airlied: don't get me started on 2x 4k screens
22:25 imirkin_: airlied: so that's why Qt widgets have to be rendered with GL now?
22:25 Plagman: even toolkit stuff; you have blurs, you have aa edges, gradients, etc
22:25 Plagman: at hi-dpi it's more power efficient to do it accelerated
22:25 airlied: imirkin_: pretty much, widgets aren't like Xt anymore
22:25 karolherbst: Plagman: I think npbody ever checked that
22:25 Plagman: gl doesn't map great to it, ideally you'd want vulkan
22:25 imirkin_: more power efficient like people see it doesn't work and turn it off, thus less power?
22:25 karolherbst: Plagman: so is it really more efficient?
22:26 karolherbst: or does everybody just believe in that?
22:26 Plagman: i do because i worked on that for eyars and it was
22:26 karolherbst: I think mupuf talked about using modesetting in X and it was less efficient in the end as one example
22:26 karolherbst: Plagman: I see
22:26 airlied: imirkin_: any day now nouveau will be thread friendly :-P
22:26 imirkin_: my main complaint is that it was bolted on as a required thing
22:26 Plagman: but in my case the 2d rendering was going directly to the gpu with apis that are better than gl
22:26 Plagman: i don't have data on glamor/etc
22:26 karolherbst: Plagman: but yeah, I think vulkan might be better suited here
22:26 imirkin_: without any regard for the drivers that would have to deal with this BS
22:27 karolherbst: imirkin_: well, usually code should handle things like that though
22:27 imirkin_: but it doesn't.
22:27 karolherbst: right, but that's not their fault
22:27 imirkin_: and now KDE + nouveau = fail.
22:27 imirkin_: whose fault is it then?
22:28 Plagman: that happens all the time, right? on nvidia hw they probably only tested on the most used config, which isn't nouveau
22:28 Plagman: unfortunate, but it happens with tons of stuff
22:28 karolherbst: I think the main problem was, that at some point it was expected that OpenGL was only used for games and stuff so multithreading wasn't really in the mind back then
22:28 karolherbst: but.. well
22:29 karolherbst: and I don't think that the issue is really multithreading anyway
22:29 imirkin_: Plagman: there's a big diff when that happens with $game which you could just not play, vs some core piece of functionality required for the system to operate
22:29 karolherbst: just multiple contexts at once
22:29 karolherbst: and I don't see why anybody would assumed there is only a hand ful
22:29 karolherbst: l
22:29 Plagman: that being said i remember when some toolkit turned on gl by default and it blew up systems with the nvidia driver too
22:29 imirkin_: karolherbst: no need for multiple contexts
22:29 karolherbst: imirkin_: I mean across applications
22:29 imirkin_: GLAMOR used to trigger issues in nouveau all by itself
22:29 karolherbst: right
22:29 imirkin_: something with VBO sync
22:30 imirkin_: and we still have some issues related to ... $dunno
22:30 karolherbst: right
22:30 imirkin_: which cause those artifacts in valley
22:30 imirkin_: (on maxwell+)
22:30 karolherbst: ahh right
22:30 karolherbst: I saw those
22:30 imirkin_: GL is just not a reliable thing that can be counted on.
22:30 imirkin_: and all of a sudden someone decided it was
22:30 imirkin_: and a torrent of shit got poured on us
22:31 Plagman: if you can't develop a desktop/etc with the assumption that these sort of apis are reliable, isn't the platform kind of insane? i feel like you've reversed the problem here
22:31 karolherbst: well, some people care about having higher power efficiency, because this frees resources for other things
22:31 imirkin_: Plagman: it was never part of the "reliable set of things" set
22:31 imirkin_: and then got added without any checking of whether it actually was
22:31 karolherbst: I doubt that OpenGL by itself is really the problem here though
22:31 karolherbst: because you want even OpenGL to be reliable
22:32 karolherbst: even in games and stuff
22:32 imirkin_: here's a ridiculous example
22:32 imirkin_: imagine some hw had OpenAL drivers optimized for that hw
22:32 imirkin_: and it worked in like the 3 games that used it
22:33 airlied: imirkin_: OpenGL has been assumped reliable for years
22:33 imirkin_: and then all of a sudden, KDE decided it was going to use OpenAL for everything
22:33 imirkin_: and started blowing up anyone who used those drivers
22:33 airlied: gnome-shell has been using it for gdm even in RHEL7
22:33 imirkin_: what would the reaction be?
22:33 airlied: granted RH should be getting skeggsb to fix it, but other things do get in the way
22:33 karolherbst: airlied: well I have a desktop system now, and I put it on my list after the P50 bugs...
22:33 airlied: but as far as modern Linux desktops go, the expectation is GL should work
22:33 karolherbst: hopefully that turns out to work out
22:34 Plagman: imirkin_: if that was the only openal driver ever, that'd be dumb
22:34 imirkin_: airlied: it wasn't when all the issues started.
22:34 Plagman: if there were configs were it worked just fine, and that was most of the customers they cared about, then that seems like natural order of things
22:34 karolherbst: imirkin_: well, Linux was way behind with that accell stuff anyway
22:34 airlied: imirkin_: you can't expect multi-threaded GL to be special cased for just nouveau
22:34 karolherbst: I think even windows had more GPU accel back then
22:34 airlied: imirkin_: it's not like the problems hasn't been known about and ignored for yuear
22:34 imirkin_: airlied: it's a lot more than multi-threaded GL
22:34 airlied: years
22:35 imirkin_: it's ... GL.
22:35 karolherbst: right, and now we have vulkan, so we could move to that ;)
22:35 imirkin_: the MT stuff just yields to the most obvious (and fastest) fail
22:35 Plagman: then you can move from crashing apps to crashing the gpu :P
22:35 karolherbst: Plagman: yay
22:36 karolherbst: Plagman: but well, X driver were always that low level usually anyway...
22:36 karolherbst: or not?
22:36 karolherbst: well not with modesetting anymore
22:36 karolherbst: but before that
22:36 Plagman: yeah they would
22:36 Plagman: but a toolkit that used vulkan would be quite scarier than a toolkit that used gl, in the current state of things
22:37 Plagman: not talking about the ddx part
22:37 karolherbst: yeah
22:37 karolherbst: maybe we should implement glamor in vulkan
22:37 karolherbst: and then the normal 2d paths are faster than using gl in toolkits again?
22:37 Plagman: for any 2d api accel ideally you'd want bindless
22:37 Plagman: probably compute
22:37 Plagman: to do the best possible job
22:38 karolherbst: sounds sane
22:38 karolherbst: we just need an API which has low overhead for offloading things to the GPU
22:39 karolherbst: and I somehow doubt that even vulkan is fit for that, because there you still have one application trying to somehow sync to the display refresh rate
22:39 karolherbst: not 20 applications doing small tiny tasks all the time
22:39 Plagman: well, that's the wsi aspect
22:39 Plagman: maybe you don't use wsi presentation at all, you render offscreen and interop with something?
22:40 Plagman: or you present to your window, but make sure to do it with something like IMMEDIATE
22:40 Plagman: if anything vulkan is better there because it's quite a bit more explicit about its swapchain
22:40 imirkin_: i do think that a scaled down, simple 2d accel api would be quite useful.
22:40 Plagman: Xrender? :p
22:40 karolherbst: Plagman: do you know how the Mac OS X stuff kind of works?
22:40 imirkin_: pretty much :)
22:40 karolherbst: I am sure they don't use OpenGL
22:41 Plagman: there was a time where toolkits used it, before switching to gl
22:41 imirkin_: dunno how i feel about trapezoids though
22:41 Plagman: they used traps for AA edges, filters for blurs, etc, even gradients
22:41 imirkin_: yeah. and that's the switch i'm complaining about :)
22:41 Plagman: the problem is these toolkits ran like complete shit on exa/etc
22:41 Plagman: the only piece where it was better with perf and power usage was the nvidia blob and maybe the intel implementation of that stuff
22:41 imirkin_: i dunno. i never had issues.
22:42 Plagman: it wasn't not working, it was just slow
22:42 imirkin_: i still don't since i tend to avoid the problematic software :)
22:42 Plagman: at high-dpi, taking a blur sw fallback in the x server was really punishing
22:43 Plagman: karolherbst: i'm not sure how the mac stuff works internally
22:43 Plagman: i'm guessing they take a shortcut to their internal gpu abstraction but that's pure guesswork
22:44 karolherbst: mhh yeah
22:44 karolherbst: whatever that is
22:44 karolherbst: they have a beta QuartzGL thing since Tiger or so
22:44 karolherbst: but until now it was never enabled by default
22:45 Plagman: hehe
22:45 Plagman: sounds like they have less courage than the kde guys
22:45 karolherbst: where they would use OpenGL, but it seems like they agree with imirkin_ here :p
22:45 karolherbst: Plagman: ohh I think there are other reasons
22:46 karolherbst: I think they just spend a lot of time finding the optimal path
22:46 karolherbst: and on the linux desktop everybody just assumes that with OpenGL everything is faster (tm)
22:46 karolherbst: I am sure some things are
22:46 karolherbst: but I am also sure it is getting overused
22:49 karolherbst: imirkin_: ohh by the way, I think you will love gtk-4
22:50 Plagman: i think realistically it's hard for toolkits to go back to platform-specific things like xrender if they want to be cross-platform
22:50 imirkin_: karolherbst: i already don't like gtk3
22:50 Plagman: so something like Qt doubling down on gl/vulkan seems normal to me
22:50 karolherbst: imirkin_: :D
22:50 imirkin_: and i can't upgrade gdm, since apparently that just *has* to depend on gnome-shell.
22:51 karolherbst: Plagman: well right, but maybe if you do effects on small things, the CPU might be faster
22:51 imirkin_: instead of being a nice little standalone app
22:51 karolherbst: imirkin_: use sddm ;)
22:51 imirkin_: i've had to use lightdm on new installs
22:51 imirkin_: i think i'll just flip back to the original xdm and move on
22:51 karolherbst: lightdm is another world of pain though
22:51 Plagman: karolherbst: ideally the toolkit itself would have a heuristic to determine that, and mix sw rendering with gpu where it makes sense
22:52 halfline: imirkin: "little"
22:52 imirkin_: it kinda mostly works usually
22:52 karolherbst: lightdm is fine as long as it runs, but if you run into issues? good luck debugging those
22:52 Plagman: although i would like to believe that if you get it right, you can do most of it on the gpu
22:52 halfline: if you want the login screen to have standard desktop features (like a11y) then you either implement everything twice or share code
22:52 karolherbst: Plagman: yeah
22:52 imirkin_: halfline: i don't
22:52 karolherbst: Plagman: but again, nobody checks that
22:52 karolherbst: or nobody has time for that or whatever
22:53 imirkin_: i just want a pretty background and a dialog that looks slightly nicer than what xdm offers.
22:53 halfline: imirkin: what about keyboard switching, on screen keyboard, animations ?
22:53 imirkin_: no thanks
22:53 halfline: okay gdm's not for you then indeed
22:53 karolherbst: sound control might make sense
22:53 imirkin_: it *used to be* for me
22:53 karolherbst: if you share lock screen with the login screen
22:53 karolherbst: or media control
22:54 halfline: yea, and sane multi monitor handling
22:54 imirkin_: yeah definitely don't need that.
22:54 karolherbst: on screen keyboard is only relevant if you have a tablet or something, but then you need a totally different approach to UI anyway
22:54 karolherbst: halfline: sane as in display everything on every screen?
22:54 karolherbst: don't see why you want something else
22:54 halfline: karolherbst: well many laptops these days have touchscreens
22:54 karolherbst: halfline: and?
22:54 halfline: so having a onscreen keyboard is useful
22:55 karolherbst: please touch the keys so anybody can see your password :p
22:55 halfline: if your yoga is yoga'd
22:55 karolherbst: nah
22:55 karolherbst: that is maybe some fancy feature
22:55 karolherbst: but nothing which anybody would miss
22:55 halfline: and shared user experience between the unlock screen and login screen
22:55 halfline: there's a bunch of really good reasons i decided to do it this way
22:55 karolherbst: right, media controls, are nice
22:55 karolherbst: and other things
22:56 karolherbst: but still
22:56 halfline: and part of the reason was maintenance burden
22:56 halfline: the old way sucked for me
22:56 halfline: having to fix bugs twice in code that behaved subtly different
22:56 karolherbst: yeah, that is fine, I still don't think that a onscreen keyboard is really important here ;)
22:57 halfline: i don't want to argue a specific point
22:57 karolherbst: right
22:57 skeggsb: karolherbst: of course it is... not everyone has/is using keyboard+mouse on systems these days
22:57 halfline: it's not useful for you, it is useful for others
22:57 halfline: it sounds like none of it is useful for imirkin :-)
22:57 karolherbst: skeggsb: as I said, on systems without keyboards you have a totally different approach to UI anyway
22:57 halfline: which is fine, he can use sddm or lightdm or wahtever
22:58 karolherbst: having a different lock screen/login thing for such systems might be fine as well
22:58 karolherbst: or maybe the same
22:58 karolherbst: and add features optionally or whatever
22:58 skeggsb: karolherbst: and gnome-shell already deals with that, it makes sense to not reimplement it for a login screen
22:58 karolherbst: yeah, I think they moved stuff into the compositor to deal with X sec issues, right?
22:59 karolherbst: otherwise they could move it into a separate process
22:59 karolherbst: on plasma kwin isn't doing the lockscreen, at least on X
22:59 airlied: gtk4 has vulkan now bte
22:59 airlied: btw
22:59 Plagman: neat
23:00 Plagman: at least it definitely won't cause nouveau to blow up that way
23:00 karolherbst: .... :D
23:00 skeggsb: airlied: yeah, i'm being pushed that way now :P
23:00 imirkin_: yeah, should just force vulkan
23:00 karolherbst: we'll see about that
23:00 karolherbst: skeggsb: ;)
23:00 imirkin_: that way it uses a swrast
23:00 imirkin_: and all is well
23:00 karolherbst: I still think we can have vulkan this year :p
23:01 Plagman: the whole point of the api is that it's not hard to get an impl off the ground; if you already have a compiler/etc it doesn't seem far fetched, exciting!
23:01 karolherbst: yeah
23:01 imirkin_: mostly missing some kernel APIs
23:01 karolherbst: Plagman: I pretty much completed nir for nouveau for OpenGL, so we are pretty much done on that front
23:01 karolherbst: imirkin_: yeah, basically
23:02 karolherbst: that is what skeggsb also kind of works on right now I think?
23:02 imirkin_: dunno. we discussed it back when VK first came out.
23:02 skeggsb: the beginnings of, yeah. still got one other thing in the pipe before i can concentrate on that fullyt
23:02 karolherbst: right
23:02 imirkin_: just need to allow placement of bo's at specific VA's
23:03 karolherbst: skeggsb: saw my new backlight fix patch?
23:03 rhyskidd: some wip code: Falcon firmware parsing out of the vbios: https://github.com/envytools/envytools/compare/master...Echelon9:feature/BIT-p-pmu-falcon-data
23:03 skeggsb: karolherbst: yep
23:03 rhyskidd: still has some rough edges, but getting there! pls try it out :)
23:03 karolherbst: skeggsb: I try to get the race/lock thing worked out tomorrow and then I am done with the P50 stuff
23:05 airlied: the other problem with 2d APIs is at some point you have to connect them to the hw and the he is 3D and you then need another driver
23:05 airlied: bring back cairo-drm
23:05 karolherbst: current regs tgsi-nir: https://gistpreview.github.io/?e42ecd69d885b48aaf37afc87efb06fc
23:05 imirkin_: rhyskidd: you could go the extra step and hook it up to envydis to dump the decoded falcon.
23:06 imirkin_: karolherbst: hah. i screwed you with bindless, didn't i
23:06 karolherbst: well
23:06 karolherbst: nir can't do bindless yet :p
23:06 karolherbst: afaik
23:06 karolherbst: or not really
23:06 imirkin_: not easily.
23:06 karolherbst: arb_enhanced_layouts is also broken in nir
23:06 imirkin_: well, not at all
23:07 karolherbst: it is
23:07 imirkin_: but should be addable
23:07 karolherbst: ohh
23:07 karolherbst: right
23:07 imirkin_: with about the same (low) level of effort as it was for tgsi
23:07 karolherbst: the only thing which worries me is that arb_shader_ballot fail
23:07 karolherbst: because it doesn't really make sense
23:07 karolherbst: but
23:07 karolherbst: overall it looks good enough to me (tm)
23:08 imirkin_: uhhh ... tcs-read-texture seems scary
23:08 Plagman: i think timothy is working on bindless+nir?
23:08 karolherbst: imirkin_: no
23:08 Plagman: also shader_ballot probably, or it's on the list
23:08 karolherbst: imirkin_: we just get a load_output where we shouldn't
23:08 Plagman: since we need that
23:08 imirkin_: karolherbst: oh. so nothing to do with textures?
23:08 karolherbst: no
23:08 karolherbst: just a load_input
23:08 karolherbst: ...
23:08 karolherbst: load_output
23:08 karolherbst: for silly reasons
23:09 karolherbst: basically a value passed to store_output
23:09 karolherbst: and the same thing is read back with load_input
23:09 karolherbst: allthough we could just read the value
23:09 karolherbst: I just don't want to deal with that now
23:09 karolherbst: imirkin_: "void nv50_ir::NVC0LoweringPass::handleLDST(nv50_ir::Instruction*): Assertion `prog->getType() == Program::TYPE_TESSELLATION_CONTROL' failed."
23:09 imirkin_: right
23:10 karolherbst: there is one thing I want to look into though
23:10 karolherbst: nir_lower_uniforms_to_ubo
23:10 karolherbst: which gives me two things
23:11 rhyskidd: imirkin_: :)
23:11 karolherbst: 1. I can remove the load_uniform code
23:11 karolherbst: 2. I can remove the +1 hack in load_ubo
23:13 imirkin_: karolherbst: btw, have you done code size analyses with the nir fe instead of tgsi? i'd be curious if the nir one is ever (much) better
23:13 imirkin_: i.e. not like by 1 instruction, but by like a measurable amount
23:13 karolherbst: I checked once and back then it was more gprs usage
23:13 karolherbst: but I think I fixed that
23:13 imirkin_: i mean on an individual shader basis
23:13 imirkin_: that was the overall thing
23:13 karolherbst: I see
23:14 karolherbst: well, I will check out that one pass and see what changes in shaders overall
23:17 imirkin_: karolherbst: there's a thing you can comment out in my nv_report.py script
23:17 imirkin_: which will print the individual changes
23:17 karolherbst: yeah, I am aware of that
23:42 karolherbst: imirkin_: c0[%r122+0x10000] -> c0[$r3+0x0]
23:42 karolherbst: but
23:42 karolherbst: c0[%r122+0x10004] -> c1[$r3+0x4]
23:45 karolherbst: imirkin_: https://github.com/karolherbst/mesa/commit/9743cff105bfbe379a3deb659ae68e766505206d
23:51 imirkin_: karolherbst: those are both wrong
23:51 imirkin_: c0[0x10000] should become c1[0]
23:52 karolherbst: yeah, so?
23:52 imirkin_: oh f me. yes. that is correct.
23:52 karolherbst: ;)
23:53 imirkin_: and it's still wrong.
23:53 imirkin_: instead of offset >> 16
23:53 imirkin_: er hm, no, it may be fine.
23:53 karolherbst: well, the test seems to be happy with my fix
23:53 karolherbst: and it looks like the version before I did the nir uniform to ubo conv think
23:54 karolherbst: nir just ends up doing a + 1 to the second indirection level
23:55 karolherbst: allthough
23:55 karolherbst: no, it is fine
23:55 karolherbst: there is no other way to do it
23:55 imirkin_: that fix is clearly correct.
23:55 imirkin_: irrespective of anything else.
23:55 karolherbst: ld u32 %r14 c0[0x10]; add s32 %r16 %r14 0x1; ld u32 %r17 c0[%r16][0x0] ... ld u32 %r20 c0[%r16][0xc] is the shader
23:56 karolherbst: wondering if I should keep the old code
23:56 karolherbst: where I was doing c1 directly
23:56 imirkin_: probably. that's a lot less hassle.
23:57 karolherbst: yeah
23:57 imirkin_: but the fix is still correct.
23:57 karolherbst: shader with old code is: ld u32 %r13 c0[0x10]; ld u32 %r14 c1[%r13][0x0] ...
23:57 karolherbst: yeah
23:59 karolherbst: but even with the old code I end up with the same code
23:59 karolherbst: just not for the first ubo
23:59 imirkin_: should be equivalent.
23:59 karolherbst: yeah
23:59 karolherbst: we just start with a more optimized shader
23:59 karolherbst: and it only matters with indirect acces of the ubo