On Thu, Dec 17, 2015 at 12:31 PM, Connor Abbott <cwabbo...@gmail.com> wrote: > On Thu, Dec 17, 2015 at 11:44 AM, Matt Turner <matts...@gmail.com> wrote: >> On Wed, Dec 9, 2015 at 4:15 AM, Iago Toral Quiroga <ito...@igalia.com> wrote: >>> Right now we rely on the code at the bottom of brw_set_dest to set the >>> correct execution size for anything that does not operate on a full SIMD >>> register (dst.width < BRW_EXECUTE_8). However, this won't work with fp64, >>> where operands are twice as big and we see instructions with a horizontal >>> width of 4 that still require an execution size of 8. We cannot fix this by >>> simply checking the type of the operands involved and skip the automatic >>> execsize adjustment when they are doubles because we can also operate on >>> doubles as integers (for pack and unpack operations for example). >> >> Can you give an example of when checking the type wouldn't be >> sufficient? Presumably packDouble2x32/unpackDouble2x32? What code do >> they generate? Could we look at the destination's stride as well? > > Yes, packDouble2x32 is what would cause the same issue, since it turns > into two 32-bit MOV's with a destination stride of 2 (and offset of 0 > and 1, ofc). We could check for the stride, but if we really don't > want to change this code, the better way to go would be to avoid the > width adjustment that causes this whole thing to happen for > destination registers, since everything other than this piece of code > ignores the destination width and vstride. But that being said, this > code is a hack since it breaks the assumption that fs_inst::exec_size > always equals the final ExecSize of the instruction, and Iago and I > agreed to fix it (or at least for now, do the portion of the fix > needed for fp64) rather than work around it.
Not sure if you guys are thinking about it, but a lot of these things that apply to doubles also apply to ARB_gpu_shader_int64. While you obviously don't need to support it now, you may want to keep it in mind as you make design decisions. Cheers, -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
