On Thu, Apr 02, 2015 at 06:29:24PM +0200, Lucas Stach wrote: > The start of the commands must always be 64bit aligned, it's the same > for all pipes. The size can be dword aligned if the last command in the > stream is something like SET_STATE with a length of 2. In that case one > needs to insert another padding dword, but as it's the end of the stream > userspace may omit that. > > So that more a question of policy: do we want userspace to always > specify the size including the padding and reject streams with a size > not double-dword aligned, or do we just fix it up in the kernel, as it's > equally easily done there. I was a bit on the fence here and decided to > go the "let the kernel fix things" route. Without really knowing the hardware, it's hard to say. However, they seem to be designed around a 64-bit architecture, and I would not be surprised if the front end DMA always fetches from the command buffer in 64-bit quantities. You mention SET_STATE, but the same applies to NOP, WAIT and all of the other commands for the 2D cores - the command word must always be in the first 32-bits of each 64-bit naturally aligned word in memory. Given that, my feeling (and it's only a feeling) is that it would be potentially dangerous to allow userspace to pass a buffer which isn't aligned. As you've found, the kernel would have to align the buffer size up to a 64-bit quantity to add the LINK command at the end anyway. So, I would err on the side of having userspace always do that, and we initially enforce that on the kernel side. If we find that's too strict, we can always relax the kernel side - and we still remain compatible with userspace. If we do the reverse, it's harder for the kernel to become more strict without breaking userspace. Given the "no regressions" rule, that's something we all want to avoid. :) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
