On Wed, Oct 3, 2018 at 10:59 AM Koenig, Christian <christian.koe...@amd.com> wrote: > > Am 03.10.2018 um 16:56 schrieb Ilia Mirkin: > > On Wed, Oct 3, 2018 at 9:36 AM Christian König > > <ckoenig.leichtzumer...@gmail.com> wrote: > >> What the heck are you talking about? As far as I can see this patch is > >> about adding hw specific alignment to vlVaCreateImage which is a state > >> tracker function. > >> > >> Completely agree that vlVaGetImage should respect the parameters given > >> instead of using the one from the surface, but that sounds like a > >> different problem. > >> > >> Maybe mixing mail threads? > > The stated reason (when I originally asked why this was being done) > > was that vlVaGetImage would overwrite bits past the image created with > > vlVaCreateImage (because it uses the full surface size, rather than > > the x/y/width/height clipped to both the image and the surface). My > > comment was that the fix needs to go into vlVaGetImage, not into > > vlVaCreateImage. > > Ah! Yeah, as I said that is a problem on it's own. > > But what Deepak is trying to address here really sounds like a problem > in a deeper layer. addrlib is really not aligning the resulting texture > correctly when we see problems like that.
That was not my understanding. vlVaCreateImage creates a linear image, not a render surface. vlVaGetImage then writes data to it, and goes way over because the underlying surface's dimensions are larger than the image's (because the underlying surface *does* have the proper alignment). But perhaps I misunderstood. Either way, I think we're in agreement that vlVaGetImage needs fixing :) -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
