10:52pendingchaos: imirkin_: thoughts on the nv50_miptree::multisampling thing?
11:31imirkin: pendingchaos: my thought is that i hate it :)
11:31imirkin: it's entirely artificial
11:32imirkin: remind me what you need it for?
11:38pendingchaos: it's so that a texture with nr_samples=1 can be used with programmable sample locations
11:38pendingchaos: 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:38pendingchaos: I'm fine with removing it though
11:40pendingchaos: "it's entirely artificial"?
11:44imirkin: pendingchaos: why couldn't you use programmable sample locations with a texture with nr_samples == 0?
11:45imirkin: presumably programmable sample locations depend on whether multisampling is enabled or not
11:46imirkin: gallium doesn't need to defend against wrong usage by the state tracker
11:46imirkin: "it's entirely artificial" == "there is absolutely no difference whether a texture is nr_samples == 1 or == 0"
13:56pendingchaos: imirkin: what should I do about Reviewed-By tags for patches 1, 2, 3 and 5? "Previous-Version-Reviewed-by: ..."?
13:57imirkin_: 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:57imirkin_: if you made insignificant changes, keep the r-b as well
13:57imirkin_: significant changes should go through another round of review
13:58imirkin_: it's on you to determine the level of significance
13:58imirkin_: 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:02pendingchaos: patch 1 is pretty insignificant I think
14:02pendingchaos: 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:03pendingchaos: 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:05pendingchaos: 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:12pendingchaos: *I think the changes to patch 5, like patch 1, is pretty insignificant ...
15:05imirkin_: 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:09pendingchaos: patches sent... hopefully they're good enough
15:12pendingchaos: 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
18:44gdk: hello, I've been loking at a shader disassembled with envydis
18:44gdk: and I found the "a2d" texture type being used with the texs instruction
18:45gdk: does anyone know what that means, and how is it different from "t2d"?
18:45gdk: (guessing that t2d means Texture2D or something like that)
18:49imirkin_: i.e. sampler2DArray
18:51gdk: ah thanks
18:51gdk: what the input register values are in this case?
18:52gdk: guessing that "REG_08" is array index
18:52imirkin_: array value (16-bit integer) followed by x and y (at least for TEX
18:52gdk: and "REG_20" os tex coord
18:52imirkin_: i gave you a link
18:52imirkin_: which explained how TEX works
18:53imirkin_: what order arguments come in
18:53imirkin_: for TEXS, it may be different, but you're on your own -- i have no clue.
18:54gdk: thanks, looking the shader I have here it seems that its the same for texs aswell
18:54gdk: as the first input register is a integer
20:18mslusarz: would there be any opposition to dropping VEX repo and rebasing all mmt branches on top of upstream Valgrind?
20:18imirkin_: there'd be opposition to stuff not working
20:19imirkin_: as long as that doesn't change, happy with whatever :)
20:20mslusarz: all existing branches will have exactly the same code, so nothing should break
20:21mslusarz: submodule stuff (VEX) is annoying to clean up, so once I push everything I'd recommend recloning
21:07mslusarz: done, I also added mmt-3.13 branch
21:08imirkin_: can you also update the instructions
21:08imirkin_: on the wiki page
21:12mslusarz: also done
21:14imirkin_: most excellent, thanks