strange HardwareVertexBuffer design

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
dummy_98
Kobold
Posts: 38
Joined: Sat Oct 31, 2015 7:12 pm
x 1

strange HardwareVertexBuffer design

Post by dummy_98 »

http://www.ogre3d.org/forums/viewtopic.php?f=2&t=84533

i misunderstood about HardwareVertexBuffer design.

HardwareVertexBuffer have no independent buffer, it have shared buffer.

Code: Select all

  void* GLHardwareVertexBuffer::lockImpl(size_t offset, 
        size_t length, LockOptions options)
    {
        if(mIsLocked)
        {
            OGRE_EXCEPT(Exception::ERR_INTERNAL_ERROR,
                "Invalid attempt to lock an vertex buffer that has already been locked",
                "GLHardwareVertexBuffer::lock");
        }


        void* retPtr = 0;

        GLHardwareBufferManager* glBufManager = static_cast<GLHardwareBufferManager*>(HardwareBufferManager::getSingletonPtr());

        // Try to use scratch buffers for smaller buffers
        if( length < glBufManager->getGLMapBufferThreshold() )
        {
            // if this fails, we fall back on mapping
           [u][b] retPtr = glBufManager->allocateScratch((uint32)length)[/b][/u];


There are two problems here.

first it is not thread safe.
second , useless working....

first ....
this design can't work with thread.

Things like a paritcle, it should be able to update vertex buffer with thread.


second

Code: Select all

char* const pStartBuf = static_cast<char*>(hardwareBufferPtr->lock(HardwareBuffer::HBL_DISCARD));
....
hardwareBufferPtr->unlock()
it is useless in lock and unlock pattern , only Bring the memory and returns immediately....

that's all

This memory need not be........

i think hardwarebuffer must have independent memory..... with thread safe
[ maybe , independent memory buffer has to write opengl buffer when render object ]

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4445
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 909
Contact:

Re: strange HardwareVertexBuffer design

Post by dark_sylinc »

Hi,

Technically this is a 1.x design issue.

Second, lock() and unlock() have never been threadable in the first place. D3D9 had a serious performance issue if made threadsafe, and OpenGL just... trying to map a buffer from multiple threads is a world of pain.
This even holds true for 2.x buffers (didn't test if they can actually be mapped from multiple threads since like I said, OpenGL really makes this HARD).

Lock the buffer(s), then work with the data in multiple threads. Unlock when you're done from main thread.

dummy_98
Kobold
Posts: 38
Joined: Sat Oct 31, 2015 7:12 pm
x 1

Re: strange HardwareVertexBuffer design

Post by dummy_98 »

Lock the buffer(s), then work with the data in multiple threads. Unlock when you're done from main thread.
In the rendering part, it will solve it

Other issues still remain.

first :
(Lock the buffer) pointer is GLHardwareBufferManager's allocated memory.

Code: Select all

GLHardwareBufferManagerBase::allocateScratch(uint32 size)
It was restricted to SCRATCH_POOL_SIZE(1024 * 1024)
but many partice's full size is unknown........ I can not predict.

----------------------------------------------------------------------------
second:
//GLHardwareBufferManager's memory is not thread safe
//(it is singleton memory with no thread safe)
//in multi-thread , it can't allocate memory.
------- sorry i did not see mutex --------------------------------------



third :
GLHardwareBufferManager's alloc have 'line search algorithm- O(N)'
later , if main thread unlock all hardwarebuffer at a time , every time GLHardwareBufferManager's alloc will increasingly slow.... more and more until main thread unlock all

i think if GLHardwareVertexBuffer have independent memory, it need not memory allocation with 'line search algorithm-O(N)'

and it need not mutex ( allocation ,deallocation)
and limited size(SCRATCH_POOL_SIZE) will be free.
Last edited by dummy_98 on Thu Dec 03, 2015 8:10 am, edited 1 time in total.

dummy_98
Kobold
Posts: 38
Joined: Sat Oct 31, 2015 7:12 pm
x 1

Re: strange HardwareVertexBuffer design

Post by dummy_98 »

sorry

it is thread safe
i did't see
sorry

Code: Select all

 
	// simple forward link search based on alloc sizes
		// [u][b]not that fast [/b][/u]but the list should never get that long since not many
		// locks at once (hopefully)
            OGRE_LOCK_MUTEX(mScratchMutex);
[ above comment , "not many locks at once" , many lock is Ineffective ]

but if it is independent memory , need not mutex for synchronization


Looking back on it now
it can not process one hardwarebuffer of per thread ,
but It seems to be multithread of per hardwarebuffer unit

Post Reply