Here's my code for a program that does a histogram on an image then a prefix sum scan on the histogram http://codepad.org/4RMtWn1e. The problem is at line 396, which correctly outputs the value of numBins (number of bins for histogram) at 1024. I than copy the histogram from device memory back to host memory. This somehow changes the value of numBins and the next output of that is 0. That seems very strange. I didn't make any specific modifications to numBins, but it changes the value anyway. I feel like if I can figure this out, It will me understand why my program isn't working.
This is wrong:
unsigned int* h_histogram;
h_histogram = (unsigned int*) malloc(sizeof(unsigned int)* 1024);
std::cout << numBins;
checkCudaErrors(cudaMemcpy(&h_histogram, d_histogram, sizeof(unsigned int)* numBins, cudaMemcpyDeviceToHost));
^
|
h_histogram is already a pointer
Instead do this:
checkCudaErrors(cudaMemcpy(h_histogram, d_histogram, sizeof(unsigned int)* numBins, cudaMemcpyDeviceToHost));
(the only change being to remove the ampersand in front of h_histogram
I'm not sure really why numBins got corrupted exactly, but this particular errant cudaMemcpy operation would not be copying to the destination you expect, instead it would overwrite the pointer value stored at h_histogram as well as anything that came after it. And if numBins happened to be stored after it, it would overwrite that also.
Related
I wrote a barebone progran template in XC8 (1.37) that I use to develop and test new GLCD functions for the 18F family. Programming is done via a PICkit3. Since I need to quicky reprogram several times the code it is really important that programming is faster as much as possible.
Tipically, the code size is around 2K and it takes less than 10 sec to program,
Everiything is fine until I must use a font table, defined as:
const char font8[] = {....
Now, with just $400 bytes added, the compiler place the table at the ROM's end and the programming of 64K memory takes more than 1 minute.
Is there any way to avoid this?
I tried to manually limit the memory range in the MPLABX options, but this is annoying and a little unsafe (sometimes part of code is truncated).
A while back I had to write some code for emissions testing, where I needed to copy data between extreme ends of RAM. To do that I needed to specify the exact memory addresses. You can also use the C extension __at() construct. http://ww1.microchip.com/downloads/en/DeviceDoc/50002053F.pdf#page=27
int scanMode __at(0x200);
const char keys[] __at(123) = { ’r’, ’s’, ’u’, ’d’};
int modify(int x) __at(0x1000) {
return x * 2 + 3;
}
I have a question about MPI. I want to have processes read a binary file simultaneously and therefore I'm trying to use MPI_File_iread, but it is not working as I'd expect and I don't know what's wrong.
Sorry if the format of the question is not correct, I am new here.
Here is my code (NINTCI is an integer pointer, file_name is a char array that has the file name already):
#include "mpi.h"
[...]
MPI_Request request;
MPI_Status status;
MPI_File fp;
MPI_File_open(MPI_COMM_WORLD, file_name, MPI_MODE_RDONLY, MPI_INFO_NULL, &fp);
MPI_File_iread(fp, NINTCI, 1, MPI_INT, &request);
MPI_Wait(&request, &status);
printf("%d\n", *NINTCI);
MPI_Barrier(MPI_COMM_WORLD);
The correct number printed should be 0 for all processes, but instead I get random numbers like the following (8 processes):
-1475867408
1495223536
-219489040
-840278800
629550320
1309351152
-321049360
21273840
Funny thing is if I replace the MPI_File_iread with MPI_File_read and remove the MPI_Wait the result is correct.
Does anybody have an idea what I'm doing wrong? Thanks in advance!
You do not check any of your error codes. Does the file exist? Does it have proper permissions? All these answers and more can be yours if you check errors.
See How to use and interpret MPI-IO Error codes? for an example of how to get meaningful information out of your MPI implementation.
I have a bizarre one here with the serial output when trying to write some code for my Arduino Uno.
I have this proto-code:
MyClass myclass;
void setup()
{
Serial.Begin(9600);
Serial.println("Starting...");
}
void loop()
{
int status = myclass.DoWork();
Serial.println("Status: " + status);
}
class MyClass
{
int DoWork()
{
Serial.println("Doing some work...");
return 1;
}
}
Now when this runs I get the following output:
Starting...
Doing some work...
atus: 1
So the strange part is the "Status: 1" missing the first few characters. Is this because I am using serial in an object improperly or something?
I have noticed when I reference another library that also uses serial like MyClass does that I get other strange output behavior... so I assume that I am doing something wrong.
EDIT: In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
You cannot add strings and integers in C++. It would have been better for you if this failed to compile:
Serial.println("Status: " + status);
Instead the compiler guessed at something. It guessed wrong. Use this:
Serial.print("Status :");
Serial.println(status);
or for complete control of outputting numbers and strings learn to use C string formatting, sprintf()
In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
One more possible explanation.
I was running minicom to monitor, and I usually like that it auto-reconnects after resetting my device.
Well I minimized a terminal running minicom last night, and today I started a new instance that somehow also got connected to the same serial port (if that is even possible).
I think the two instances of minicom were each reading ~50% of the serial characters roughly at random, leaving me with quite a mess of text.
I have a GUI application whose main part is a QPlainTextEdit. It is used to display a log of the application, and as such the associated text grows line by line ad infinitum.
As the application is intended to run very long, I need to limit the memory that will be allocated for this log. Therefore I want to have some maxNumLines or maxNumCharacters parameter that will make sure the history will be truncated when reached, i.e. the head lines will be removed as new lines are appended (a.k.a. log rotation).
To achieve this I found the functions
// get the associated text
QString toPlainText () const
// set the associated text
void setPlainText ( const QString & text )
Therefore something like this untested code would probably do the trick:
QString &tmp = pte.toPlainText();
while (tmp.size() > maxNumCharacters) {
// remove lines from the head of the string until the desired size is reached
// removes nothing if "\n" could not be found
tmp.remove(0, tmp.indexOf("\n")+1);
}
pte.setPlainText( tmp );
Is this the way to go to remove the first line(s) from the QPlainTextEdit? Are there probably other Qt Text GUI elements that would better fit to this task (set a maximum number of lines and truncate at the head of the list), e.g. somehow display a QStringList in which I could store the lines (s.t. I could easily erase(0))?
Or does the QPlainTextEdit eventually implement such upper bound for the size of the associated QString after all?
Apparantly the property maximumBlockCount is exactly what I need:
If you want to limit the total number of paragraphs in a QPlainTextEdit, as it is for example useful in a log viewer, then you can use the maximumBlockCount property. The combination of setMaximumBlockCount() and appendPlainText() turns QPlainTextEdit into an efficient viewer for log text.
For reference:
http://doc.qt.io/qt-5/qplaintextedit.html#maximumBlockCount-prop
I had exactly the same problem a months back, and I ended up using a QListView. Although using the model/view/delegate architecture is a bit more fiddly, it scales much better in the long run. For example once the basic architecture is in place, adding a filter that displays only error or warning entries becomes trivial, or creating a delegate so that the background of error entries are painted red is also straightforward.
I encountered a problem with passing Image object (captured with Point Grej FlyCapture2 SDK) to QImage object. I am getting a pointer associated with Image data by function:
virtual unsigned char* FlyCapture2::GetData ( )
and then loading the data by:
QImage::QImage ( uchar * data, int width, int height, int bytesPerLine, Format format )
Formats of data of both Image objects are 8-bit monocolor. BytesPerLine parameter should be equal to width of the Image (I've already checked it by saving FlyCapture2::Image to .bmp and then loading it to QImage).
Do you thing the problem is casting from unsigned char* to uchar*?
Do you have any other ideas? Copying image pixel by pixel is much too slow.
EDIT: I am converting Image captured by FlyCapture into the FlyCapture2::PIXEL_FORMAT_RGB8 , for which: R = G = B = 8 bits, within PGR::SnapShot() function. SnapShot() returns unsigned char* const.
and here is a part of my Qt display function:
unsigned char *const img = PGRSystem->SnapShot();
QImage Img(img, 1024, 768, QImage::Format_RGB888);
QGraphicsScene *Scene = new QGraphicsScene();
Scene->addPixmap(QPixmap::fromImage(Img));
ui.ImageView->setScene(Scene);
ui.ImageView->fitInView(ui.ImageView->itemAt(100,100));
delete [] Scene;
I also tried to save Img to file, but got unhandled exception then. I tried other pixel format pairs (FlyCapture2::PIXEL_FORMAT_RGB - 24 bit RGB with QImage::RGB888 and FlyCapture2::PIXEL_FORMAT_RGBU32 with QImage::RGB32)
It is also worth to mention that QImage constuctor, which I am using, does not set the colorTable (I am getting exception when checking if QImage is in grayScale).
I need a little more help I guess.
First thing - QImage doesn't support a native greyscale image, which is what it sounds as if you're getting as output - so I would be curious what Format argument you're using. Probably the easiest solution, though memory-inefficent, will be to expand your greyscale image to RGB by copying each value three times (into a new QByteArray).
An additional concern is that the particular QImage constructor you're using, does not copy the underlying data, so you need be sure the pointer returned from GetData() outlives the QImage - or force the QImage to make a copy internally, using, say, QImage::copy.
Seeing more code would help, as other respondents noted above.
Thanks a lot for your help, you were right about the Image formats. Unfortunatelly the main problem was associated with passing the pointer between functions. In PGR::SnapShot() I was creating FlyCapture2::Image and then I was getting the pointer to data. FlyCapture2::Image was detructed when exit the function so returned pointer was BadPtr.