Ogre hardware buffer (hardware cache)

· Definition In fact, this buffer zone is a storage area of malloc, but it is not as good as that of malloc, which is applied in the memory, and the buffer zone is in the GPU/AGP, and its write and read speed is faster. Generally, the hardware buffer is used as the vertex buffer, index buffer, and Pixel Buffer. · Use Hardware buffer management is the hardwarebuffermanager responsible for a hardware cache manager, which is responsible for creating and releasing the buffer. It is the creation factory of the ry, and the single key will be created during root initialization. Therefore, when we need a piece of memory, we must not directly operate on new or malloc, instead Verbuf = hardwarebuffermanager: getsingleton (). createvertexbuffer () · Type When allocating a hardware buffer, we need to pass a parameter to specify the buffer type. Do we need to read and write frequently? This greatly facilitates the allocation and management of underlying hardware cache areas. Let's take a look at the types of hardware buffers and what options should we make when allocating them. (Hbu is abbreviated as harewarebufferusage) Hbu_static static hardware buffer, which means that we seldom write data into the update buffer and occasionally read data from it. Hbu_static_write_onLy writes only static hardware buffers. It means that we seldom update the buffer and never read data from the buffer. However, when we create a backup buffer, we can still read it. Hbu_dynamic dynamic hardware buffer. It means that we will regularly update the data in the buffer and want to read the data from it. This is the most efficient method of using the buffer. Hbu_dynamic_write_onLy writes only the dynamic hardware buffer. This is a hardware buffer that can only be written. However, when we create a backup buffer, it is still allowed to be read. Hbu_dynamic_write_onLy_discardable indicates that the hardware buffer zone is a buffer zone that requires frequent updates. Most of the updated data is stored here. However, remember to add a cache lock when writing data to this data buffer. Suggestion: Use write_on moreThe buffer type with the suffix ly. Even if read is required, we recommend that you use backup buffering instead of instant writable buffering. · Backup Buffer When we create a write_onAfter the hardware buffer of Ly, if we have to read data from it, we can pass the parameter when creating the buffer, so that we will create a backup buffer in the memory. Whenever we write a copy of data to the video memory, ogre automatically copies the data to the memory buffer and then updates it to the hardware buffer in the video memory. Of course, this technology will bring more overhead, so do not use it unless necessary. · Cache lock When we update the write buffer or read the buffer, we should first "Lock" it to avoid modification. Of course, remember to unlock it later. Pbuffer-> lock (begin, length, locktype) In general, the smaller the lock range, the more convenient and fast. However, the locktype can also affect the Read efficiency. The lock types include: · The hbl _ normal lock supports reading data from the buffer zone, but it is inefficient because it allows us to read data from the hardware buffer zone. However, when we use backup buffering, this impact will be improved. · Hbl _ read_onThe ly lock means that we can only read the content from the buffer and prohibit writing. We recommend that you use backup buffering to improve our efficiency. In addition, what we actually read is not the hardware buffer, but the data in the memory. · The hbl _ discard lock means that all content in the hardware buffer will be discarded every time we perform an operation. Generally, this operation will be used only in the environment where each shard is processed, it cannot be read. However, once we declare this, we basically declare to the engine that we are not interested in the content of the hardware buffer, so we should not create a backup buffer. If we try to use this lock when we do not use the backup buffer, It is very efficient, but if there is a memory backup buffer, it is unnecessary. · Hbl _ no_overwrite when we sometimes need to update part of the buffer but not all of the buffer, it is not suitable to use hbl_discard. At this point, we need to use this lock, which is still very efficient, but it only works when there is no backup buffer. · Experience in using hardware buffers and buffer locks 1: Because the fastest and best buffer is naturally through hbu_static_write_onLY type creation, no backup cache is created, and only one hbl_discard Lock operation will never be performed on the buffer. 2: When we need a buffer with frequent updates, we can use hbu_dynamic_write_on.Ly to create, do not create backup cache, and then use hbl_discard to lock. If you do not want to update all, use hbl_no_overwrite to lock. 3: If we have to read data from the buffer, we can create a backup buffer using hbl_read_on.Ly lock it. If possible, try to declare the buffer as static. 4: When we need to use different modes for different elements of the vertex, we should not update all the vertex structures of the buffer through a large number of pointers. We should update them in parts. For example, if we only need to update the texture coordinate information frequently, we should save the texture coordinate information in a separate buffer zone, while other infrequently updated elements are split and stored in hbu_static_write_on.Ly buffer. · Vertex buffer Vertexdata has several important members: · Vertexstart vertex start position · Vertexcount vertex count · Vertexdeclaration: a pointer to the number of vertex data · Vertexbufferbinding a pointer pointing to the vertex buffer binding In the vertex type description, we need to emphasize a sequence problem. To support versions earlier than DX9, We need to declare and save data in the following order: 1: vertex position information 2: vertex binding weight 3: vertex normal information 4: vertex ambient light color information 5: vertex mirror color information 6: vertex texture coordinate information In addition to the above sequence, we also need to note that there is absolutely no gap in the vertex buffer. After we create a vertex buffer, we also need to bind it to the specified resource. The format is as follows: verterbufferbinding-> setbinding (0, vertexbuffer ); Then, we bind the vertex buffer during the runtime, and update and fill in the information cyclically. The Ogre provides the length of the interval and the starting point between the adjacent points, so that we can update the data. · Index Buffer It is basically the same as the vertex buffer. Update after creation. The only difference is that some attributes are different during creation. · Pixel Buffer Here we save the texture pixel information. However, unlike the vertex buffer and index buffer, we cannot manually create a pixel buffer. The Pixel Buffer is automatically created only when we create a texture. Texture Types supported in the Pixel Buffer: Tex_type_1d one-dimensional texture, indexed by 1D texture coordinates Tex_type_2d texture, Which is indexed by 2D Coordinate Tex_type_3d 3D texture, Which is indexed by 3D Coordinate of Arts and Sciences Tex_type_cube_mapCubeSix surface textures of the object, which are indexed by 3D textures. Memory Allocation format of the Pixel Buffer Image Data Information in ogre is encapsulated in pixelbox objects. Note thatPixelbox itself is saved in the GPU, but the real textures are saved in the memory, not read in the GPU.. The pixelbox In the GPU stores the description of the pixel format and location information in the memory. However, pixelbox does not have the memory management function. It can only operate data through the stored memory pointer. The pixel box provides a method to index pixels by depth, height, and width. If one-dimensional textures have no height or depth, fill in the parameter 1. As follows: (width, 1, 1), two-dimensional texture (width, height, 1) Pixel Buffer update Ogre provides two methods to update the pixel buffer. 1: manually create a texture and put an image into the texture. We can:CodeImage IMG; img.load(“xxx.jpg "," General "); texture ptex = texture: getsingleton (). createmanual (.... ); Ptex-> getbuffer (0, 0)-> blitfrommemory (); 2: Lock a Pixel Buffer and read and write it. Buffer-> lock (harewarebuffer: hbl_discard ); Const pixelbox & Pb = buffer-> getcurrentlock (); // process the lock For (INT I = 0; I <Pb. getwindth (); ++ I) { For (Int J = 0; j <getheight (); ++ J) { Static_cast <unit32 *> (PB. DaTa) // obtain the data and process it as needed } } Buffer-> unlock (); // remember to unlock it.