summaryrefslogtreecommitdiffstats
path: root/src/util
diff options
context:
space:
mode:
authorJason Ekstrand <[email protected]>2016-09-12 08:18:53 -0700
committerJason Ekstrand <[email protected]>2016-09-12 16:52:10 -0700
commit24be6306609179efddfb7e5cc6ec5d6a335c9b88 (patch)
treebdfcbd350332a352e63dd368237953e63fdbea0f /src/util
parent2519237c2495adb9564062eed6b9cd225b886dc0 (diff)
Revert "i965: Drop the maximum 3D texture size to 512 on Sandy Bridge"
This reverts commit 6ba88bce64b343761aabe3a6c7ee285c6020a959. The commit was erroneous because GL has a separate limit, GL_MAX_FRAMEBUFFER_LAYERS which guards the number of layers you are allowed to render into. The GL 4.5 spec says: "The framebuffer attachment point attachment is said to be framebuffer attachment complete if [...] all of the following conditions are true: [...] If image is a three-dimensional, one- or two-dimensional array, or cube map array texture and the attachment is layered, the depth or layer count of the texture is less than or equal to the value of the implementation-dependent limit MAX_FRAMEBUFFER_LAYERS." and goes on to say that "framebuffer complete" requires all attachments to be "framebuffer attachment complete". On Sandy Bridge, we set GL_MAX_FRAMEBUFFER_LAYERS to 512 so creating a 3D texture bigger than 512 is fine; you just can't render into all of the slices at once. Fixes ES3-CTS.gtf.GL3Tests.npot_textures.npot_tex_image on Sandy Bridge Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
Diffstat (limited to 'src/util')
0 files changed, 0 insertions, 0 deletions