Measurement Studio for VC++

cancel
Showing results for 
Search instead for 
Did you mean: 

PC can't handle both IMAQ & OPENGL with BIG FAST images

I can extract images using a ring buffer at 72hz (2k x 2k x 16bit).    However, when I try to BOTH extract (using IMAQ) AND display (using OPEN-GL)  I get  an IMAQ FIFO overflow.      I want to run (and display) at 60hz but eventually get FIFO overflow at that speed....especially if I move the mouse around at the same time.  (Your measurment studio has no problem collecting AND displaying at 72 hz though).      Is there a way to give the IMAQ priority over open-gl ????   I don't mind missing a couple frames being displayed, but I cannot have IMAQ halting over a FIFO overflow.        
 
Thanks for any hints.  
0 Kudos
Message 1 of 6
(5,255 Views)

dkim,

   I have a couple of questions, I assume you're using LabVIEW?  Also, what do you mean by extract?  Are you inputting images in some way or are you using our IMAQ Extract.vi (assuming you're using LabVIEW) to reduce an image?  Also, are you calling your Open GL code with a Code Interface Node?  Calling outer code creates a new running thread, which sounds like open GL is starving our driver.  While I'm waiting to hear back from you I'll see what I can find out about getting priority to the IMAQ thread.  Thanks

-Allison S.
Applications Engineering

-Allison S.
Calibration Services
Product Support Engineer
0 Kudos
Message 2 of 6
(5,243 Views)

I'm using a c++ program.  By extract I mean   being able to successfully do a   imgSessionExamineBuffer().    I then use the extracted image with OPEN-GL  to display the 2kx2kx16bit image using NVIDIA cards.   All this is happening at 60hz.   At 30hz it works great.  At 60hz it works most of the time....if I move the mouse around a lot it dies quicker than if I just leave the PC alone.    I agree that your driver seems to be getting "STARVED".       Displaying only a portion of the image doesn't seem to have any affect.  Maybe Open-GL holds the interrupt longer than IMAQ can be without it?????    I'ld prefer to starve open-GL!!!!   If you have any ideas I'ld sure like to know.   However, I do realize that this probably is more a PC through-put problem than an IMAQ problem  🙂   Open-GL is just being used temporarily until our "display" boards are ready..   

 

0 Kudos
Message 3 of 6
(5,241 Views)
Dkim,
 
    Out of curiosity, why are you displaying at 60Hz?  The human eye can only really see about 30 Hz. It should be ok to display every other frame or even every 3rd or 4th frame.
-Allison S.
Calibration Services
Product Support Engineer
0 Kudos
Message 4 of 6
(5,210 Views)

It doesn't help to only display every other (or every 10th frame) for that matter.     I DO need to collect at 60 hertz though.   Somehow  OPEN_GL   HOGS the memory bandwidth or ISR when it displays just one 2048x2048x16bit frame for a long enough time, that depending upon timing (moving the cursor around a lot seems to make the problem worse) allows the IMAQ FIFO to fill up.       If I collect at 30 hertz it is not a problem, because the IMAQ FIFO does not fill up so quickly.  

If I comment out the Open-GL "glBegin....draw quad...glEnd" statements, I can collect the data at 72 hz with no problem,   so the problem is NOT that IMAQ can't keep up.   My CPU utilization is way below 50% so that should not be a problem.       I'm thinking I have a memory bandwidth problem, but haven't proved that yet.

I'm looking at the OPEN_GL application I am using to see if I can reduce the amount of from memory "copies"  that take place per image.  

 

 

 

 

 

0 Kudos
Message 5 of 6
(5,209 Views)

Dkim,

    I see.  When you are acquiring at 60Hz an image that large and displaying in a separate thread, I can understand that it's slowing down.  Keep me updated on how it's going and if you have any luck reducing the memory load that Open GL uses.  Let me know if you have anymore questions.

 

-Allison S.

Applications Engineering

-Allison S.
Calibration Services
Product Support Engineer
0 Kudos
Message 6 of 6
(5,193 Views)