i915g: large mipmaps and npots fail.
The original problem is mutter-issue: Background wallpaper is blank on Intel Gen3.
Mutter/gnome uses by default a 4096x4096 picture and uses 4 2048x2048-mipmap-textures, to show them on screen. The mutter-team did not want to solve this issue by disable mipmapping and say the problem should be solved at the i915g-driver.
If a user selects an own npot-background, it will be slightly mangled by mipmapping, if it has to be downsized.
This MR solves 4 problems with mipmap on i915g.
-
i915g supports extension GL_OES_texture_npot at ES 2.0 and GL_ARB_texture_non_power_of_two at GL 2.1. At i945_texture_layout_2d() util_next_power_of_two() is called, which oversizes the npot-blocks for every level to get power of 2 for width and height. Hardware doesnot expect these oversized npot-blocks. The call should be removed. This also is necessary at i915_texture_layout_2d(), which is used by older gen3-gpus.
-
At update_map at i915_state_sampler.c max_lod is set to 1 for npots. This almost totally disables mipmapping. If GL_TEXTURE_MIN_FILTER is configured with MIPMAP_NEAREST, only LEVEL 0 is used, even for very small pictures. If GL_TEXTURE_MIN_FILTER is configured with MIPMAP_LINEAR, only LEVEL 0 and 1 are used, even for very small pictures. max_load should still be set to 1, but only if it is still 0, because no mipmap-levels are present. According to existing comment at update_map this is needed, to avoid problems at sampling, if MIN_FILTER and MAX_FILTER differ.
-
Generation of mipmaps is failing for large heights. If height > 1365 LEVEL 1 canot be generated because of the max texture size limit (2048). This is solved by using an offset at the texture-buffer at overflow situations. The height of the offset must be multiple of 8. This solves the problem mentioned at MR !27561 (closed).
-
Also the coding-error at i915_texture_layout_2d(), mentioned at MR !27677 (closed), implicitly is solved.