[Mesa-dev] [PATCH] i965: Require pixel alignment for GPU copy blit

Cody Northrop cody at lunarg.com
Tue Sep 23 08:13:19 PDT 2014


Thanks, Neil.

Yeah, I had the same thoughts regarding whether it is a valid offset.  The
trace does render correctly on Nvidia proprietary driver, but renders even
worse on Intel Windows driver (blank white screen after the bubbles pass).
I believe it used to render correctly on Windows, but maybe the driver has
marched on.

Since the i965 driver is capable of handling the offset with software
fallbacks (which it used to before the internal format change), seems
reasonable to continue supporting it.

-C

On Tue, Sep 23, 2014 at 6:54 AM, Neil Roberts <neil at linux.intel.com> wrote:

> I just noticed this wording in the GL spec regarding buffer objects:
>
> “Clients must align data elements consistent with the requirements of
> the client platform, with an additional base-level requirement that an
> offset within a buffer to a datum comprising N basic machine units be a
> multiple of N.”
>
> I wonder if that means putting pixels in a buffer that are not naturally
> aligned to the bpp is not valid. It's not really clear though because
> potentially you could say that the size of the datum of the pixel data
> is 1 because the type parameter in glTexImage2D is GL_UNSIGNED_BYTE.
> However if you were to upload the data as GL_UNSIGNED_INT_8_8_8_8_REV
> then it would be a different story.
>
> I guess either way though the patch doesn't do any harm though and it's
> good if it fixes a real-world use case.
>
> - Neil
>
> Neil Roberts <neil at linux.intel.com> writes:
>
> > This patch looks good to me.
> >
> > The wording in the bspec seems a little vague so I was wondering if
> > maybe the real restriction is that the offset must be 4-byte aligned
> > rather than being aligned to the bpp. However I tried it with a 16-bit
> > type and sure enough it works to have an offset aligned to two bytes.
> >
> > Reviewed-by: Neil Roberts <neil at linux.intel.com>
> >
> > - Neil
> >
> > Cody Northrop <cody at lunarg.com> writes:
> >
> >> The blitter will start at a pixel's natural alignment. For PBOs, if the
> >> provided offset if not aligned, bits will get dropped.
> >>
> >> This change adds offset alignment check for src and dst, kicking back if
> >> the requirements are not met.
> >>
> >> The change is based on following verbiage from BSPEC:
> >>  Color pixel sizes supported are 8, 16, and 32 bits per pixel (bpp).
> >>  All pixels are naturally aligned.
> >>
> >> Found in the following locations:
> >> page 35 of intel-gfx-prm-osrc-hsw-blitter.pdf
> >> page 29 of ivb_ihd_os_vol1_part4.pdf
> >> page 29 of snb_ihd_os_vol1_part5.pdf
> >>
> >> This behavior was observed with Steam Big Picture rendering incorrect
> >> icon colors.  The fix has been tested on Ubuntu and SteamOS on Haswell.
> >>
> >> Signed-off-by: Cody Northrop <cody at lunarg.com>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83908
>



-- 
 Cody Northrop
 Graphics Software Engineer
 LunarG, Inc.- 3D Driver Innovations
 Email: cody at lunarg.com
 Website: http://www.lunarg.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140923/e2311953/attachment.html>


More information about the mesa-dev mailing list