| Summary: | Properly reflect OpenGL-core >= 3.1 and ES >= 3.0 API functions restricted to Buffer Objects | ||
|---|---|---|---|
| Product: | [JogAmp] Jogl | Reporter: | Sven Gothel <sgothel> |
| Component: | core | Assignee: | Sven Gothel <sgothel> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | gouessej, julien.carlos, org.jogamp, rami.santina, sgothel, xerxes |
| Priority: | --- | ||
| Version: | 2 | ||
| Hardware: | All | ||
| OS: | all | ||
| Type: | --- | SCM Refs: |
4e83a5df7a851cc33d85f76381f058256906ad4c
8363df5da5794faf10478789954992cef0c0d50f
33db4580da46ba21771499fdf50489e60294e439
ac705f0d6eea7c8ba27a7cf7c42674c7446576b4
|
| Workaround: | --- | ||
| Bug Depends on: | 764, 765, 789, 929 | ||
| Bug Blocks: | 821, 1441 | ||
|
Description
Sven Gothel
2013-10-09 23:18:37 CEST
Remove CPU sourced data API entry where not allowed (ES3 and GL core >= 3.0)
Remove CPU sourced data API entries via new config 'BufferObjectOnly <name>',
listed in 'gl-common-gpubufferonly.cfg' and included in ES3 and all GL core >= 3 interfaces.
If BufferObjectOnly is defined for a function, only the 'long offset' variant is being emitted.
Due to limitations of GlueGen's 'ExtendedInterfaceSymbolsIgnore A.java', which only
identifies the function name and not the signature - all CPU sourced variants
are manually added to the compatibility and ES2 GL profiles via '*-common-cpubufferJavaCode.java' files.
GLContext: Added 'isCPUSourcedAvail()' to determine whether context allows CPU sourced data,
i.e. for GL2ES1 and GLES2 ctx.
GLContext/GLProfile/GL: isGLES2() now returns false if having a ES3 context due to 'CPU sourced'
incompatibility!
GL2 cfg: Ignore GL2ES3 symbols (super)
Validate CPU sourced data API is allowed, throw exception if not.
GLContext: isCPUSourcedAvail() -> isCPUDataSourcingAvail()
33db4580da46ba21771499fdf50489e60294e439 Add unit test TestCPUSourcingAPINEWT validating CPU sourcing, i.e. expecting exception w/ core profile! I'm not entirely sure this is correct for the ES3 case. I can't find anywhere in the ES3 spec that actually forbids cpu-sourced data. In fact, it seems to imply that client-side data is perfectly acceptable in multiple places. Section 2.9.7, pdf page 53 in the ES3 spec: "Initially zero is bound to ELEMENT_ARRAY_BUFFER, indicating that DrawElements (...) are to source their indices from arrays passed as their indices parameters." "Blocks of vertex array data may be stored in buffer objects with the same format and layout options supported for client-side vertex arrays." "Rendering command DrawArrays and the other drawing commands defined in section 2.8.3 operate as previously defined, except that data for enabled generic attribute arrays are sourced from buffers if the array's buffer binding is non-zero". And so on, and so on... The reason I bring this up is that the Mesa people have just asked me if it's actually a problem that they return an ES3 context instead of an ES2 one when asked, and I can't actually find evidence to suggest they aren't compatible. Relevant discussion on Mesa tracker: https://bugs.freedesktop.org/show_bug.cgi?id=72600 See Bug 925 tackling the ES3/ES2 compatibility issue and 'acceptance'. We won't add CPU sourced API entries to ES3 interface. However, since ES3 will be ES2 compatible w/ fix for Bug 925 a user can always use: glES3.getGLES2().gl*Pointer(..., cpuArray); Bug 925 Comment 1: Removed ES3/ES2 compatibility issue .. ac705f0d6eea7c8ba27a7cf7c42674c7446576b4
Bug 929, Bug 852 - Reflect ES3 Compatibility with ES2 / Add CPU Sourced Data API Func to ES3 Interface
Since ES3 is compatible w/ ES2 and CPU sourced data is [still] allowed (but marked deprecated),
re-adding them to the ES3 interface for completness.
Note: CPU sourced data API functions will be removed in ES4, similar to GL core >= 3.0
|