2010/6/4 Jakob Bornecrantz <wallbra...@gmail.com>:
> 2010/6/4 Kristian Høgsberg <k...@bitplanet.net>:
>> This extension allows an application to make a context current by
>> passing EGL_NO_SURFACE for the write and read surface in the call to
>> eglMakeCurrent. The motivation is that applications that only want to
>> render to client API targets (such as OpenGL framebuffer objects)
>> should not need to create a throw-away EGL surface just to get a
>> current context.
>
> Looks good.
>
> Any reason this is a intel extension instead of a Mesa one?
I think it was something like "uh, we'll need some tokens for this
extension, if I make it an Intel extension I think we have a token
range we can use" or something. Will rename for tokens.
> Can you add a small spec file explaning it? Not that it needs much
> explaining. Tho it would be nice to know if glDrawBuffers(0, NULL) and
> then drawing something should raise a error? Or if rendering will be
> skipped?
Argh, I wrote a spec but forgot to git add it. Attached here.
> Feel like taking a stab at adding this to st/mesa, st/dri & st/egl?
I wouldn't know where to start :)
Kristian
Name
INTEL_no_surface
Name Strings
EGL_INTEL_no_surface
Contact
Kristian Høgsberg <k...@bitplanet.net>
Status
Proposal
Version
Version 1, May 28, 2010
Number
EGL Extension #not assigned
Dependencies
EGL 1.4 is required.
Written against wording of EGL 1.4 specification.
Overview
This extension allows an application to make a context current by
passing EGL_NO_SURFACE for the write and read surface in the call to
eglMakeCurrent. The motivation is that applications that only want to
render to client API targets (such as OpenGL framebuffer objects) should
not need to create a throw-away EGL surface just to get a current
context.
This extension introduces a new config attribute that indicates the APIs
that support binding a context with no surfaces. A config can be used
for making a context current with a value of EGL_NO_SURFACE for the
write and read surfaces.
For GL contexts, the state of the context until a FBO is created
and bound is the same as a context with an incomplete FBO bound.
Not all client APIs support FBOs or an FBO type mechanism and EGL will
only enable the bits for the APIs that allow this in
EGL_RENDERABLE_TYPE.
IP Status
There are no known IP issues.
Issues
1) Should this instead be its own config attribute? It would be
an API bitmask that indicate the APIs that allow using the config
to make a context current with no surfaces. That way we avoid
using up bits in the EGL_SURFACE_TYPE mask and avoid combinatorial
explosion in the number of configs if the ES1 API doesn't support
FBOs while ES2 does. That would otherwise require exposing one
set of configs with ES2 in the EGL_RENDERABLE_TYPE bitmask and
EGL_NO_SURFACE_BIT_INTEL and one set with ES1 in the
EGL_RENDERABLE_TYPE and no EGL_NO_SURFACE_BIT_INTEL.
Resolved: yes.
New Procedures and Functions
None
New Tokens
Accepted by the <Attribute> parameter of eglGetConfigAttrib and
the <attrib_list> parameter of eglChooseConfig:
EGL_NO_SURFACE_CAPABLE_INTEL 0xCD00
Additions to the EGL Specification
Add to table 3.1 (EGLConfig attributes):
Attribute Type Description
---------------------------- ------- ---------------------------------
EGL_NO_SURFACE_CAPABLE_INTEL bitmask EGLConfig supports making a context
current with EGL_NO_SURFACE for
write and read surfaces.
Additions to table 3.4, Default values and match criteria for
EGLConfig attributes:
Attribute Default Selection Criteria Priority
---------------------------- -------------- ------------------ ---------
EGL_NO_SURFACE_CAPABLE_INTEL EGL_DONT_CARE Mask
Add to section 3.4, "Configuration Management"
EGL_NO_SURFACE_CAPABLE_INTEL is a mask indicating the client APIs for
which the config can be used to make a context current with no surfaces
bound. The valid bit settings are the same as for EGL_RENDERABLE_TYPE,
shown in Table 3.3
If the bit corresponding the to the client API a context was made for is
set in EGL_NO_SURFACE_CAPABLE_INTEL, then the config can be used to make
a context current with no surfaces bound. This is done by passing
EGL_NO_SURFACE for the read and write surfaces in the call to
eglMakeCurrent. This can only be supported for client APIs that provide
a mechanism for configuring their own rendering targets, such as OpenGL
framebuffer objects.
The state of the context depends on the client API in use.
Currently only GL APIs with framebuffer object support are
supported and in this case the state it equivalent to having an
incomplete framebuffer object bound.
Revision History
June 3, 2010
Initial draft (Kristian Høgsberg)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
