Ogre Forums

Posted: **Wed Dec 02, 2015 3:36 pm**

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 ]

Posted: **Wed Dec 02, 2015 6:52 pm**

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.

Posted: **Thu Dec 03, 2015 7:28 am**

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.

Posted: **Thu Dec 03, 2015 7:59 am**

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

Ogre Forums

strange HardwareVertexBuffer design

strange HardwareVertexBuffer design

Re: strange HardwareVertexBuffer design

Re: strange HardwareVertexBuffer design

Re: strange HardwareVertexBuffer design