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