gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt - Issue 1870483003: Add command buffer support for GL_RGB CHROMIUM image emulation.

Side by Side Diff: gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt

Issue 1870483003: Add command buffer support for GL_RGB CHROMIUM image emulation. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Created 4 years, 8 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
1 Name	1 Name

2	2

3 CHROMIUM_gpu_memory_buffer_image	3 CHROMIUM_gpu_memory_buffer_image

4	4

5 Name Strings	5 Name Strings

6	6

7 GL_CHROMIUM_gpu_memory_buffer_image	7 GL_CHROMIUM_gpu_memory_buffer_image

8	8

9 Version	9 Version

10	10

(...skipping 33 matching lines...) Expand 10 before \| Expand all \| Expand 10 after Loading...
44 Returns a unique identifier for the image that could be used in	44 Returns a unique identifier for the image that could be used in

45 subsequent operations.	45 subsequent operations.

46	46

47 INVALID_VALUE is generated if <width> or <height> is nonpositive.	47 INVALID_VALUE is generated if <width> or <height> is nonpositive.

48	48

49 INVALID_ENUM is generated if <internalformat> is not one of	49 INVALID_ENUM is generated if <internalformat> is not one of

50 RGB or RGBA.	50 RGB or RGBA.

51	51

52 INVALID_ENUM is generated if <usage> is not READ_WRTIE_CHROMIUM.	52 INVALID_ENUM is generated if <usage> is not READ_WRTIE_CHROMIUM.

53	53

	54 On OS X, RGB internal format is not supported, and the created

	55 GpuMemoryBuffer will always have internal format RGBA. The caller is

	56 responsible for handling this appropriately. The only support provided by

	57 this extension is that calls to copyTexImage2D and copyTexSubImage2D will

	58 perform paramter validation as if the internal format were RGB.
	erikchen 2016/04/06 23:26:30 Assuming that everyone is happy with the general i Assuming that everyone is happy with the general idea of this approach, I think there are cleaner ways of supporting this mechanism in the CHROMIUM image API. 1. Add an additional parameter to CreateGpuMemoryBufferImageCHROMIUM (bool RGBEmulation). 2. Add an additional parameter to BindTexImage2DCHROMIUM (bool RGBEmulation). 3. Add a new function MarkImageAsRGBEmulationCHROMIUM(GLuint imageID) 4. [Keep mechanism here]. I'm not sure which one reveman@ will prefer, so I've held off on adding the plumbing for a new API call. Maybe (3), based on https://bugs.chromium.org/p/chromium/issues/detail?id=598050#c2, and the desire to keep this set of APIs as close as possible to EGL image extension APIs? reveman 2016/04/07 13:00:56 I don't think we should have workarounds as part o Show quoted text On 2016/04/06 at 23:26:30, erikchen wrote: > Assuming that everyone is happy with the general idea of this approach, I think there are cleaner ways of supporting this mechanism in the CHROMIUM image API. > > 1. Add an additional parameter to CreateGpuMemoryBufferImageCHROMIUM (bool RGBEmulation). > 2. Add an additional parameter to BindTexImage2DCHROMIUM (bool RGBEmulation). > 3. Add a new function MarkImageAsRGBEmulationCHROMIUM(GLuint imageID) > 4. [Keep mechanism here]. > > I'm not sure which one reveman@ will prefer, so I've held off on adding the plumbing for a new API call. Maybe (3), based on https://bugs.chromium.org/p/chromium/issues/detail?id=598050#c2, and the desire to keep this set of APIs as close as possible to EGL image extension APIs? I don't think we should have workarounds as part of extension specs. It should be limited to the implementation. Why do we need to mark the image as using RGB emulation? Can that not just be hardcoded as emulated on MacOS if format is equal to RGB? Ken Russell (switch to Gerrit) 2016/04/07 21:41:14 It seems reasonable to mention errata in the exten Show quoted text On 2016/04/07 13:00:56, reveman wrote: > On 2016/04/06 at 23:26:30, erikchen wrote: > > Assuming that everyone is happy with the general idea of this approach, I > think there are cleaner ways of supporting this mechanism in the CHROMIUM image > API. > > > > 1. Add an additional parameter to CreateGpuMemoryBufferImageCHROMIUM (bool > RGBEmulation). > > 2. Add an additional parameter to BindTexImage2DCHROMIUM (bool RGBEmulation). > > 3. Add a new function MarkImageAsRGBEmulationCHROMIUM(GLuint imageID) > > 4. [Keep mechanism here]. > > > > I'm not sure which one reveman@ will prefer, so I've held off on adding the > plumbing for a new API call. Maybe (3), based on > https://bugs.chromium.org/p/chromium/issues/detail?id=598050#c2, and the desire > to keep this set of APIs as close as possible to EGL image extension APIs? > > I don't think we should have workarounds as part of extension specs. It should > be limited to the implementation. Why do we need to mark the image as using RGB > emulation? Can that not just be hardcoded as emulated on MacOS if format is > equal to RGB? It seems reasonable to mention errata in the extension spec. Unfortunately, as has already been discussed at length on this bug and other CLs, it is impractical to completely hide the knowledge from users of this extension that GL_RGB type GLImages are emulated with the GL_RGBA type. Therefore this should be documented.
	59

54 Errors	60 Errors

55	61

56 None.	62 None.

57	63

58 New State	64 New State

59	65

60 None.	66 None.

61	67

62 Revision History	68 Revision History

63	69

64 9/29/2014 Documented the extension.	70 9/29/2014 Documented the extension.

OLD	NEW

« no previous file with comments | « no previous file | gpu/command_buffer/service/framebuffer_manager.h » ('j') | ui/gl/gl_image.h » ('J')