Bug 852 - Properly reflect OpenGL-core >= 3.1 and ES >= 3.0 API functions restricted to Buffer Objects
Summary: Properly reflect OpenGL-core >= 3.1 and ES >= 3.0 API functions restricted to...
Status: RESOLVED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 2
Hardware: All all
: --- enhancement
Assignee: Sven Gothel
URL:
Depends on: 764 765 789 929
Blocks: 821 1441
  Show dependency tree / graph
 
Reported: 2013-10-09 23:18 CEST by Sven Gothel
Modified: 2023-08-06 21:30 CEST (History)
6 users (show)

See Also:
Type: ---
SCM Refs:
4e83a5df7a851cc33d85f76381f058256906ad4c 8363df5da5794faf10478789954992cef0c0d50f 33db4580da46ba21771499fdf50489e60294e439 ac705f0d6eea7c8ba27a7cf7c42674c7446576b4
Workaround: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2013-10-09 23:18:37 CEST 
Properly reflect OpenGL-core >= 3.1 and ES >= 3.0 commands restricted to Buffer Objects

Core GL/ES interfaces shall not expose functions taking client side 
memory as an argument where only server side buffer objects are allowed (see below).

Said functions only allow to source the data from buffers already copied to the GPU.

Validation of above (bound buffer) shall be performed,
i.e. throw an exception if attempt to source data from client side memory.

+++

OpenGL 3.1 core spec 2.10 p41

Vertex Array Objects

"An INVALID_OPERATION error is generated if any of the *Pointer commands
specifying the location and organization of vertex array data are called while zero
is bound to the ARRAY_BUFFER buffer object binding point, and the pointer argu-
ment is not NULL."

- glVertexAttribPointer
- glVertexAttribIPointer
- 

+++

OpenGL 3.2 core spec 2.9.7 p45
OpenGL 4.0 core spec 2.9.7 p51

Draw* commands -w/ "Array Indices in Buffer Objects"

"If zero is bound to ELEMENT_ARRAY_BUFFER, the result of these drawing commands is undefined."

- DrawElements
- DrawRangeElements 
- DrawElementsInstanced 

"source their indices from the buffer object whose name is bound to ELEMENT_ARRAY_BUFFER..."

- DrawElementsBaseVertex
- DrawRangeElementsBaseVertex 
- DrawElementsInstancedBaseVertex 

"also source their indices from that buffer object..."

- MultiDrawElements 
- MultiDrawElementsBaseVertex 

"also source their indices from that buffer object..."

+++

OpenGL 4.0 core spec 2.9.8 p51:

Draw* Indirect Commands ..

"If zero is bound to DRAW_INDIRECT_BUFFER, the result of these drawing com-
mands is undefined."

- DrawArraysIndirect 
- DrawElementsIndirect 

+++

Related bugs Bug 764, Bug 765 and Bug 789
Comment 1 Sven Gothel 2013-10-10 13:19:39 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()
Comment 2 Sven Gothel 2013-11-01 05:56:31 CET 
33db4580da46ba21771499fdf50489e60294e439
  Add unit test TestCPUSourcingAPINEWT validating CPU sourcing, i.e. expecting exception w/ core profile!
Comment 3 Mark Raynsford 2013-12-12 00:14:48 CET 
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...
Comment 4 Mark Raynsford 2013-12-12 00:15:53 CET 
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.
Comment 5 Mark Raynsford 2013-12-12 20:07:08 CET 
Relevant discussion on Mesa tracker:

https://bugs.freedesktop.org/show_bug.cgi?id=72600
Comment 6 Sven Gothel 2013-12-13 22:29:34 CET 
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);
Comment 7 Sven Gothel 2013-12-20 17:41:24 CET 
Bug 925 Comment 1: Removed ES3/ES2 compatibility issue ..
Comment 8 Sven Gothel 2013-12-22 03:31:03 CET 
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