gpu: FBO must be incomplete if the attached texture is not cube complete.

gpu: FBO must be incomplete if the attached texture is not cube complete.

Section 4.4.4 "Framebuffer Completeness" of the ES 3.0.4 spec [1] says that if
the color attachment is a cube map texture and the texture isn't cube map
complete, then the framebuffer is incomplete.

Some drivers accept incomplete cube texture as FBO color attachment. This CL
strictly prevent incomplete cube texture from attaching FBO.

[1] https://www.khronos.org/registry/gles/specs/3.0/es_spec_3.0.4.pdf

TEST=gl_tests.GLCubeMapTextureTests/GLCubeMapTextureTest.ReadPixelsFromIncompleteFBO/*
BUG=518889

[dshwang, 2015-08-12 17:37:22]

dongseong.hwang@intel.com changed reviewers:
+ kbr@chromium.org, sievers@chromium.org

[dshwang, 2015-08-12 17:37:22]

This CL depends on https://codereview.chromium.org/1280163004

As we discussed in https://codereview.chromium.org/1280163004/#msg14, gpu
command buffer allows incomplete cube texture as FBO attachment. This CL emits
GL_INVALID_FRAMEBUFFER_OPERATION error explicitly.

[dshwang, 2015-08-17 07:10:09]

sievers, could you review this CL as follower of
https://codereview.chromium.org/1280163004 ?

[dshwang, 2015-08-17 16:12:50]

dongseong.hwang@intel.com changed reviewers:
+ piman@chromium.org

[dshwang, 2015-08-17 16:13:18]

On 2015/08/17 07:10:09, dshwang wrote:
> sievers, could you review this CL as follower of
> https://codereview.chromium.org/1280163004 ?

Now it depends on https://codereview.chromium.org/1299683002, so postpone review
until the CL is landed.

[no sievers, 2015-08-17 20:44:32]

What about ES2 and webgl? Did ES3 become stricter here?
For EGL we request a v2.0 client API, for desktop we still use the compatibility
profile, but it doesn't seem to mention differences.

[Ken Russell (switch to Gerrit), 2015-08-17 21:52:35]

On 2015/08/17 20:44:32, sievers wrote:
> What about ES2 and webgl? Did ES3 become stricter here?
> For EGL we request a v2.0 client API, for desktop we still use the
compatibility
> profile, but it doesn't seem to mention differences.

I think I made a mistake when reading section 4.4.4 "Framebuffer Completeness"
in the ES 3.0 spec. The specific text is:

"If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is TEXTURE and the value of
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME does not name an immutable-format texture and
the value of FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL is not level_base, then the
texture must be mipmap complete, and if FRAMEBUFFER_ATTACHMENT_OBJECT_NAME names
a cubemap texture, the texture must also be cube complete."

I think this allows level 0 of the faces of a cube map texture (assuming its
base level is 0) to be bound as framebuffer object attachments even if the cube
map texture is not cube complete.

Sorry for my misreading of the spec. I'm not sure what the consequence is for
this CL. It was clear that there were problems performing ReadPixels operations
on some drivers while faces of cube map textures were bound as the FBO's color
attachments. I don't know whether driver bug workarounds will be needed, whether
Chromium will need to restrict the sorts of operations that can be performed in
this situation, etc. Dongseong, can you try to characterize better the failure
modes?

It's been found in the past on some Mac machines that cube map textures' faces
had to be allocated in the order defined implicitly by OpenGL:
GL_TEXTURE_CUBE_MAP_POSITIVE_X, GL_TEXTURE_CUBE_MAP_NEGATIVE_X,
GL_TEXTURE_CUBE_MAP_POSITIVE_Y, GL_TEXTURE_CUBE_MAP_NEGATIVE_Y,
GL_TEXTURE_CUBE_MAP_POSITIVE_Z, GL_TEXTURE_CUBE_MAP_NEGATIVE_Z. If they weren't
then the texture's contents would be corrupted. I wonder whether there's a
similar bug on the platforms where GLCubeMapTextureTest was crashing.

Rendering to cube maps' faces should be well tested; I'm not sure about the
ReadPixels path, especially in ANGLE.

[dshwang, 2015-08-18 08:09:03]

On 2015/08/17 21:52:35, Ken Russell wrote:
> On 2015/08/17 20:44:32, sievers wrote:
> > What about ES2 and webgl? Did ES3 become stricter here?
> > For EGL we request a v2.0 client API, for desktop we still use the
> compatibility
> > profile, but it doesn't seem to mention differences.
> 
> I think I made a mistake when reading section 4.4.4 "Framebuffer Completeness"
> in the ES 3.0 spec. The specific text is:
> 
> "If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is TEXTURE and the value
of
> FRAMEBUFFER_ATTACHMENT_OBJECT_NAME does not name an immutable-format texture
and
> the value of FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL is not level_base, then the
> texture must be mipmap complete, and if FRAMEBUFFER_ATTACHMENT_OBJECT_NAME
names
> a cubemap texture, the texture must also be cube complete."
> 
> I think this allows level 0 of the faces of a cube map texture (assuming its
> base level is 0) to be bound as framebuffer object attachments even if the
cube
> map texture is not cube complete.
> 
> Sorry for my misreading of the spec. I'm not sure what the consequence is for
> this CL. It was clear that there were problems performing ReadPixels
operations
> on some drivers while faces of cube map textures were bound as the FBO's color
> attachments. I don't know whether driver bug workarounds will be needed,
whether
> Chromium will need to restrict the sorts of operations that can be performed
in
> this situation, etc. Dongseong, can you try to characterize better the failure
> modes?
> 
> It's been found in the past on some Mac machines that cube map textures' faces
> had to be allocated in the order defined implicitly by OpenGL:
> GL_TEXTURE_CUBE_MAP_POSITIVE_X, GL_TEXTURE_CUBE_MAP_NEGATIVE_X,
> GL_TEXTURE_CUBE_MAP_POSITIVE_Y, GL_TEXTURE_CUBE_MAP_NEGATIVE_Y,
> GL_TEXTURE_CUBE_MAP_POSITIVE_Z, GL_TEXTURE_CUBE_MAP_NEGATIVE_Z. If they
weren't
> then the texture's contents would be corrupted. I wonder whether there's a
> similar bug on the platforms where GLCubeMapTextureTest was crashing.
> 
> Rendering to cube maps' faces should be well tested; I'm not sure about the
> ReadPixels path, especially in ANGLE.

Oh, I also misunderstood the spec although read the part several times. :(
This CL is one of my efforts to dig into nvidia bot failure of
https://codereview.chromium.org/1275773003/
My assumption is wrong about this CL.
I don't have Nvidia card, so I don't fully understand why Nvidia fails. 
Sorry for this noise and wrong speculation. Let me try to characterize better
the failure of https://codereview.chromium.org/1275773003/
I close it as INVALID.

[dshwang, 2015-08-18 08:44:46]

On 2015/08/17 21:52:35, Ken Russell wrote:
> Rendering to cube maps' faces should be well tested; I'm not sure about the
> ReadPixels path, especially in ANGLE.

ReadPixels path is covered by https://codereview.chromium.org/1290053004/