Re: Dynamic VBO mysteries on ES2

On Jan 4, 2011, at 2:44 PM, Andy O'Meara wrote:
>
> Thanks for your help, guys! You were indeed right that I had an issue lurking that was calling one of the vb bind commands to be skipped. *puts on hat of shame*
>
> With that, we now have our core content officially up and running under ES2 and under quad pixel mode as of today--WOW!
>
> The one question left is the use of per-frame dynamic textures (i.e. where you changing the texture contents each frame on the CPU side--not glFramebufferTexture2D). Ye old kGL_APPLE_client_storage and is of course available on OS X, but are there any options on ES2?
>
No client storage in iOS.
Changing texture every frame: I assume this texture contents is runtime variable otherwise there's a name for changing a texture every frame: a video. :) In this latter case consider CoreVideo.
If your texture updates are truly dynamic use the GPU to update them w/ an offscreen GPU if possible.
In any case make sure you make your texture updates at the beginning of the frame or you may cause an implicit flush.
Keep the bandwidth down by using lower precision or compressed textures if possible.
>
>
>
>
> On Jan 4, 2011, at 2:01 PM, Richard Schreyer wrote:
>
>>
>> Just to re-emphasise John's point, this is where you crash if your index pointer, vertex pointers, strides, etc, eventually point to garbage memory, as this is where our software performs the load when copying vertex data. You may be able to break in GDB, and look at the pointer that is the failing load, and see if you can map that backwards.
>>
>> Also check for any dangling array enables (somewhere where you didn't call glDisableVertexAttribArray()), as we'll happily dereference the pointers of any enabled array.
>>
>> Finally, as a performance point, you're seeing the same failure on the device too, which indicates that you're also seeing software vertex submission there. Something about the current vertex array state is causing us to fail to DMA the buffer object directly, requiring software re-packing.
>>
>
>
> On Jan 4, 2011, at 1:11 PM, Jason Green wrote:
>
>> Things to check to help narrow down the bug:
>>
>> * Are you drawing the right number of vertices? i.e., not causing overflows?
>>
>> * Does glBufferSubData() work as expected? (Yes, it will generally cause an extra copy and generate a sync point, but does it crash?)
>>
>> * Does it crash if you specify GL_STATIC_DRAW?
>>
>> * Does it crash if you provide a valid memory pointer for the initial glBufferData() call?
>>
>> * Your app might have memory stompers elsewhere which could be corrupting the state in some way. Can you reproduce this in a standalone test app?
>>
>>
>> Good luck, hope this helps!
>>
>> - Jason
>>
>> On Jan 4, 2011, at 1:48 PM, Andy O'Meara wrote:
>>
>>>
>>> Hey OpenGLers, does anyone know of any lurking issues or limitations for dynamic VBOs on ES2 (on iOS 4.2) using the glMapBuffer/glUnmapBuffer() approach?
>>>
>>> We've been doing high performance VBO stuff for years now on OGL and D3D, and I've done every regression I can think of, so I'd love to get an ideas with what we may be doing wrong (or if a radar needs to be filed). If the answer to all this turns out to be not to use glMapBuffer/glUnmapBuffer() on ES2, what methods yields the absolute best performance?
>>>
>>> We have a about a dozen 10k-50k dynamic VBOs that we use for different stuff.
>>>
>>> When one is made:
>>>
>>> struct ColorVertex {
>>> float mX, mY, mZ;
>>> float mTexU, mTexV;
>>> };
>>>
>>> enum {
>>> ATTRIB_VERTEX,
>>> ATTRIB_TEX_UV
>>> }
>>>
>>> glGenBuffers()
>>> glBindBuffer( GL_ARRAY_BUFFER, mVBO )
>>> glBufferData( GL_ARRAY_BUFFER, N * sizeof( ColorVertex ), NULL, GL_DYNAMIC_DRAW )
>>> glBindBuffer( GL_ARRAY_BUFFER, 0 )
>>>
>>>
>>> To write data (every frame):
>>>
>>> glBindBuffer( GL_ARRAY_BUFFER, mVBO )
>>> ColorVertex* vList = (ColorVertex*) glMapBuffer( GL_ARRAY_BUFFER, GL_WRITE_ONLY );
>>> ... write to vList ...
>>> glUnmapBuffer( GL_ARRAY_BUFFER )
>>> glBindBuffer( GL_ARRAY_BUFFER, 0 )
>>>
>>>
>>> When compiling the GLSL program:
>>> ...
>>> glAttachObject( mProgram, mShaderID )
>>> glBindAttribLocation( mProgram, ATTRIB_VERTEX, "inPos" )
>>> glBindAttribLocation( mProgram, ATTRIB_TEX_UV, "inTexCoord" )
>>> glLinkProgram( mProgram )
>>>
>>>
>>> To draw:
>>>
>>> glBindBuffer( GL_ARRAY_BUFFER, mVBO )
>>> glUseProgramObject( mProgram )
>>>
>>> glVertexAttribPointer( ATTRIB_VERTEX, 3, GL_FLOAT, GL_FALSE, sizeof( ColorVertex ), &( (ColorVertex*) NULL ) -> mTexU );
>>> glEnableVertexAttribArray( ATTRIB_VERTEX )
>>>
>>> glVertexAttribPointer( ATTRIB_TEX_UV, 2, GL_FLOAT, GL_FALSE, sizeof( ColorVertex ), &( (ColorVertex*) NULL ) -> mX );
>>> glEnableVertexAttribArray( ATTRIB_COLOR )
>>>
>>> glDrawArrays( ... ) // crash on both iOS4 and in the iPhone sim:
>>>
>>> #0 0x0a91a29e in gleRunVertexSubmitImmediate ()
>>> #1 0x0a9190e3 in gleLLVMArrayFunc ()
>>> #2 0x0a91908b in gleSetVertexArrayFunc ()
>>> #3 0x0a90fbc6 in gleDrawArraysOrElements_ExecCore ()
>>> #4 0x0a8f0f77 in glDrawArrays_Exec ()
>>> #5 0x00de7a94 in glDrawArrays ()
>>>
>>> glBindBuffer( GL_ARRAY_BUFFER, 0 )
>>>
>>>
>>> Regression/Notes:
>>>
>>> - No errors or warnings appear int he shader logs or via glGetError() get any point.
>>>
>>> - The same code works properly when running under normal OpenGL on OS X (with the appropriate modifications to the shader source and using glEnableClientState() and glVertexPointer() instead of glEnableVertexAttribArray() and glVertexAttribPointer()).
>>>
>>> - I tried the approach above as well as not using user-supplied attrib enums (and having ES2 return them via glGetAttribLocation()) -- no change.
>>>
>>> - If instead of glMapBuffer/glUnmapBuffer(), supply a user-side allocated buffer to glBufferData() won't performance be potentially poorer since the OGL will likely have to perform a copy at some point?
>>>
>>>
>>> Thanks in advance for any help!
>>>
>>> Andy
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

Apple Footer

This site contains user submitted content, comments and opinions and is for informational purposes only. Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.
Apple