KHR_gl_texture_2D_image is broken on at least SNB for mipmap levels that fall outside of a tile boundary since the following commit:
Author: Eric Anholt <email@example.com>
Date: Wed Aug 28 12:06:31 2013 -0700
i965/gen7: Use the base_level field of the sampler to handle GL's BASE_LEVEL.
It seems that after this commit, the tile offsets set in intel_set_texture_image_region() are ignored.
Fix coming up. I've added some additional changes to completely remove x/y tiling offsets dependency and solely rely on level/layer fields in surface_state instead.
patch sent in mailing list for review.
What's the status of this bug? I see that the patches were sent in December and Jordan had a comment that needed addressing... and then nothing?
(In reply to comment #3)
> What's the status of this bug? I see that the patches were sent in December
> and Jordan had a comment that needed addressing... and then nothing?
The concerns that Jordan raised were from the complete removal of the tiled offsets. I didn't proceed with that direction because there were already some piglit failures on my implementation of the blorp fixes, as it only supported single-sampled layered rendering. I think Topi took over the removal of the tiling offsets tasks as it involved much more than my initial approach.
Patches 1-3 in the series, however, in itself fixed the KHR_gl_texture_2D_image bug mentioned in this report. Nobody commented on those specific patches.
On the other hand, I think Ander would like to remove the KHR_gl_texture_2D_image feature if I remember the discussion with him correctly? He might want to comment here what is the status of that decision.
(In reply to comment #4)
> On the other hand, I think Ander would like to remove the
> KHR_gl_texture_2D_image feature if I remember the discussion with him
> correctly? He might want to comment here what is the status of that decision.
I don't think that was ever my intention, but I couldn't find any real world users of the extension. I was doing some refactoring of the DRI image extension implementation in i965, and wanted to make sure it wouldn't break anything. There were some problems with that approach though, so I pursued a different one to achieve what I needed. As things stands now, I'm not blocked by this bug.