10:01 mwk:ponders pixel shaders on rankine
10:01 mwk: is there even a way to turn these off with the rankine classes?
10:03 mwk: as in, if I ask nicely, I can disable vertex shaders and use the fixed-function vertex pipeline instead, but there seems to be no corresponding switch for FPs, and the NV20 methods to control fixed-function texture sampling don't seem to have survived to nv30 classes
10:03 mwk: and yet, reg combiner methods still exist
11:02 imirkin: mwk: iirc there's a FP_CONTROL register we totally don't understand
12:52 pendingchaos: imirkin: seems due to a miscommunication between brian and myself, the 4th patch for ARB_sample_locations, the nvc0 one, was pushed before being given a Reviewed-By
12:52 pendingchaos: perhaps you or karolherbst can take a look at it sometime: https://lists.freedesktop.org/archives/mesa-dev/2018-June/196517.html?
12:53 pendingchaos: or should it maybe be reverted before being looked at?
12:54 karolherbst: pendingchaos: can you verify that we have at least no regressions with piglit?
12:55 pendingchaos: IIRC I ran piglit with the patches a while ago and things seemed fine
12:57 pendingchaos: it moves around a piece of code for pre-GM20x cards, but that should be rather low risk
12:57 karolherbst: pendingchaos: "bld.getBB()->remove(i);" afaik we usually ude delete_Instruction after an instrucion is unreachable
12:58 pendingchaos: it also changes how gl_SamplePosition is implemented on GM20x+, but I can't test that it still works on pre-GM20x
12:58 pendingchaos:nods
12:58 karolherbst: mhh, I see
12:59 karolherbst: pendingchaos: mhh, you change those NVC0_CB_AUX_* macros
12:59 karolherbst: I could imagine that the newer ones maybe be not available on older hardware
12:59 karolherbst: ohh wait
12:59 karolherbst: no, I am silly :D
12:59 karolherbst: this is the driver constbuf stuff
13:02 karolherbst: pendingchaos: mhh, the dirty bit NVC0_NEW_3D_SAMPLE_LOCATIONS is set on older hardware now, which will lead to validate_sample_locations be called, right?
13:03 karolherbst: I am wondering if we really have to do this on pre maxwell hardware though
13:03 pendingchaos: yeah, it should handle it though
13:04 karolherbst: mhh you moved that code out of the framebuffer validate function, right?
13:04 pendingchaos: right
13:04 karolherbst: yeah.. maybe that's better afterall
13:05 karolherbst: pendingchaos: I think we have a wrapper for memcpy inside mesa or gallium though
13:05 karolherbst: but... glibc should handle that good enough already
13:06 karolherbst: anyway, doesn't matter
13:07 karolherbst: pendingchaos: stuff looks fine, but I don't know much about that code. Anyway, if you remember me on Monday, I will run piglit on older hardware as well
13:10 pendingchaos: "remember me on Monday"?
13:11 karolherbst: yeah, to run piglit, otherwise I forget :p
13:12 pendingchaos: ah if I remind you on next Monday, the 18th, you can run the patches with piglit on older hardware?
13:18 RSpliet: pendingchaos: German and Dutch use the same word for reminding and remembering ;-)
13:19 pendingchaos: RSpliet: ah
13:19 pendingchaos: karolherbst: thanks for looking at it
13:58 karolherbst: ohh
13:58 karolherbst: I didn't even notice :D
20:00 Lyude: 22:15 <freenode#nouveau> <imirkin> Lyude: are you getting any other errors in dmesg? <-- just noticed this re: cursor flickering
20:00 Lyude: no unfortunately
20:01 imirkin_: figured might be some DISP errors
20:01 imirkin_: but i guess not
20:06 Lyude: mm... i may have just found the difference between before and after that patch that is causing the visual artifacts with the cursor, it looks like that patch just causes us to somehow stop updating the cursor layer through the evo channel
20:18 imirkin_: that certainly makes sense
20:19 imirkin_: the change detection logic might be a little fragile
20:19 imirkin_: lesseee here
20:20 Lyude: jfyi as well: I think this only happens with > 1 display
20:21 Lyude: and you saw the sha for the patch I bisected it to right?
20:21 imirkin_: mind pasting it again? (yes, i did see)
20:21 Lyude: yeah sure
20:21 Lyude: 5bca1621c07c3ad37b5a4943450a892e18984df0
20:21 imirkin_: but that was yesterday or whenever
20:22 imirkin_: gr, i forgot what asyw/asyh mean again =/
20:22 imirkin_: oh. w = window, h = head?
20:22 imirkin_: asy = asylum?
20:22 Lyude: async probably
20:24 imirkin_: skeggsb: you now have 2 lines like this in wndw.c: wndw->ctxdma.parent = &wndw->wndw.base.user;
20:24 Lyude: a-ha
20:24 Lyude: i knew the parent line looked suspecious
20:25 imirkin_: not that it matters
20:25 imirkin_: they're sequential
20:25 imirkin_: just ... unclean.
20:26 imirkin_: unfortunately the split into countless files makes the code un-follow-able
20:26 imirkin_: so you'll have to wait for skeggsb to have a look
20:27 Lyude: nah, i can fix it :)
20:27 Lyude: it is just a matter of tracking down the spot it's deciding that the cursor plane doesn't need updating
21:05 pendingchaos: imirkin: it seems *_warn is used in both ways: https://cgit.freedesktop.org/mesa/mesa/tree/src/compiler/glsl/glsl_parser.yy#n1193, https://cgit.freedesktop.org/mesa/mesa/tree/src/compiler/glsl/glsl_parser_extras.cpp#n845?
21:06 pendingchaos: there isn't much that creates a warning when an extension is used though
21:06 imirkin_: the latter is the warning that i was thinking of
21:06 imirkin_: the former looks like a bug
21:07 imirkin_: i guess we warn for enable *and* warn...
21:07 imirkin_: warn: Causes the named extension to work; however, using the extension will emit warnings. If used with all, then the use of any extensions will emit warnings.
21:07 imirkin_: huh ok
21:07 imirkin_: i was wrong.
21:08 pendingchaos: where did you find that?
21:08 imirkin_: https://www.khronos.org/opengl/wiki/Core_Language_(GLSL)
21:08 imirkin_: which isn't normative, but is generally not totally wrong
21:08 imirkin_: we totally fail at this in mesa...
21:09 imirkin_: interesting.
21:09 imirkin_: ok, in the glsl spec it says:
21:09 imirkin_: Behave as specified by the extension extension_name, except issue warnings
21:09 imirkin_: on any detectable use of that extension, unless such use is supported by other
21:09 imirkin_: enabled or required extensions.
21:10 imirkin_: (page 19 of the GLSL 4.40 spec)
21:10 imirkin_: yeah. we barely do that anywhere.
21:19 pendingchaos: it seems the code in the state tracker patch was luck based
21:25 imirkin_: yeah, you called the wrong function :)
21:26 imirkin_: shader caps use a different getter
21:26 pendingchaos: would also explain how I somehow never realized that shader caps are per-stage
21:26 pendingchaos: *would explain
21:28 imirkin_: i suspect that the use-case for the "warn" thing is #extension all: warn
21:28 imirkin_: when you want the damn shader to Just Work (tm)
21:34 Lyude: well that's fun
21:34 Lyude: despite having bisected it, this cursor bug doesn't look to be a kernel issue
21:35 Lyude: because all of the cursor ioctls stop getting called when the cursor starts flickering
21:36 Lyude: i have a very strong feeling this has to do with the new atomic modesetting ddx code
21:37 HdkR: <3 the load_store_formatted patches
21:38 HdkR: er, image_load_formatted
21:38 HdkR:says loadstore too often
21:58 karolherbst: imirkin_: well it is good to know what extensions you actually require, but all: warn will also print a couple of extensions you might not want to enable
21:59 imirkin_: not if you don't use them...
22:00 imirkin_: warn only warns if you actually make use of stuff
22:00 imirkin_: in theory.
22:00 karolherbst: yes
22:00 karolherbst: but at least glslang prints more than you actually would have to enable
22:00 imirkin_: ok, but that sounds like a bug in glslang :)
22:00 karolherbst: yeah
22:00 karolherbst: I have a compute shader where warn, warns about nothing
22:00 karolherbst: but
22:01 karolherbst: uhm
22:01 karolherbst: I mean, disable doesn't complain
22:01 karolherbst: but warn complains about GL_ARB_shading_language_420pack being used
22:01 imirkin_: that's a tough one to warn about.
22:01 karolherbst: well
22:01 karolherbst: I have set glsl to 430
22:01 imirkin_: it might actually be getting used :)
22:01 imirkin_: heh
22:01 karolherbst: ;)
22:01 imirkin_: ok, i figured it was like glsl 130
22:01 imirkin_: + warn all
22:02 karolherbst: well for compute shaders you need 430
22:02 karolherbst: or 420 with extension
22:02 imirkin_: 420pack adds the implicit conversions
22:02 imirkin_: so you could accidentally start "using" them
22:02 karolherbst: sure
22:02 karolherbst: but you don't have to enable that extension anyway if you just write a 420+ shader
22:02 imirkin_: yeah
22:03 karolherbst: it is kind of weird. I mean the idea is nice, but if implemented this way, then it is just noise
22:03 imirkin_: so it's like warn if ->has_foo() returns true, but disabling this ext would make it return false :)
22:03 karolherbst: right
22:03 imirkin_: or rather, disabling all the warn exts would make it return false
22:05 karolherbst: I hope it isn't a spec bug though... I filled enough spec bugs already these days
22:06 imirkin_: gets old after a while =/
22:07 pendingchaos: imirkin_: new patches sent, realized I forgot the v2 right after I sent them though
22:07 imirkin_: no worries
22:40 imirkin_: pendingchaos: were you hitting this? - assert(format->components != 0);
22:40 imirkin_: that should only happen in case of a BUG() situation...
22:40 imirkin_: i.e. a format is set, but we know nothing about it
22:41 pendingchaos: yes
22:41 pendingchaos: I think format is always non-NULL and when none is specified, components is 0?
22:41 imirkin_: oh
22:41 imirkin_: coz it's FMT_NONE?
22:41 imirkin_: which is not null
22:42 imirkin_: i see.