01:01reinuseslisp: should I report envydis (potential) bugs here or on the github page? VMAD can take H1 heights on the first operand
01:10imirkin: better send patches to fix it :)
01:43rhyskidd: mslusarz: thanks for the fresh pair of eyes on my mmt rebase branch
02:55imirkin: reinuseslisp: right ... so obviously the us16's are going to be in terms of h0/h1, and us8 are going to be b0..3
02:57imirkin: i'd make 5f00_3 just hang off of the 5f00_0 definitions ... that way you don't have to do anything too crazy with the masks
03:16reinuseslisp: vmad s16 h1 $r20 $r51 u8 b0 $r52 $r53
03:16reinuseslisp: vmad $r20 s16 h1 $r51 u8 b0 $r52 $r53
03:17imirkin: #2 sounds right
03:18reinuseslisp: there are other instructions using 5f00_3, I guess I'll rename it
03:19imirkin: probably equally in need of fixing though
03:19imirkin: all v* ops
03:19imirkin: (i would guess)
03:19imirkin: do a spot check on a few
03:19imirkin: if they pan out, assume they all do
03:22imirkin: skeggsb: hopefully i'll have time to do a proper bring-up of high-bpc hdmi and yuv420 by the time next kernel rolls around
03:40reinuseslisp: yup, they have the same behavior
03:43imirkin: instructions with weird modes require a lot more attention
03:43imirkin: since the v* ops never get used
03:44imirkin: i don't think too much attention was given to their details
04:04mooch: xmad = extra mad vmad = very mad :D
04:10reinuseslisp: what about H instructions?
04:10reinuseslisp: (at mooch)
04:11imirkin: those should be good.
04:11mooch: i dunno lol
04:11mooch: i'm just joking
04:11imirkin: oh, in that analogy...
04:12imirkin: half mad?
04:15HdkR: Hulking mad
04:55endrift: hardly mad
09:32RSpliet: howling mad?
10:07mupuf: RSpliet: that's quite an original one :)
12:27RSpliet: mupuf: On the contrary, it's a reference to the A-team ;-)
12:30mupuf: RSpliet: oh well... I guess my lack of pop culture shows
12:51karolherbst: imirkin: mhhh, calling nouveau_pushbuf_new a second time on the same channel+client causes weird issues :/
12:51karolherbst: even if the pushbuf isn't used
12:52karolherbst: ohhh, wait... maybe it is my mistake, nvm
15:16orbea: karolherbst: I went back to commit 8b58a14ef76f6d6e6c71fff2cb5c8fa6662a1882 from May 2 2018 and kmscube still doesn't render anything remotely resembling a cube. I'm not sure its a mesa regression, but I can go back farther if its still possible?
15:16karolherbst: orbea: no idea if it's a regression. But I would assume it used to work otherwise people would have complained earlier already
15:16karolherbst: orbea: is this 18.1?
15:17karolherbst: 8b58a14ef76f6d6e6c71fff2cb5c8fa6662a1882 I mean
15:17orbea: I'm not sure, I'm building the git master
15:17karolherbst: ohh 18.2-devel
15:17orbea: err not master
15:17karolherbst: I would at least test one 18.0 and 18.1 release
15:17karolherbst: maybe even 17.3
15:17karolherbst: depending on if the issue already existed inside 18.y
15:17orbea: is there a way to see what commits correlate to versions?
15:18karolherbst: orbea: just do a git checkout $tag ;)
15:18karolherbst: but we also have that VERSION file
15:18orbea: ah, I see, thanks
15:18karolherbst: orbea: git checkout mesa-18.0.5 eg
15:19orbea: doing that now :)
16:10orbea: karolherbst: okay, 18.0.5 works :) *starts bisecting*
19:13orbea: karolherbst: finally...first bad commit is 2052dbdae363f4fd184842733ff9c96bd6e7f08c
19:14orbea: Is that a nvidia dev?
19:15karolherbst: yeah, but well, the tegra mesa driver uses the nouveau stuff
19:15karolherbst: imirkin: any idea why that patch breaks kmscube?
19:15orbea: breaks as in a bunch of glitched horizontal lines instead of a cube, the colors are right at least...
19:17karolherbst: orbea: what GPU?
19:18karolherbst: mhh, interesting
19:19karolherbst: orbea: can you verify that nvc0_resource_create_with_modifiers or nvc0_query_dmabuf_modifiers are called when running kmscube?
19:19karolherbst: gdb or something
19:19karolherbst: add a printf
19:19karolherbst: I don't see that the old path should have changed, so I assume it goes into one of those functions for whatever reason
19:20orbea: i'll try printf
19:20karolherbst: mhh, but maybe that "whandle->modifier = nvc0_miptree_get_modifier(mt);" does something
19:42orbea: karolherbst: seems to be entering nvc0_resource_create_with_modifiers, but not nvc0_query_dmabuf_modifiers
19:44orbea: tested with these printfs http://dpaste.com/24MQENY.txt and got this output http://dpaste.com/1NRWADK.txt
19:46karolherbst: huh, but there is nvc0_query_dmabuf_modifiers in the log
19:47orbea: yea, those are printf before each function is called, but it deosn't seem to actually enter it
19:51orbea: huh,that patch swallowed the \n in the printf when pasted :P
19:54mslusarz: rhyskidd: np