10:52 pendingchaos: imirkin_: thoughts on the nv50_miptree::multisampling thing?
11:31 imirkin: pendingchaos: my thought is that i hate it :)
11:31 imirkin: it's entirely artificial
11:32 imirkin: remind me what you need it for?
11:38 pendingchaos: it's so that a texture with nr_samples=1 can be used with programmable sample locations
11:38 pendingchaos: the only user of programmable sample locations, the mesa state tracker, currently doesn't make such situations possible, but I thought it was a harmless thing that improved correctness
11:38 pendingchaos: I'm fine with removing it though
11:40 pendingchaos: "it's entirely artificial"?
11:44 imirkin: pendingchaos: why couldn't you use programmable sample locations with a texture with nr_samples == 0?
11:45 imirkin: presumably programmable sample locations depend on whether multisampling is enabled or not
11:46 imirkin: gallium doesn't need to defend against wrong usage by the state tracker
11:46 imirkin: "it's entirely artificial" == "there is absolutely no difference whether a texture is nr_samples == 1 or == 0"
12:42 pendingchaos:nods agreeingly
13:56 pendingchaos: imirkin: what should I do about Reviewed-By tags for patches 1, 2, 3 and 5? "Previous-Version-Reviewed-by: ..."?
13:57 imirkin_: well, the general thing to do is to keep R-b's if they're like "with small change X, r-b" and you do only small change X
13:57 imirkin_: if you made insignificant changes, keep the r-b as well
13:57 imirkin_: significant changes should go through another round of review
13:58 imirkin_: it's on you to determine the level of significance
13:58 imirkin_: and the relationship polices abuse -- i.e. if you stick my r-b on something after making changes i consider huge, then i'll yell at you the first time and never review your changes after the second time
14:02 pendingchaos: patch 1 is pretty insignificant I think
14:02 pendingchaos: for patches 2 and 3, I had to change the patches to implement EvaluateDepthValues(), adding a method to pipe_context and creating a mostly-passthrough function in the state-tracker for it
14:03 pendingchaos: I think the changes to 2 and 3 should be reviewed, though I want to make it clear that someone has already looked over most of it
14:05 pendingchaos: I think patch 5 is also pretty insignificant, it just adds GL_ARB_sample_locations and GL_NV_sample_locations to the 18.2.0 release notes
14:12 pendingchaos: *I think the changes to patch 5, like patch 1, is pretty insignificant ...
15:05 imirkin_: pendingchaos: you can also say Reviewed-by: foo (vN). However if there have been substantial changes, i tend to just drop it entirely. maybe mention it in the notes below the ---
15:09 pendingchaos: patches sent... hopefully they're good enough
15:12 pendingchaos: imirkin_: it seems I forgot the copyright header for nv50_ir_dump.cpp and nv50_ir_dump.h btw, so I'll be sending a new version with them after the current one has been looked at
15:14 imirkin_: ok
18:44 gdk: hello, I've been loking at a shader disassembled with envydis
18:44 gdk: and I found the "a2d" texture type being used with the texs instruction
18:45 gdk: does anyone know what that means, and how is it different from "t2d"?
18:45 gdk: (guessing that t2d means Texture2D or something like that)
18:47 imirkin_: array2d
18:49 imirkin_: i.e. sampler2DArray
18:51 gdk: ah thanks
18:51 gdk: what the input register values are in this case?
18:52 gdk: guessing that "REG_08" is array index
18:52 imirkin_: array value (16-bit integer) followed by x and y (at least for TEX
18:52 gdk: and "REG_20" os tex coord
18:52 imirkin_: i gave you a link
18:52 gdk: is*
18:52 imirkin_: which explained how TEX works
18:53 imirkin_: what order arguments come in
18:53 imirkin_: for TEXS, it may be different, but you're on your own -- i have no clue.
18:54 gdk: thanks, looking the shader I have here it seems that its the same for texs aswell
18:54 gdk: as the first input register is a integer
20:18 mslusarz: would there be any opposition to dropping VEX repo and rebasing all mmt branches on top of upstream Valgrind?
20:18 imirkin_: there'd be opposition to stuff not working
20:19 imirkin_: as long as that doesn't change, happy with whatever :)
20:20 mslusarz: all existing branches will have exactly the same code, so nothing should break
20:20 imirkin_: excellent
20:21 mslusarz: submodule stuff (VEX) is annoying to clean up, so once I push everything I'd recommend recloning
21:07 mslusarz: done, I also added mmt-3.13 branch
21:08 imirkin_: can you also update the instructions
21:08 imirkin_: on the wiki page
21:12 mslusarz: also done
21:14 imirkin_: most excellent, thanks