Lin Johnson <[email protected]> writes: > Ext_color_buffer_half_float is using type GL_HALF_FLOAT > and data_type GL_FLOAT. This fix Android CTS test > android.view.cts.PixelCopyTest > v2: remove commtens of Ext_color_buffer_half_float. > As Ext_color_buffer__float can use type GL_HALF_FLOAT > > Reviewed-by: Palli, Tapani <[email protected]> > Signed-off-by: Lin Johnson <[email protected]>
I've been looking into CTS issues on VC5, and I think this patch should
be reverted.
The issue is that the text above that in the spec disallows this case.
From GLES 3.0.2:
Only two combinations of format and type are accepted in most
cases. The first varies depending on the format of the currently
bound rendering surface. For normalized fixed-point rendering
surfaces, the combination format RGBA and type UNSIGNED_BYTE is
accepted. For signed integer rendering surfaces, the combina- tion
format RGBA_INTEGER and type INT is accepted. For unsigned integer
rendering surfaces, the combination format RGBA_INTEGER and type
UNSIGNED_INT is accepted.
[...]
ReadPixels generates an INVALID_OPERATION error if the combination
of format and type is unsupported.
and this spec adds on to that first paragraph:
For floating-point rendering surfaces, the combination
format RGBA and type FLOAT is accepted.
The second allowed combo is:
The second is an implementation-chosen format from among those
defined in table 3.2, excluding formats DEPTH_COMPONENT and
DEPTH_STENCIL . The values of format and type for this format may be
determined by calling Get- Integerv with the symbolic constants
IMPLEMENTATION_COLOR_READ_FORMAT and IMPLEMENTATION_COLOR_READ_TYPE
, respectively.
The failing cases are in the CTS's packed_pixels testsuite, such as:
KHR-GLES3.packed_pixels.pbo_rectangle.r11f_g11f_b10f
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
