I wrote a simple CUDA code as follows:
//Allocate the first 2d array "deviceArray2DInput"
if(cudaMallocPitch((Float32**) &deviceArray2DInput, &devicePitch, sizeof(Float32)*deviceColNumber,deviceRowNumber) == cudaErrorMemoryAllocation){
return -1;
}
//Allocate the second 2d array "deviceArray2DOutput". It was suppose to hold the output of some process.
if(cudaMallocPitch((Float32**) &deviceArray2DOutput, &devicePitch,sizeof(Float32)*deviceRowNumber,deviceColNumber) == cudaErrorMemoryAllocation){
return -1;
}
//Copy data from "hostArrayR" to "deviceArray2DInput" (#1)
cudaMemcpy2D(deviceArray2DInput,devicePitch,hostArrayR,sizeof(Float32)*colNumber,sizeof(Float32)*deviceColNumber,deviceRowNumber,cudaMemcpyHostToDevice);
//Clean the top 10000 elements in "hostArrayR" for verification.
for(int i = 0; i < 10000; ++i){
hostArrayR[i] = 0;
}
//Copy data back from "deviceArray2DInput" to "hostArrayR"(#2)
cudaMemcpy2D(hostArrayR,sizeof(Float32)*colNumber,deviceArray2DInput,devicePitch,sizeof(Float32)*deviceColNumber,deviceRowNumber,cudaMemcpyDeviceToHost);
I commented out the second allocation block, the code worked well. It copied the data from the host array "hostArrayR" to the device array "deviceArray2DInput" and copied it back. However, if both allocation blocks existed, the copied-back "hostArrayR" was empty (no data was copyed back from device).
I am sure that the data was in "hostArrayR" at line (#1) but there was no data at line (#2). I cleaned the first 10000 elements (much lesss than the size of the array) to verfy that data did not come back.
I am using Nvidia Nsight 2.2 on Visual Studio 2010. The array size is 1024x768 and I am using floating 32-bit data. My GPU card is GTX570. It seems that there was no memory allocation error (or the code will return before doing copy stuffs).
I did not try "cudaMalloc()" because I prefer to use "cudaMallocPitch()" for memory alignment.
You should check the API calls against cudaSuccess, rather than one
specific error.
You should check the error value returned by the memcpys.
You're overwriting the devicePitch on the second cudaMallocPitch() call, the arrays have different shapes and hence could have different pitches.
Related
I tried usual Windows way, I passed nullptr as output buffer pointer and size 0. AcceptSecurityContext fails with error SEC_E_INSUFFICIENT_MEMORY. I was expecting to get needed size in OutSecBuff.cbBuffer but it is 0. I call it again with huge buffer. Call succeeds but context is invalid an later calls fail.
// Query needed buffer size
secStatus = AcceptSecurityContext(&hcred,&hctxt, &InBuffDesc,attr,SECURITY_NATIVE_DREP,
&hctxt,&OutBuffDesc,&attr,nullptr);
if(SEC_E_INSUFFICIENT_MEMORY == ss)
{
// Allocate buffer of needed size, big enough
OutSecBuff.cbBuffer = *pcbOut;
OutSecBuff.pvBuffer = pOut;
// Call with buffer of required size
secStatus = AcceptSecurityContext(&hcred,&hctxt, InBuffDesc,
attr,SECURITY_NATIVE_DREP,&hctxt,&OutBuffDesc,&attr,nullptr);
}
If I preallocate huge buffer, everything works fine.
I would like to dynamically allocate buffer of needed size.
SSAPI takes different approcah. When querying security package QuerySecurityPackageInfo, max size of output buffer is returned in field cbMaxToken. You allocate buffer once and you can be assured that buffer size will be enough for all requests.
I was looking at my process in Task manager after pulling in a large amount of data that went to a CEditView then setting back to small amount. I noticed the commit size stayed large. Then I used VMMMap and see it as well, so I did "Memory Usage" in VS2017 Diagnostic Tools. I see it's coming from ultimately the ::SetWindowText() call. So that obviously allocates a large buffer on the heap, but then when I set it back to a small amount, that allocate stays large. The question is, is there a way I can have the Edit Control free up the memory it doesn't need for smaller amounts of text to reduce that committed memory? Say, I can free it up before setting the new text and it would allocate as needed?
Thanks!!
// From within CEditView
// based on an answer RbMm using EM_GETHANDLE/EM_SETHANDLE and further
// from https://stackoverflow.com/questions/5500237/how-to-use-em-sethandle-on-edit-control
// reduce size to 64K if larger than that and not needed
#define EDITctrlLimitSize 65536
// check if we should reduce size of buffer
HLOCAL horgmem = (HLOCAL) SendMessage(EM_GETHANDLE,0,0);
SIZE_T sizeused=LocalSize(horgmem);
int cbCh = sizeof(TCHAR) > 1 ? sizeof(TCHAR) : IsUsingComCtlV6() ? sizeof(WCHAR) : sizeof(char);
if (sizeused > EDITctrlLimitSize && (string.GetLength()*cbCh) < EDITctrlLimitSize) {
// EM_GETHANDLE says to not change the data, yet EM_SETHANDLE tells you to
// get the handle then LocalFree it, so why not just LocalReAlloc it and set
// again.
HLOCAL hnewmem=(HLOCAL) LocalReAlloc(horgmem, EDITctrlLimitSize, LMEM_MOVEABLE);
if (hnewmem) {
// zero full buffer because seems like good thing to do
LPVOID pnewmem=LocalLock(hnewmem);
if (pnewmem) {
memset(pnewmem, 0, EDITctrlLimitSize);
LocalUnlock(hnewmem);
}
// viola - process memory reduced.
SendMessage(EM_SETHANDLE, (WPARAM) hnewmem, 0);
}
}
I'm altering someone else's code. They used PNG's which are loaded via BufferedImage. I need to load a TGA instead, which is just simply a 18 byte header and BGR codes. I have the textures loaded and running, but I get a gray box instead of the texture. I don't even know how to DEBUG this.
Textures are loaded in a ByteBuffer:
final static int datasize = (WIDTH*HEIGHT*3) *2; // Double buffer size for OpenGL // not +18 no header
static ByteBuffer buffer = ByteBuffer.allocateDirect(datasize);
FileInputStream fin = new FileInputStream("/Volumes/RAMDisk/shot00021.tga");
FileChannel inc = fin.getChannel();
inc.position(18); // skip header
buffer.clear(); // prepare for read
int ret = inc.read(buffer);
fin.close();
I've followed this: [how-to-manage-memory-with-texture-in-opengl][1] ... because I am updating the texture once per frame, like video.
Called once:
GL11.glBindTexture(GL11.GL_TEXTURE_2D, textureID);
GL11.glTexParameteri(GL11.GL_TEXTURE_2D, GL11.GL_TEXTURE_WRAP_S, GL11.GL_CLAMP);
GL11.glTexParameteri(GL11.GL_TEXTURE_2D, GL11.GL_TEXTURE_WRAP_T, GL11.GL_CLAMP);
GL11.glTexParameteri(GL11.GL_TEXTURE_2D, GL11.GL_TEXTURE_MAG_FILTER, GL11.GL_NEAREST);
GL11.glTexParameteri(GL11.GL_TEXTURE_2D, GL11.GL_TEXTURE_MIN_FILTER, GL11.GL_NEAREST);
GL11.glTexImage2D(GL11.GL_TEXTURE_2D, 0, GL11.GL_RGB, width, height, 0, GL11.GL_RGB, GL11.GL_UNSIGNED_BYTE, (ByteBuffer) null);
assert(GL11.GL_NO_ERROR == GL11.glGetError());
Called repeatedly:
GL11.glBindTexture(GL11.GL_TEXTURE_2D, textureID);
GL11.glTexSubImage2D(GL11.GL_TEXTURE_2D, 0, 0, 0, width, height, GL11.GL_RGB, GL11.GL_UNSIGNED_BYTE, byteBuffer);
assert(GL11.GL_NO_ERROR == GL11.glGetError());
return textureID;
The render code hasn't changed and is based on:
GL11.glDrawArrays(GL11.GL_TRIANGLES, 0, this.vertexCount);
Make sure you set the texture sampling mode. Especially min filter: glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR). The default setting is mip mapped (GL_NEAREST_MIPMAP_LINEAR) so unless you upload mip maps you will get a white read result.
So either set the texture to no mip or generate them. One way to do that is to call glGenerateMipmap after the tex img call.
(see https://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexParameter.xml).
It's a very common gl pitfall and something people just tend to know after getting bitten by it a few times.
There is no easy way to debug stuff like this. There are good gl debugging tools in for example xcode but they will not tell you about this case.
Debugging GPU code is always a hassle. I would bet my money on a big industry progress in this area as more companies discover the power of GPU. Until then; I'll share my two best GPU debugging friends:
1) Define a function to print OGL errors:
int printOglError(const char *file, int line)
{
/* Returns 1 if an OpenGL error occurred, 0 otherwise. */
GLenum glErr;
int retCode = 0;
glErr = glGetError();
while (glErr != GL_NO_ERROR) {
printf("glError in file %s # line %d: %s\n", file, line, gluErrorString(glErr));
retCode = 1;
glErr = glGetError();
}
return retCode;
}
#define printOpenGLError() printOglError(__FILE__, __LINE__)
And call it after your render draw calls (possible earlier errors will also show up):
GL11.glDrawArrays(GL11.GL_TRIANGLES, 0, this.vertexCount);
printOpenGLError();
This alerts if you make some invalid operations (which might just be your case) but you usually have to find where the error occurs by trial and error.
2) Check out gDEBugger, free software with tons of GPU memory information.
[Edit]:
I would also recommend using the opensource lib DevIL - its quite competent in loading various image formats.
Thanks to Felix, by not calling glTexSubImage2D (leaving the memory valid, but uninitialized) I noticed a remnant pattern left by the default memory. This indicated that the texture is being displayed, but the load is most likely the problem.
**UPDATE:
The, problem with the code above is essentially the buffer. The buffer is 1024*1024, but it is only partially filled in by the read, leaving the limit marker of the ByteBuffer at 2359296(1024*768*3) instead of 3145728(1024*1024*3). This gives the error:
Number of remaining buffer elements is must be ... at least ...
I thought that OpenGL needed space to return data, so I doubled the size of the buffer.
The buffer size is doubled to compensate for the error.
final static int datasize = (WIDTH*HEIGHT*3) *2; // Double buffer size for OpenGL // not +18 no header
This is wrong, what is needed is the flip() function (Big THANKS to Reto Koradi for the small hint to the buffer rewind) to put the ByteBuffer in read mode. Since the buffer is only semi-full, the OpenGL buffer check gives an error. The correct thing to do is not double the buffer size; use buffer.position(buffer.capacity()) to fill the buffer before doing a flip().
final static int datasize = (WIDTH*HEIGHT*3); // not +18 no header
buffer.clear(); // prepare for read
int ret = inc.read(buffer);
fin.close();
buffer.position(buffer.capacity()); // make sure buffer is completely FILLED!
buffer.flip(); // flip buffer to read mode
To figure this out, it is helpful to hardcode the memory of the buffer to make sure the OpenGL calls are working, isolating the load problem. Then when the OpenGL calls are correct, concentrate on the loading of the buffer. As suggested by Felix K, it is good to make sure one texture has been drawn correctly before calling glTexSubImage2D repeatedly.
Some ideas which might cause the issue:
Your texture is disposed somewhere. I don't know the whole code but I guess somewhere there is a glDeleteTextures and this could cause some issues if called at the wrong time.
Are the texture width and height powers of two? If not this might be an issue depending on your hardware. Old hardware sometimes won't support non-power of two images.
The texture parameters changed between the draw calls at some other point ( Make a debug check of the parameters with glGetTexParameter ).
There could be a loading issue when loading the next image ( edit: or even the first image ). Check if the first image is displayed without loading the next images. If so it must be one of the cases above.
I am using the following to get the memory usage:
struct task_basic_info info;
mach_msg_type_number_t sizeNew = sizeof(info);
kern_return_t kerr = task_info(mach_task_self(),
TASK_BASIC_INFO,
(task_info_t)&info,
&sizeNew);
if( kerr == KERN_SUCCESS ) {
printf("Memory in use (in bytes): %u", info.resident_size);
} else {
printf("Error with task_info(): %s", mach_error_string(kerr));
}
But the memory returned by this is much higher than that of shown by XCode6, any one else facing the same issue ?
Resident set size (RSIZE) is not the same as the 'amount of memory used'. it includes the code as well.
You're probably looking for the top equivalent of RPRVT from the top program.
Obtaining that information requires walking the VM information for the process. Using the code for libtop.c, function libtop_update_vm_regions as a template, you would need to walk through the entire memory map adding up all the private pages. There's a simpler example of walking the address space, which can be used as a basis for calculating this size. You're looking for the VPRVT value, not the RPRVT value.
I don't currently have a mac to hand to write out an example with any degree of confidence that would work.
I am developing an application in Atmel Studio 6 using the xMega32a4u. I'm using the TWI libraries provided by Atmel. Everything is going well for the most part.
Here is my issue: In order to update an OLED display I am using (SSD1306 controller, 128x32), the entire contents of the display RAM must be written immediately following the I2C START command, slave address, and control byte so the display knows to enter the data into the display RAM. If the control byte does not immediately precede the display RAM package, nothing works.
I am using a Saleae logic analyzer to verify that the bus is doing what it should.
Here is the function I am using to write the display:
void OLED_buffer(){ // Used to write contents of display buffer to OLED
uint8_t data_array[513];
data_array[0] = SSD1306_DATA_BYTE;
for (int i=0;i<512;++i){
data_array[i+1] = buffer[i];
}
OLED_command(SSD1306_SETLOWCOLUMN | 0x00);
OLED_command(SSD1306_SETHIGHCOLUMN | 0x00);
OLED_command(SSD1306_SETSTARTLINE | 0x00);
twi_package_t buffer_send = {
.chip = OLED_BUS_ADDRESS,
.buffer = data_array,
.length = 513
};
twi_master_write(&TWIC, &buffer_send);
}
Clearly, this is very inefficient as each call to this function recreates the entire array "buffer" into a new array "data_array," one element at a time. The point of this is to insert the control byte (SSD1306_DATA_BYTE = 0x40) into the array so that the entire "package" is sent at once, and the control byte is in the right place. I could make the original "buffer" array one element larger and add the control byte as the first element, to skip this process but that makes the size 513 rather than 512, and might mess with some of the text/graphical functions that manipulate this array and depend on it being the correct size.
Now, I thought I could write the code like this:
void OLED_buffer(){ // Used to write contents of display buffer to OLED
uint8_t data_byte = SSD1306_DATA_BYTE;
OLED_command(SSD1306_SETLOWCOLUMN | 0x00);
OLED_command(SSD1306_SETHIGHCOLUMN | 0x00);
OLED_command(SSD1306_SETSTARTLINE | 0x00);
twi_package_t data_control_byte = {
.chip = OLED_BUS_ADDRESS,
.buffer = data_byte,
.length = 1
};
twi_master_write(&TWIC, &data_control_byte);
twi_package_t buffer_send = {
.chip = OLED_BUS_ADDRESS,
.buffer = buffer,
.length = 512
};
twi_master_write(&TWIC, &buffer_send);
}
/*
That doesn't work. The first "twi_master_write" command sends a START, address, control, STOP. Then the next such command sends a START, address, data buffer, STOP. Because the control byte is missing from the latter transaction, this does not work. All I need is to insert a 0x40 byte between the address byte and the buffer array when it is sent over the I2C bus. twi_master_write is a function that is provided in the Atmel TWI libraries. I've tried to examine the libraries to figure out its inner workings, but I can't make sense of it.
Surely, instead of figuring out how to recreate a twi_write function to work the way I need, there is an easier way to add this preceding control byte? Ideally one that is not so wasteful of clock cycles as my first code example? Realistically the display still updates very fast, more than enough for my needs, but that does not change the fact this is inefficient code.
I appreciate any advice you all may have. Thanks in advance!
How about having buffer and data_array pointing to the same uint8_t[513] array, but with buffer starting at its second element. Then you can continue to use buffer as you do today, but also use data_array directly without first having to copy all the elements from buffer.
uint8_t data_array[513];
uint8_t *buffer = &data_array[1];