<div dir="ltr"><div>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. </div>-C </div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Sep 23, 2014 at 6:54 AM, Neil Roberts <<a href="mailto:neil@linux.intel.com" target="_blank">neil@linux.intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <div class="HOEnZb"><div class="h5"> Neil Roberts <<a href="mailto:neil@linux.intel.com">neil@linux.intel.com</a>> 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 <<a href="mailto:neil@linux.intel.com">neil@linux.intel.com</a>> > > - Neil > > Cody Northrop <<a href="mailto:cody@lunarg.com">cody@lunarg.com</a>> 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 <<a href="mailto:cody@lunarg.com">cody@lunarg.com</a>> >> Bugzilla: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=83908" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=83908</a> </div></div></blockquote></div> -- <div dir="ltr"><div> Cody Northrop Graphics Software Engineer LunarG, Inc.- 3D Driver Innovations Email: <a href="mailto:cody@lunarg.com" target="_blank">cody@lunarg.com</a> Website: <a href="http://www.lunarg.com/" target="_blank">http://www.lunarg.com</a></div></div> </div>