On 15 September 2012 09:37, José Fonseca <<a href="mailto:jose.r.fonseca@gmail.com" target="_blank">jose.r.fonseca@gmail.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On Fri, Sep 14, 2012 at 11:22 PM, Carl Worth <<a href="mailto:cworth@cworth.org">cworth@cworth.org</a>> wrote: > Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> writes: >> I think you're right, Jose. And unless I'm much mistaken, Mesa has never >> followed this rule correctly. > > Cool, an implementation bug! > >> Carl, would you mind sending me the test program you were using to >> investigate this? I'd like to try it on my nVidia machine. Assuming >> that the nVidia driver follows the spec, I'll file a Mesa bug report. > > Sure thing. It's attached. The program initializes a 2x2 RGB texture > with 12 bytes of data, (so according to José's understanding of the > specification). And according to that interpretation it should result in > a texture with 4 texels, all green. > > When I run this with Mesa, I get 2 green pixels, then one blue, then one > of uncertain color as Mesa reads past my allocated array, (and > triggering an error if you run the program under valgrind). > > I'll be quite interested to see what you find. </div></div>I tried on my NVIDIA, and it also shows green green blue black. I read the spec more detailed, and it seems that "element" is a single channel (not a pixel), where a "group" is a pixel. I've pushed a change that tries to match the spec precisely. I've checked that it does the right thing with Paul's sample. Jose </blockquote></div> Ok, thanks for checking into this in more detail, Jose. If I understand correctly now, it sounds like there is no Mesa bug after all.