00:18 pmoreau: karolherbst: Branches updated: they should now compile, and you should no longer need setting the IR_FORMAT cap.
07:10 karolherbst: pmoreau: IR_FORMAT? You mean PIPE_COMPUTE_CAP_IR_TARGET?
07:54 Subv: hey, what's the purpose of the VIEWPORT_TRANSLATE_X/Y/Z and VIEWPORT_SCALE_X/Y/Z methods in nvc0? considering there's also VIEWPORT_HORIZ and VIEWPORT_VERT methods
10:27 pendingchaos: Subv: looking at nvc0_state_validate.c, it seems that VIEWPORT_TRANSLATE/SCALE_X/Y/Z is used for the transformation and VIEWPORT_HORIZ/VERT is used for clipping
15:36 pmoreau: karolherbst: Yes sorry, I meant IR_TARGET
16:45 karolherbst: pmoreau: ohh, before I forget, the SVM atomic stuff is fully optional, right?
17:10 Subv: does anyone know the exact behavior of the IPA instruction on maxwell shaders? i know it reads an interpolated value from the shader inputs but what are the third, fourth and fifth operands? Example IPA: ipa $r9 a[0x8c] $r10 0x0 0x1
17:10 Subv: $r10 in this case came from ipa pass $r10 a[0x7c] 0x0 0x0 0x1 and then mufu rcp $r10 $r10
17:11 Subv: i'm assuming that the output from the "ipa pass" is "1/gl_FragCoord.w", though i don't understand why it uses "pass" for this
17:19 karolherbst: Subv: pass is the exact value without interpolation
17:19 Subv: the value of the provoking vertex?
17:20 karolherbst: I think so
17:21 Subv: i don't understand what "ipa $r9 a[0x8c] (1/provoking_vertex.w) 0x0 0x1" should do, then
17:23 Subv: does the nouveau maxwell emitter also emit that ipa pass at the beginning of every fragment shader?
17:28 karolherbst: you need to pass the result into other ipa invocations
17:28 karolherbst: not all, but most of them
17:28 karolherbst: especially the mul ones
17:28 karolherbst: but pass shouldn't do a 1/value thing
17:29 Subv: the mufu rcp is where the 1/value comes from
17:29 karolherbst: it is more like an ipa mul does a value*1/$value I think, but I don't know much about those details here
17:29 karolherbst: right
17:29 karolherbst: I forgot about that
17:29 karolherbst: so you usually do ipa pass $r0 a[0x7c]
17:29 karolherbst: rcp $r0 $r0
17:30 karolherbst: and then use that $r0 in other ipa passes
17:30 Subv: i'm trying to write a maxwell shader -> glsl decompiler and this instruction is giving me a hard time, because there doesn't seem to be any documentation about it at all and the fields all just look like magic numbers sprinkled here and there
17:30 karolherbst: not all of them though
17:31 annadane: i know this isn't nouveau's fault and i don't mean to come here to bitch but has anyone ever had issues with nouveau *not* crashing... it did it on kde plasma constantly but even on mate when i have a lot of programs open it occasionally freezes up as well
17:31 annadane: or rather, has anyone not had nouveau crash, i mean
17:31 annadane: misworded
17:31 annadane: it's not your fault you get no cooperation from nvidia
17:31 annadane: it's incredibly frustrating
17:32 karolherbst: Subv: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
17:32 karolherbst: Subv: search for fragCoord[3]
17:32 Subv: karolherbst: it seems weird to multiply the value by the provoking vertex's w in ipa mul, what does that even achieve?
17:33 karolherbst: imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp#n3134
17:34 karolherbst: can't we drop that entire if clause and just do the else branch?
17:34 karolherbst: fragCoord[3] is RCP(SV_POSITION[3]) already
17:35 karolherbst: Subv: well, I didn't look into that, I have no idea if that's weird or not
17:35 karolherbst: all I know is that interpolation is crazy business :p
17:55 lachs0r: urgh
17:55 lachs0r: I tried to run piglit but that caused my system to become unresponsive and lots of memory corruption on subsequent boots until I disconnected my system from power
17:56 lachs0r: (gtx 960/gm206)
17:57 lachs0r: pendingchaos: how do I run just the tests you’re interested in?
17:59 pendingchaos: the programs to run should be in bin/ and start with nv_conservative_raster_
17:59 pendingchaos: running them without any arguments should be fine
18:00 pendingchaos: you shouldn't need to run the gles2 tests
18:02 Subv: it seems ipa pass is actually NV50_IR_INTERP_LINEAR, and just "ipa" is NV50_IR_INTERP_PERSPECTIVE, according to the emitter
18:10 lachs0r: pendingchaos: https://0x0.st/sBfK.txt
18:11 lachs0r: also nv_conservative_raster_dilate-draw_gles2 was skipped
18:12 lachs0r: rest passed
18:17 imirkin: karolherbst: no, we can't :)
18:18 imirkin: Subv: take the current code as correct. adjust your thinking until it matches the code.
18:20 imirkin: Subv: it also works together with https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp#n2617
18:20 imirkin: basically you get the proper "w" given the offset
18:27 imirkin: Subv: about viewports, also note that viewport widht/height are global, while the viewport transforms are per viewport (there are up to 16 viewports configurable if you use a geometry shader ... or there's fancier stuff on GM20x+, like NV_viewport_array2 and so on)
18:39 karolherbst: imirkin: why not though?
18:40 karolherbst: ohhhhh
18:40 karolherbst: mhhhh
18:40 imirkin: karolherbst: not sure i get the question ... the two paths are different
18:40 karolherbst: interesting
18:40 imirkin: they do different things
18:40 karolherbst: yeah, I see the difference
18:40 karolherbst: now I am wondering
18:41 imirkin: piglit won't pick up the difference ... but there are some picky dEQP tests iirc
18:41 imirkin: i didn't exactly get all of this right on the first time 'round :)
18:42 karolherbst: mhh
18:42 karolherbst: I am wondering because I don't do that in NIR, but we have failing interpolateAt tests with TGSI
18:42 karolherbst: I have none with nir
18:42 karolherbst: I am sure it is something else though
18:42 imirkin: the failing tests are with interpolateAt and not figuring out the source varying?
18:42 imirkin: iirc those were all fixed ... which ones fail?
18:42 imirkin: maybe there's something new though
18:43 imirkin: there were a handful of TODO's that i had in the tgsi code
18:43 karolherbst: new tests were added
18:43 karolherbst: ahh right
18:43 imirkin: which should now be possible
18:43 karolherbst: that was it
18:43 imirkin: but weren't at the time i implemented them
18:43 karolherbst: new tests :)
18:43 imirkin: can you tell me which one to see if there's anything obvious?
18:44 imirkin: [could be that the tests are broken...]
18:44 karolherbst: yeah, just creating the piglit summary again
18:44 imirkin: or could be that the nir path is *so* broken that it fools the test into thinking it passed ;)
18:44 karolherbst: :D
18:44 karolherbst: maybe
18:45 imirkin: a lot of piglits are passable by just making the frag shader always draw green
18:45 karolherbst: yeah, I noticed
18:45 karolherbst: and some pass even though you have the wrong result
18:45 karolherbst: a bit annoying
18:45 imirkin: or by doing nothing at all and getting lucky and getting a green source surface
18:45 karolherbst: buffer tests are funny
18:45 karolherbst: usually we reuse the same global address
18:45 imirkin: yea :)
18:45 karolherbst: and if the test expects the same values as the last one
18:46 karolherbst: :)
18:46 karolherbst: imirkin: *block-array
18:46 imirkin: give me a name.
18:46 karolherbst: array-nonuniform and array-of-array
18:46 imirkin: a specific one. that i can run.
18:46 karolherbst: spec@arb_gpu_shader5@execution@built-in-functions@fs-interpolateatcentroid-block-array
18:46 imirkin: thanks
18:46 karolherbst: ahh
18:46 karolherbst: /tests/spec/arb_gpu_shader5/execution/built-in-functions/fs-interpolateAtCentroid-block-array.shader_test is the file :)
18:47 imirkin: hm. time to update piglit.
18:48 imirkin: yeah that fails on GF108. i'll have a glance.
18:48 imirkin: thanks for letting me know
18:48 imirkin: hmmmmm. surprising.
18:48 imirkin: nothing funny in there.
18:49 imirkin: i was expecting a weird qualifier.
18:51 karolherbst: I could check the diff between nir and tgsi
18:51 imirkin: ok yeah that's broken code.
18:51 imirkin: that's just plain wrong.
18:51 karolherbst: ahh
18:52 karolherbst: so the piglit is wrong?
18:52 imirkin: (the output code, that is)
18:52 imirkin: no
18:52 karolherbst: ohh
18:52 karolherbst: k
18:52 imirkin: something in the tgsi fe
18:52 imirkin: is forgetting to shift by 4
18:52 karolherbst: ahh
18:52 imirkin: "oops"
18:52 karolherbst: so it is TGSIs fault?
18:52 karolherbst: or tgsi->nvir?
18:52 imirkin: tgsi -> nvir
18:52 karolherbst: okay
18:53 imirkin: so we get it right for the regular interpolate - return interpolate(src, c, shiftAddress(ptr));
18:54 imirkin: but we forget to for the INTERP_* case
18:54 imirkin: "oops"
18:58 karolherbst: happens
18:59 imirkin: it's not exactly a common case.
18:59 karolherbst: ohh yeah, I do that in nir for all, because it is the same code :)
18:59 karolherbst: so that explains the difference
19:00 imirkin: in tgsi it's a bit different ... fetchSrc() vs an explicit opcode
19:00 imirkin: perhaps i could have made something more graceful. dunno.
19:00 karolherbst: yeah, I saw that in TGSI a lot of the logic is inside that fetchSrc thing, but I decided to put the logic rather in the opcode handling code and just have common helper for indirects and load/stores and so on
19:01 imirkin: in nir the loads are more explicit
19:01 karolherbst: and a getSrc is really just giving me the nvir src
19:01 karolherbst: yeah, true
19:01 imirkin: whereas in tgsi, IN[] / CONST[], etc can appear in any op
19:01 karolherbst: right
19:01 karolherbst: or BUFFER :)
19:01 imirkin: right.
19:01 karolherbst: I saw the handleSTORE and handleLOAD code :)
19:01 karolherbst: quite fun
19:02 imirkin: they might still have the commented out pieces from earlier iterations
19:03 karolherbst: a bit yes
19:11 imirkin: wtf. another bug. this is horrible.
19:11 imirkin: some huge idiot wrote this code. might have been me =/
19:14 imirkin: ok. all better.
19:21 imirkin: in practice, no one ever uses interpolateAt* ... or indirect inputs :) probably why it's never come up
19:23 Yardanico: guys, if you'll need someone to test something with GM206 (GTX 750 v2), ping me :)
19:23 imirkin: Yardanico: cool thanks!
19:26 karolherbst: imirkin: :D Well we didn't found those with the CTS, so probably nobody cares ;)
19:26 Moiman: GTX 750 v2 is missing from CodeNames wiki
19:26 karolherbst: we should remove this table...
19:27 karolherbst: the wikipedia page is usually good enough for those
19:27 karolherbst: and users can just check dmesg for what they have
19:27 karolherbst: or maybe we just report that to userspace
19:27 imirkin: eh, it's convenient
19:27 karolherbst: imirkin: I use https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units
19:28 Yardanico: karolherbst, it doesn't have GTX 750 v2 too :)
19:28 imirkin: yeah, but it's nice to get a quick overview.
19:28 karolherbst: I am sure the v2 is a GM107
19:28 karolherbst: ohh wait
19:28 karolherbst: GM206
19:28 Yardanico: karolherbst, it's not :)
19:28 Yardanico: 01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 750 v2] (rev a1)
19:29 HdkR: That wiki page is super useful, I have it open at least once a week
19:29 lachs0r: I can test on the following: 7600gt, 8400gs, 9800gt, g210, 820m (optimus), gtx 560 ti, gtx 960
19:30 Yardanico: it's actually a shame because I could've easily used nouveau if I had GM107 :)
19:31 lachs0r: (not sure which 8400gs but I believe it’s g98)
19:32 karolherbst: imirkin: *sigh* I totally left my personal machine alone since I started my new job and now I have to do the gentoo profile migration and updates.. (KF5 5.40 -> KF5 5.44 or kernel 4.14.4 -> 4,15,12) :)
19:32 imirkin: that's the one unfortunate thing about gentoo
19:32 imirkin: you can't leave it without updates for TOO long
19:32 imirkin: otherwise you dig yourself into a hole
19:32 imirkin: that can be annoying to get out of
19:32 karolherbst: I have to throw out qt4 :D
19:33 imirkin: i tend to get in trouble with ruby
19:33 karolherbst: mhh
19:33 karolherbst: I usually just increase that ruby version in make.conf and that usually works out
19:33 imirkin: it usually conflicts with itself
19:34 karolherbst: nice
19:35 karolherbst: imirkin: ahh, that setIndirect thing... I hit that too
19:35 karolherbst: was wondering why my code didn't work until I noticed it doesn't work when there is no source :)
19:36 karolherbst: allthough in your case it shouldn't matter, or should it?
19:36 imirkin: gotta make sure those go on last =/
19:36 imirkin: thing is that the indirect gets added as a source
19:36 imirkin: in the srcs array
19:36 karolherbst: I see
19:36 imirkin: so it has to go after all the "real" sources
19:37 karolherbst: interesint
19:37 karolherbst: interesting
19:37 imirkin: having it all in the srcs array avoids all kinds of special casing
19:37 karolherbst: I got it right with the nir stuff without knowing that
19:37 imirkin: but it does mean you have to be a little careful
19:37 karolherbst: yeah, understandable
19:39 lachs0r: I have left two of my systems alone for 6+ years, ran an update (rolling distro), worked out fine… including the systemd switch (that was opensuse factory, now tumbleweed)
19:39 lachs0r: have to say they handle this really well
19:39 karolherbst: imirkin: do you know how common it is that screens don't have the horizontal RGB subpixel layout?
19:39 imirkin: no clue
19:40 imirkin: there's an image that can help you test it though
19:40 imirkin: for a particular screen
19:40 karolherbst: well, I have a 40" FHD screen here and it is vBGR
19:40 karolherbst: I could just see it with my camera lens
19:41 karolherbst: but this is the first one I encounter which has a different layout
19:41 karolherbst: that's why I am wondering
19:41 lachs0r: anything goes with TVs
19:41 lachs0r: but for PC monitors, that’s very uncommon
19:41 karolherbst: makes sense
19:41 karolherbst: just wondering why they would use different layouts for those panels
19:42 karolherbst: the quality is pretty crappy anyway, but still
19:42 lachs0r: well, it’s a TV :)
19:42 HdkR: Samsung QLED has a cross-hatch subpixel layout
19:42 HdkR: Which there are monitors available for that :)
19:42 karolherbst: uhhh
19:43 karolherbst: I am sure computers love that
19:43 HdkR: http://www.hdtvtest.co.uk/image/news/qled-subpixel.jpg
19:43 lachs0r: subpixel font rendering sucks anyway, just give it more pixels per inch
19:43 imirkin: http://www.lagom.nl/lcd-test/img/subpixel-font.png
19:43 imirkin: the one that looks crisp indicates which layout your lcd has
19:44 imirkin: (for me it's the RGB one)
19:44 karolherbst: yeah, for me as well
19:44 lachs0r: I always see the color fringes :/
19:44 lachs0r: so I use greyscale AA
19:44 karolherbst: intersting it even works on my 4k screen here
19:47 imirkin: why is that surprising?
19:48 karolherbst: just thought that with 4k you usually have too smal pixels to really see it
19:48 imirkin: well, it's just a matter of seeing it on the image... pixels work either way
19:48 karolherbst: allthough I had to get quite near to the display to actually see a difference with that image
19:48 imirkin: you can't zoom it though
19:48 imirkin: since that would break the effect
19:48 imirkin: 1 pixel in the image has to be 1 pixel on screen
19:48 pmoreau: imirkin, karolherbst: I was thinking of slowly starting to move the wiki to GitLab pages; with been all complaining about the current one, and the GitLab pages architecture seems quite modular, as one can pick any SSG to build the pages. Would you have any preferences?
19:49 karolherbst: imirkin: right, but pixels on a 15" 4K display are quite small
19:49 pmoreau: s/with/we’ve
19:49 imirkin: karolherbst: ah yeah, they would be.
19:49 imirkin: pmoreau: what's SSG?
19:49 pmoreau: My brain is not working --"
19:49 pmoreau: Static Site Generator
19:49 imirkin: oh. it's like the github thing basically?
19:49 pmoreau: Sphynx, Jekyll, etc.
19:50 karolherbst: I am for something trivial
19:50 karolherbst: we don't really need fancy formatting
19:50 karolherbst: so even markdown would be plenty
19:50 imirkin: easy to edit is the main thing
19:50 pmoreau: GitHub might have one, I haven’t played with their github.io thing
19:51 imirkin: i don't feel strongly either way
19:51 imirkin: currently there's basically no way to let people edit the fd.o one
19:51 karolherbst: yeah, easy to edit is the most important thing
19:51 pmoreau: I was thinking of rst, similar to envytools, but markdown is fine as well
19:51 karolherbst: if it is annoying to edit, nobody does
19:51 imirkin: the whole point of a wiki is that it be editable
19:51 imirkin: so the permissioning of the edits is the main thing to fix
19:51 karolherbst: pmoreau: if I have to look into any kind of docs to get the syntax right, it is too complicated ;)
19:51 imirkin: the rest is largely irrelevant
19:52 karolherbst: and the source files should be inside git or something
19:52 pmoreau: Managing permissions should hopefully be easier than it currently is
19:52 imirkin: they are with the current thing too, btw (in git)
19:53 karolherbst: pmoreau: we can use external auth providers with gitlab, right?
19:53 imirkin: i would also not focus on migrating any content over
19:53 imirkin: pretty much everything in the current wiki should be killed off, with a handful of exceptions
19:53 pmoreau: From what I gathered, you have a git repo on GitLab, and when you push a commit, it triggers a build of the website using the CI, and pushes it off.
19:53 karolherbst: pmoreau: I don't want random users to create accounts with passwords on any of our pages ;)
19:53 imirkin: pmoreau: is it editable online?
19:54 karolherbst: good point
19:54 imirkin: and is it possible to grant permissions to random people, e.g. via oauth to their e.g. google account?
19:54 pmoreau: karolherbst: Yes, there is external auth providers (for example GitHub), but the repo would be owned by the Nouveau group/team, which you can’t freely join I assume.
19:54 karolherbst: my requiernments: external auth provider, online edit, common version control, easy syntax, easy to edit
19:54 karolherbst: pmoreau: right
19:54 karolherbst: pmoreau: right management is a different thing
19:55 karolherbst: but I don't feel well with hosting passwords/emails pairs
19:55 karolherbst: even if it is $random_cloud_provider
19:55 pmoreau: For the online edit, GitLab has online editing like GitHub IIRC, and since that GitLab pages is a regular Git repo, it should have that as well.
19:55 imirkin: ok, but like you need previews / etc usually
19:56 pmoreau: Looking quickly through the GitLab pages documentation, they do talk about some preview module that you can usually have, but I am not too sure how it works.
20:03 karolherbst: pmoreau: can you also allow anonymous changes to the wiki, without an account?
20:03 pmoreau: I don’t think so
20:05 pmoreau: You would need to be identified to either edit from the GitLab webpage, or push a commit to the repo.
20:05 pmoreau: (I would guess)
20:05 karolherbst: mhh :(
20:06 karolherbst: but I guess with enough external providers it should be fine
20:06 imirkin: yeah, as long as people can be easily permissioned without having to create a new account
20:07 karolherbst: I mean just having an account should be okay already
20:07 karolherbst: if it needs any ack from us then it is pointless
20:07 pmoreau: Oh, you meant creating a local account, so not using external provider?
20:07 karolherbst: no, generally
20:07 imirkin: i think it's fine if we have to ack people to edit the wiki
20:07 imirkin: otherwise you get spam, etc
20:08 karolherbst: I doubt you would get so much spam
20:08 karolherbst: we could try out how it goes
20:08 imirkin: that was the reason for the current wiki setup
20:08 karolherbst: and if it is too much we can require an ack
20:08 pmoreau: No one ever come to #nouveau to speak nonsense or spam, ever ;-p
20:08 karolherbst: I mean, requiring an account is good enough
20:08 karolherbst: let it be a github one or something else
20:09 pmoreau: I’ll ask Daniel about the previewing thing, as I think he has some experience with the pages system.
20:10 karolherbst: I think aching changes might be fine for persons without permissions to directly edit it
20:10 karolherbst: but I wouldn't prevent it just because we didn't ACK a person
20:11 imirkin: either way
20:11 imirkin: i think figuring out the options available for permissions is paramount.
20:11 karolherbst: yeah
20:11 imirkin: then we can squabble over exactly how to configure it
20:11 karolherbst: pmoreau: where do you want to host it?
20:11 imirkin: fd.o is setting up a gitlab instance
20:11 pmoreau: ^
20:11 karolherbst: ahhh right
20:12 imirkin: i'm not a big fan of it ... wish the git ui was a lot more like cgit
20:12 imirkin: i really like that one
20:12 pmoreau: karolherbst: https://gitlab.freedesktop.org/
20:12 imirkin: but i get the operational burden of running one's own stuff without funding to do so.
20:12 imirkin: so it's all volunteer-based basically
20:17 pendingchaos: lachs0r: thanks
20:19 lachs0r: I’m not a fan of gitlab because it’s impossible to deploy without their scripts and very specific versions of everything. also has ridiculous system requirements for even the most basic setup. typical modern webshit.
20:19 lachs0r: and the CI doesn’t support kvm
20:20 lachs0r: (or libvirt for that matter)
20:20 lachs0r: but oh well, not like there are any decent alternatives
20:20 imirkin: i'm not a fan of git{lab,hub} because their ui is heavier than cgit.
20:20 lachs0r: yes.
20:21 karolherbst: lachs0r: there is always gogs, but I don't know how many features that misses
20:21 lachs0r: also cgit has working, usable search
20:21 lachs0r: and can list more than a few dozen commits without shitting itself
20:21 lachs0r: karolherbst: gogs has terrible performance and phones home
20:21 karolherbst: I couldn't care less about phones home
20:21 karolherbst: people need to take breaks
20:22 karolherbst: best way for that is to have unusable sites through phones :p
20:22 karolherbst: *for
20:25 pendingchaos: lachs0r: did you run the tests with mesa or the nvidia driver?
20:25 lachs0r: mesa
20:25 lachs0r: your branch
20:25 lachs0r: unless I was doing it wrong somehow
20:26 pendingchaos: nv_conservative_raster_dilate-draw_gles2 being skipped gives the impression the nvidia driver was used
20:26 pendingchaos: as it does not expose GL_NV_conservative_raster_dilate on gles for some reason
20:27 lachs0r: I’ve uninstalled the nvidia driver, built my distro’s mesa package with the branch instead, installed those, rebooted, confirmed I was running nouveau+mesa, then ran the tests
20:27 lachs0r: *packages
20:27 imirkin: pendingchaos: i assume you saw mareko's comments about not sticking this stuff into the viewport?
20:27 imirkin: he's spent a bunch of time reducing the sizes of various structures, and i guess wants to avoid that getting undone.
20:28 pendingchaos: yes, I am planning to move it to the rasterization state in the next version
20:28 imirkin: ok
20:29 lachs0r: pendingchaos: it’s possible that there were leftovers from nvidia’s driver because I haven’t always used packages. but would that even run with nouveau instead of outright crashing? :D
20:31 lachs0r: okay just checked, nothing left
20:32 pendingchaos: glxinfo shows that GL_NV_conservative_raster_dilate is supported on GLES?
20:43 lachs0r: pendingchaos: yes
20:43 lachs0r: Function "glConservativeRasterParameterfNV" not supported on this implementation
21:00 pendingchaos: seems to be that registry/gl.xml has GL_NV_conservative_raster_dilate as only supported on desktop GL
21:01 imirkin: ah yeah, that's piglit's dispatch thing
21:02 imirkin: it uses the khr gl.xml for dispatch
21:02 pendingchaos: I think I might just remove the gles version of the test
21:02 imirkin: and esp dealing with details like what is aliased to what
21:02 imirkin: so that the tests don't have to be too careful about it
21:05 karolherbst: is it even smart to expose extensions which doesn't exist? I don't know into what kind of issues we might run here
21:09 pendingchaos: lachs0r: if you use glvnd and X, you might be able to switch between mesa and the nvidia driver using something like this: https://0x0.st/sBOo.sh
21:09 pendingchaos: sometimes I have to reinstall the x server because something deletes libglx.so.default though
21:09 pendingchaos: you should also be able to use a modified mesa without installing it by using LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
21:10 pendingchaos: karolherbst: do you mean exposing GL_NV_conservative_raster_dilate on gles?
21:10 karolherbst: pendingchaos: you can have that easier
21:10 karolherbst: I can switch without restarting X
21:10 lachs0r: pendingchaos: use update-alternatives
21:10 lachs0r: at least if your distro packages use that
21:10 karolherbst: well on a laptop you can
21:11 lachs0r: not on mine, actually
21:12 pendingchaos: karolherbst: how does one do that?
21:13 karolherbst: pendingchaos: LD_LIBRARY_PATH magic and a dummy DDX driver
21:13 lachs0r: proprietary driver only works with bumblebee crap. trying to use nvidia prime with modesetting just gives me a black screen :/
21:14 karolherbst: well it even works on a desktop with an intel GPU, but then intel needs to be your main gpu
21:18 lachs0r: I have to say things are a lot more responsive with nouveau than with nvidia, despite lack of reclocking etc.
21:18 annadane: i would love to use nouveau. unfortunately it crashes using anything :(
21:18 lachs0r: seems to be stable here as long as I don’t run the full piglit suite :D
21:19 lachs0r: but slow
21:19 annadane: i wonder if using the backported kernel in debian would help but i don't think so
21:19 lachs0r: but at least it doesn’t stall for ages every time something creates a gl context
21:20 lachs0r: I’d say not using debian on desktop helps in general
21:20 karolherbst: annadane: if application are crashing, then userspace is the problem, not the kernel ;)
21:22 lachs0r: unless you see nouveau errors in the kernel log
21:22 annadane: idk. i could probably diagnose this but i don't know how to