On Mon, Apr 30, 2018 at 3:11 PM, Eric Anholt <e...@anholt.net> wrote:
> Marek Olšák <mar...@gmail.com> writes: > > > From: Nicolai Hähnle <nicolai.haeh...@amd.com> > > > > Allow the caller to specify the row stride (in bytes) with which an image > > should be mapped. Note that completely ignoring USER_STRIDE is a valid > > implementation of mapImage. > > > > This is horrible API design. Unfortunately, cros_gralloc does indeed have > > a horrible API design -- in that arbitrary images should be allowed to be > > mapped with the stride that a linear image of the same width would have. > > > > There is no separate capability bit because it's unclear how stricter > > requirements should be defined. > > I think that this is a bad interface, and you should just push an extra > copy into the caller so that they're encouraged to fix their bad API > instead of pushing their mistake down into Mesa ABI that we get stuck > with forever. > I agree that it's a very bad interface. I would also like cros_gralloc not to do silly things. I don't know what kind of hardware gralloc is designed around - it's certainly not designed around modern GPUs, that part is clear. The emulation of the user-specified stride increases memory usage (especially if the stride is larger than necessary), so it's a bad idea by definition. I don't know if it's still possible to change gralloc not to use it. The reason the feature is pushed into the driver is that only the driver can efficiently force a certain stride where the stride is much larger than box.width*bpp of the mapping, and still only tile/detile box.width*bpp. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
