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