Assume that I need to render static picture (100 stars).
I generate star data (position, color, size) to std::vector stars;
Then I create a class for D3D rendering, which consist a buffer:
CGalaxyMapRenderer
{
…
CComPtr<ID3D11Buffer> m_spStarBuffer;
}
In ctor I initialize it in this way:
CGalaxyMapRenderer::CGalaxyMapRenderer(const std::vector<SStarData>& vecData)
{
…
const CD3D11_BUFFER_DESC vertexBuffDescr((UINT)(sizeof(SStarData)*stars.size()), D3D11_BIND_VERTEX_BUFFER); //Constant buffer?
D3D11_SUBRESOURCE_DATA initVertexData = {0};
initVertexData.pSysMem = &stars[0];
spDevice->CreateBuffer(&vertexBuffDescr, &initVertexData, &m_spStarBuffer);
…
}
After that I may destroy std::vector, as it is no longer needed.
The questions are:
spDevice->CreateBuffer(&vertexBuffDescr, &initVertexData, &m_spStarBuffer));
Where memory allocation will take place for this peace of code?
Will it be graphic memory or current process memory?
When I no longer need to render a galaxy map (for example, when I want to move to next level, where no galaxy map required), I am going to destroy CGalaxyMapRenderer.
There will be automatic destruction of m_spStarBuffer in dtor.
The question is: is it enough to clear all the buffer resources?
Or should I make some additional steps in order to make memory free?
As to first question it should be on the process heap graphic memory is only used when needed in general: http://msdn.microsoft.com/en-us/library/ff476501(v=vs.85).aspx
As to second question I'm hoping by automatic destruction you mean that m_spStarBuffer is a smart pointer. Here's a simple example of creating a vertex buffer: http://msdn.microsoft.com/en-us/library/ff476899(v=VS.85).aspx
Related
I'm currently developing application using gSoap library and has some misunderstanding of proper usage library. I has generated proxy object (-j flag) which wrapped my own classes, as you can see below. Application must work 24/7 and connect simultaneously to many cameras (~50 cameras), so after every request i need to clear all temporary data. Is it normal usage to call soap_destroy() and soap_end() after every request? Because it seem's overkill to do it after each request. May be exists another option of proper usage?
DeviceBindingProxy::destroy()
{
soap_destroy(this->soap);
soap_end(this->soap);
}
class OnvifDeviceService : public Domain::IDeviceService
{
public:
OnvifDeviceService()
: m_deviceProxy(new DeviceBindingProxy)
{
soap_register_plugin(m_deviceProxy->soap, soap_wsse);
}
int OnvifDeviceService::getDeviceInformation(const Access::Domain::Endpoint &endpoint, Domain::DeviceInformation *information)
{
_tds__GetDeviceInformation tds__GetDeviceInformation;
_tds__GetDeviceInformationResponse tds__GetDeviceInformationResponse;
setupUserPasswordToProxy(endpoint);
m_deviceProxy->soap_endpoint = endpoint.endpoint().c_str();
int result = m_deviceProxy->GetDeviceInformation(&tds__GetDeviceInformation, tds__GetDeviceInformationResponse);
m_deviceProxy->soap_endpoint = NULL;
if (result != SOAP_OK) {
Common::Infrastructure::printSoapError("Fail to get device information.", m_deviceProxy->soap);
m_deviceProxy->destroy();
return -1;
}
*information = Domain::DeviceInformation(tds__GetDeviceInformationResponse.Manufacturer,
tds__GetDeviceInformationResponse.Model,
tds__GetDeviceInformationResponse.FirmwareVersion);
m_deviceProxy->destroy();
return 0;
}
}
To ensure proper allocation and deallocation of managed data:
soap_destroy(soap);
soap_end(soap);
You want to do this often to avoid memory to fill up with old data. These calls remove all deserialized data and data you allocated with the soap_new_X() and soap_malloc() functions.
All managed allocations are deleted with soap_destroy() followed by soap_end(). After that, you can start allocating again and delete again, etc.
To allocate managed data:
SomeClass *obj = soap_new_SomeClass(soap);
You can use soap_malloc for raw managed allocation, or to allocate an array of pointers, or a C string:
const char *s = soap_malloc(soap, 100);
Remember that malloc is not safe in C++. Better is to allocate std::string with:
std::string *s = soap_new_std__string(soap);
Arrays can be allocated with the second parameter, e.g. an array of 10 strings:
std::string *s = soap_new_std__string(soap, 10);
If you want to preserve data that otherwise gets deleted with these calls, use:
soap_unlink(soap, obj);
Now obj can be removed later with delete obj. But be aware that all pointer members in obj that point to managed data have become invalid after soap_destroy() and soap_end(). So you may have to invoke soap_unlink() on these members or risk dangling pointers.
A new cool feature of gSOAP is to generate deep copy and delete function for any data structures automatically, which saves a HUGE amount of coding time:
SomeClass *otherobj = soap_dup_SomeClass(NULL, obj);
This duplicates obj to unmanaged heap space. This is a deep copy that checks for cycles in the object graph and removes such cycles to avoid deletion issues. You can also duplicate the whole (cyclic) managed object to another context by using soap instead of NULL for the first argument of soap_dup_SomeClass.
To deep delete:
soap_del_SomeClass(obj);
This deletes obj but also the data pointed to by its members, and so on.
To use the soap_dup_X and soap_del_X functions use soapcpp2 with options -Ec and -Ed, respectively.
In principle, static and stack-allocated data can be serialized just as well. But consider using the managed heap instead.
See https://www.genivia.com/doc/databinding/html/index.html#memory2 for more details and examples.
Hope this helps.
The way memory has to be handled is described in Section 9.3 of the GSoap documentation.
I have a simple recursive-type container object "Level" (such as a directory, which can contain multiples of itself), although I'm not sure that's related to this problem.
//Level.h
class Level
{
public:
Level();
vector<Level*> SubLevels;
Level CreateSubLevel();
}
//Level.cpp
Level::Level()
{
SubLevels = vector<Level*>();
}
Level Level::CreateSubLevel()
{
Level NewLevel = Level();
SubLevels.push_back(&NewLevel);
return NewLevel;
}
If then in my main loop I call
//main.cpp
Level MasterLevel = Level();
MasterLevel.CreateSubLevel();
MasterLevel.CreateSubLevel();
MasterLevel.CreateSubLevel();
I find that indeed the vector MasterLevel.SubLevels contains three pointers to Level objects. However, they are all pointers to the same address!
I'm not sure why this is happening. My memory management skills are lacking - but I'm suspecting that it's because every time CreateSubLevel() is called, a new object is created, but then it is deleted when CreateSubLevel() exits? I thought that ARC would keep track of the fact that the pointer to it still exists, but perhaps I'm mistaken? Or is it another issue entirely?
How can I best fix this problem?
Thanks!
SubLevels is holding onto three pointers to temporaries. It's not a surprise that the compiler chose to reuse the same memory for the temporary each time - why not?
If you want to actually store three different Levels correctly, you will either have to store them by value:
vector<Level> SubLevels;
SubLevels.push_back(Level());
Or actually allocate Levels:
vector<Level*> SubLevels;
SubLevels.push_back(new Level); // don't forget to delete!
The reason you come up with the same value every time is because you are using the address of a temporary variable (on the stack). Every time the function CreateSubLevel() is called, the stack is reused, thus the objects are stored in the same location every call.
You can allocate objects on the heap using operator new():
vector<Level*> SubLevels;
SubLevels.push_back(new Level);
Then you can delete them in a destructor:
Level::~Level()
{
vector<Level*>::iterator i;
for (i = SubLevels.begin(); i != SubLevels.end(); ++i)
delete *i;
}
You have three calls to MasterLevel.CreateSubLevel(); one after the other. Each call creates a stack frame that is of the same size. Hence, the address of the local variable is the same. You are storing the address of the local variable in SubLevels.
If you use the address stored in SubLevels, you will run into undefined behavior. You need to allocate memory from heap.
While you are at it, keep a list of smart pointers, std::unique_ptr or std::shared_ptr instead of storing raw pointers.
Use
vector<std::shared_ptr<Level>> SubLevels;
and use it as:
void Level::CreateSubLevel()
{
SubLevels.push_back(std::make_shared<Level>());
}
I have a question realted to meemory usage by using
Dynamic ConstantBuffer vs Constant Buffer updated frequentlky(Using Defualt usagetype) vs Dynamic Vertex Buffer
I always Defined Constnat buffer usage as defualt and updated the changes in realtime like so
Eg 1
D3D11_BUFFER_DESC desc;
desc.Usage = D3D11_USAGE_DEFAULT;
// irrelevant code omitted
void Render()
{
WORLD = XMMatrixTranslation(x,y,z); // x,y,z are chaned dynamiclly
ConstantBuffer cb;
cb.world = WORLD;
devcon->UpdateSubResource(constantBuffer,0,0,&cb,0,0);
// Set the VSSetBuffer and PSSetBuffer
}
But Recently I came across a tutorial from rastertek that used
devcon->Map() and devcon->Unmap() to update them and he had defined the usage as Dynamic
Eg 2
void CreateBuffer(){
D3D11_BUFFER_DESC desc;
desc.Usage = D3D11_USAGE_DYNAMIC; // irrelkavant code ommited
}
void Render()
{
WORLD = XMMatrixTranslation(x,y,z); // x,y,z are chaned dynamiclly
D3D11_MAPPED_SUBRESOURCE mappedRes;
ConstantBuffer *cbPtr;
devcon->Map(constantBuffer,0,D3D11_MAP_WRITE_DISCARD,0,&mappedRes);
cbPtr = (ConstantBuffer*)mappedRes.pData;
cbPtr->World = WORLD;
devcon->UnMap(constantBuffer,0);
}
So the question is .
Is there any performance gain or hit by using Dynamic Constant buffer(eg2) over the the default ConstatnBuffer updatee at runtim(eg1) ??
Please do help me clear this doubt..
Thanks
The answer here like most performance advice is "It depends". Both are valid and it really depends on your content and rendering pattern.
The classic performance reference here is Windows to Reality: Getting the Most out of Direct3D 10 Graphics in Your Games from Gamefest 2007.
If you are dealing with lots of constants, Map of a DYNAMIC Constant Buffer is better if your data is scattered about and is collected as part of the update cycle. If all your constants are already laid out correctly in system memory, then UpdateSubResource is probably better. If you are reusing the same CB many times a frame and Map/Locking it, then you might run into 'rename' limits with Map/Lock that are less problematic with UpdateSuResource so "it depends' is really the answer here.
And of course, all of this goes out the window with DirectX 12 which has an entirely different mechanism for handling the equivalent of dynamic updates.
In my situation, the Drawing::Bitmap is created using a pointer to the pixel data. On the MSDN you can find a constructor doing exactly this:
Bitmap(int width, int height, int stride, PixelFormat format, IntPtr scan0);
From the documentation it is clear this constructor creates just the header and required things around the provided data. It is also noted, the caller have to release the pixel data array.
The caller is responsible for allocating and freeing the block of memory specified by the scan0 parameter. However, the memory should
not be released until the related Bitmap is released.
My problem is, if I pass a Bitmap with linked pixel data to another class, then I'm not able to release the underlying data. See my example bellow:
Drawing::Image^ FirstClass::GetImage(std::string ImagePath)
{
IplImage* cvImg = cvLoadImage(ImagePath.c_str());
Drawing::Image^ ManagedImg = gcnew Bitmap(
cvImg->width,
cvImg->height,
cvImg->widthStep,
Drawing::Imaging::PixelFormat::Format24bppRgb,
(System::IntPtr)cvImg->imageData);
return ManagedImg;
}
Void SecondClass::RefreshImage()
{
// Release the last image first
if (MyImage!=nullptr)
{
???
}
MyImage = GetImage(...);
}
A simple workaround is to pass, the IplImage* to the SecondClass, create the managed Bitmap there and then call cvReleaseImage(&Native_MyImage); there. However this works, I really want to know how to do it properly without passing IplImage*.
You need to pass pointers to pixels in some way.
For me, a better way would be to wrap IplImage* and ManagedImg into a single class that manages both of them. The destructor of the class would be responsible for destroying ManagedImg and then for calling cvReleaseImage() for stored value of the IplImage*. And then your GetImage function could return a pointer to this wrapper class, not to Drawing::Image.
I'm building a simple generic engine for my true start in the making of games, and I am trying to be somehow organized and decent in the making of my engine, meaning I don't want it to be something I throw to the side once I make what I'm planning to.
I add objects to be displayed, drawObjects, and these can either move, not move, and have an animation, or not have one.
In case they DO have an animation, I want to initialize a single animationSet, and this animationSet will have xxx animationComp inside of it. As I'm trying to be neat and have worked abit on "optimizations" towards memory and cpu usage (such as sharing already-loaded image pointers, and whatever came across my mind), I wanted to not ask for possibly unused memory in arrays.
So I had animationSetS* animationSet = NULL; initially, planning to do a animationSet = animationSetS[spacesINEED]; after, only on the objects that needed animation that I added, being those that aren't animations a NULL and therefore not using memory (correct?).
And then this question popped up! (title)
struct animationComp {
SDL_Rect* clip;
int clipsize;
};
struct animationSetS {
animationComp* animation;
int currentFrame;
int currentAnimation;
int animationNumber;
};
struct drawObject { // Um objecto.
char* name;
SDL_Surface* surface;
bool draw = true;
float xPos;
float yPos;
bool willMove = false; // 0 - Won't move, 10 - Moves alot, TO IMPLEMENT
bool isSprite = false;
animationSetS* animationSet;
};
I dabble alot in my questions, sorry for that. For any clarifications reply here, I'll reply within 10 minutes for the next... 1 hour perhaps? Or more.
Thanks!
Setting the pointer to NULL means that you'll be able to add ASSERT(ptr != NULL); and KNOW that your pointer does not accidentally contain some rubbish value from whatever happens to be in the memory it was using.
So, if for some reason, you end up using the object before it's been properly set up, you can detect it.
It also helps if you sometimes don't use a field, you can still call delete stuff; [assuming it's allocated in the first place].
Note that leaving a variable uninitialized means that it can have ANY value within it's valid range [and for some types, outside the valid range - e.g. pointers and floating point values can be "values that are not allowed by the processor"]. This means that it's impossible to "tell" within the code if it has been initialized or not - but things will go horribly wrong if you don't initialize things!
If this should be really implemented in C++ (as you write), why don't you use the C++ Standard Library? Like
struct animationSetS {
std::vector< std::shared_ptr<animationComp> > animation;
// ...
}