00:51 rtcm: already had two reports of this in gnome, anyone knows what's going on? https://bugs.freedesktop.org/show_bug.cgi?id=89842
00:53 airlied: skeggsb: ^
05:04 Robert-:#ATW-RO :)
13:13 RSpliet: imirkin, imirkin_: what's an MRT?
13:14 imirkin_: heh
13:14 imirkin_: it's a very poorly chosen acronym
13:14 imirkin_: or rather
13:14 imirkin_: multiple render targets
13:14 imirkin_: so having "an" MRT doesn't make a ton of sense
13:14 imirkin_: but it's basically a reference to one of many render targets in a multi-color-buffer situation
13:15 RSpliet: haha ok, I'm not sure if I completely follow
13:15 RSpliet: why is this only relevant in a multi-colour buffer?
13:16 imirkin_: MRT == multiple color render targets
13:16 imirkin_: RT = render target
13:16 imirkin_: M = multiple :)
13:16 imirkin_: is this question in reference to something in particular?
13:16 RSpliet: well, no, just your patch-se raising curiousity to what they actually do
13:17 imirkin_: the freedreno support i pushed recently?
13:17 RSpliet: yep
13:17 imirkin_: yeah, so that was adding support for having up to 4 color render targets in a single render
13:17 imirkin_: GL 3.0 requies you to have 8
13:17 imirkin_: but... meh
13:17 imirkin_: the hw only supports 4 :)
13:17 imirkin_: (and GLES 3.0 only requires 4... coincidence?)
13:18 RSpliet: 4 colour render target as in "4 buffers", or something more complex?
13:18 imirkin_: ok
13:18 imirkin_: so
13:18 RSpliet: hehe, probably not
13:18 imirkin_: there's a fragment program
13:18 imirkin_: for every rasterized fragment
13:18 imirkin_: it runs
13:18 imirkin_: and outputs things
13:18 imirkin_: in GL1/2-land
13:18 imirkin_: "things" is a color, and optionally, a depth
13:18 RSpliet: "FP" is the same thing as "vertex shader"? :p
13:19 imirkin_: FP = fragment program
13:19 imirkin_: VP = vertex program (which runs per-vertex)
13:19 imirkin_: fragment is like a pixel
13:19 RSpliet: ah, so pixel-shader is the old term for that
13:19 imirkin_: but in a multi-sample universe, it's called a fragment
13:19 imirkin_: anyways
13:20 imirkin_: in GL3, in addition to depth
13:20 imirkin_: you can have up to 8 color attachments bound to a fbo
13:20 imirkin_: and the fragment program can output a different color for each one
13:20 imirkin_: each of which goes through the usual blending/etc logic
13:20 imirkin_: when you have more than 1 color attachment, it's known as MRT
13:21 imirkin_: (fbo = container for "the thing that we're rendering to")
13:21 RSpliet: "frame buffer object" I reckon?
13:21 imirkin_: yes, but that's not extremely descriptive :)
13:21 RSpliet: descripting enough for me :-)
13:22 imirkin_: for someone who doesn't already know what a framebuffer is. and if you know what a framebuffer is (in GL-speak), then you've heard of a fbo as well
13:22 RSpliet: so it will output different colours to the same offset in different buffers?
13:22 RSpliet: if you bind multiple buffers that is
13:22 RSpliet: ("render targets"
13:22 imirkin_: the same texel position, yes
13:22 RSpliet: ok, that makes sense
13:22 imirkin_: offset is a bit specific
13:22 RSpliet: "Texel" is an island :p
13:22 imirkin_: since they can have different formats
13:23 imirkin_: texel is like a pixel
13:23 RSpliet: colour formats you mean? or is there another mapping?
13:23 imirkin_: yes, color formats. but the RT's can also have different sizes (fun)
13:24 imirkin_: (why would you want this, you ask? i have no clue. but that's what ARB_framebuffer_object specifies.)
13:24 RSpliet: idk, I don't even see the point of MRT yet
13:24 RSpliet: in the end you still need to end up with 1 frame :p
13:24 glennk: a typical use case is g-buffers for deferred rendering
13:25 joi: and g in g-buffers stand for...
13:25 imirkin_: g is for "go away" :)
13:25 joi: :D
13:25 glennk: geometry, a bit weird but the abbreviation stuck
13:26 imirkin_: another use-case might be in a pre-GS world
13:26 imirkin_: of rendering multiple lighting angles or... something
13:27 imirkin_: but i know a lot less about how people actually use GL than what all you can do with GL
13:27 RSpliet: basically to benefit from hw blending rather than doing it yourself in your FP?
13:28 glennk: generally because you have more data to share between separate objects than will fit in one color buffer set of components
13:28 imirkin_: well, it's also the only way to output multiple things from one fp program
13:29 RSpliet: glennk: ah right, that makes sense :-)
13:29 RSpliet: thanks!
14:32 imirkin_: RSpliet: codegen/nv50_ir_emit_nv50.cpp:488:emitForm_MAD: Assertion `i->encSize == 8' failed.
14:32 imirkin_: http://hastebin.com/evidisomim.avrasm
14:33 imirkin_: i'm gonna go ahead and blame you for this one :p
14:33 imirkin_: EMIT: mad u32 $r6 u16 $r2h $r5l $r6 (4)
14:47 imirkin_: RSpliet: will you have some time to look at it soon, or should i revert the relevant change(s)?
14:48 imirkin_: or perhaps i can figure out wtf is going on...
14:52 imirkin_: RSpliet: looks like you only handled float, not int mad
15:34 RSpliet: ah yes, I didn't look at umad
15:34 imirkin_: RSpliet: i'm pushing a quick fix to just disable it for ints
15:35 imirkin_: but it may be nice if you could add the emission logic to reenable it
15:35 RSpliet: probably in a brainfart of "saturating doesn't make sense here, so why try to adjust existing code"
15:36 imirkin_: hehe
15:37 imirkin_: what you neglected is that OP_MAD was *hard* disabled for short forms before
15:38 RSpliet: yeah... the simplest fix right now is adding a check in CodeEmitterNV50::getMinEncodingSize
15:38 imirkin_: just pushed
15:39 RSpliet: that's... quick
15:39 imirkin_: i look fast ;)
15:39 imirkin_: there *are* 4-byte imad's though, so feel free to add support for it if you're interested
15:40 RSpliet: hehe, if I ever find the time for it
15:40 imirkin_: oh hm... i wonder if i have to disable the immediate thing too
15:40 RSpliet: are you sure btw? I recall checking but failing to find it
15:40 imirkin_: envydis has it
15:41 RSpliet: you mean the folding pass?
15:41 imirkin_: ya
15:43 RSpliet: I think so yes
15:43 RSpliet: btw, what are you testing?
15:43 RSpliet: not many programs require integers :p
15:43 imirkin_: RSpliet: well, robclark handed me a shader with a single IDIV, and it crashed. i was unhappy.
15:44 RSpliet: they're going to be important if OpenCL ever emerges
15:44 imirkin_: the immediate thing is more me thinking about what all else you did
15:44 RSpliet: but you're right, I should've looked at the integer case too
15:44 imirkin_: np. i totally forgot about it as well.
15:45 imirkin_: and apparently no piglit ever hit it
15:45 imirkin_: which is a little surprising
15:45 RSpliet: hardly, it's not trying hard to match src2 with dst
15:45 imirkin_: didn't you add a coalesce somewhere?
15:45 imirkin_: or did you end up getting defeated?
15:46 RSpliet: I was defeated by the logic... I thought it was fine doing it as part of adding constraints straight after liveness analysis
15:46 RSpliet: but it turned out not to be a "we're going to solve this constraint in RA", rather a "we'll just override whatever RA decides"
15:47 RSpliet: causing incorrect shaders even for Portal
15:47 imirkin_: wow, you really haven't had a lot of mesa contributions... before these, your last commits were to nv30 in 2012...
15:47 imirkin_: for some reason i thought you were a more frequent contributor
15:47 RSpliet: nope
15:47 RSpliet: I find kernels easier :p
15:48 imirkin_: hehe
15:49 RSpliet: and have a continuous lack of time
15:49 RSpliet: speaking of which, mupuf succesfully tested NVA0 reclocking
15:49 imirkin_: nice
15:50 imirkin_: ship it ;)
15:50 RSpliet: haha, kind of my idea
15:50 RSpliet: but not before I copy-paste voltage logic from nva3+
15:50 RSpliet: so as pmoreau has a higher chance of success
15:51 RSpliet: I might get an NV50 or NV92 tomorrow, which could help slash away parts for older cards
15:51 RSpliet: (hopefully even DDR2, but I won't get my hopes up too high)
15:51 imirkin_: yeah, iirc nv92 doesn't use 100da0
15:51 imirkin_: look through the traces i sent you ;)
15:51 imirkin_: nv50 might be a lost cause btw -- if it's weird, ignore it
15:51 RSpliet: that... could just as well imply it just never changes :-)
15:52 imirkin_: maybe. but there's a diff reg
15:52 imirkin_: 1007xx or so
15:52 imirkin_: which gets set to the same (but inverted) thing
15:52 imirkin_: and it's not per-partition
15:52 RSpliet: yeah, I'll make sure to give it a proper look when I can play around with it in real life
15:53 RSpliet: there's too little control over external trace (no coolbits, no hacked up VBIOSes)
15:53 RSpliet: makes it difficult to draw conclusions
16:28 imirkin: RSpliet: right. but you can see that it writes to a register you were doing nothing with earlier in its script :)