Hello and thanks for reading.
Setup: An R-Series PXI card in a chassis which is connected to a PC via MXI. The PC houses a Nvidia Quadro 5000 grafics card with an external frame sync input (Gsync) which is connected to an R-Series I/O. An external Measurement device which emits a clock at 1200Hz connected to an R-Series I/O. Several I/O lines on the measurement device connected to the R-series in order to record Triggers/States of the Programm to be developed. Windows as OS on the PC running a VI to display a grafical scene. A dedicated while loop installed on the R-series FPGA to derive the 60Hz clock for the Gsync I/O of the GPU from the 1200Hz external clock of the measurement device.
Task: Synchronize a 60 FPS grafical scene to the measurement device so i can later on derive from the states of the recorded trigger channels of the measurement device when the grafical scene had which properties with as little inaccuracy in time as possible.
Thoughts:
- Im not sure if Labview realtime as OS on the PC would allow me to present a grafical scene - as far as i understand there is no grafical output over a gpu available in labview real time? I dont have labview RT installed yet but would if that improoves performance.
- Currently im using 3D picture control to realize the grafical scene in order to utilze GPU acceleratoin to minimize frame loop time and achieve the 60 FPS.
- I implemented a software side wait for Vsync impulse (GPU starts to draw next frame) in the windows VI grafical scene update loop using vsync.dll from the example code given by Andrey_Dmitriev in this topic.: http://forums.ni.com/t5/LabVIEW/Vertical-synchronization-when-displaying-video/td-p/792930
code: http://forums.ni.com/ni/attachments/ni/170/363277/1/VSync.zip
This implementation skips frames every now and then depending on the CPU load. The scene itself is minimalistic and should not strain the GPU at all. Im not sure how to prioritize execution of the grafical task further. Compile it and execute the binary as highest priority windows task?
- As im giving the Gsync clock via R-series I/O myself anyway i was wondering if its not better to hand up the I/O state of the 60Hz clock all the way from r-series FPGA to the windows VI. Im not sure which impementation would provide the least load/overhead/latency - is a a timed loop using the I/O pin as clock source the recommended implementation? I would like to compare timing of this approach to the software Vsync.dll solution.
- In order to track the states of the grafical scene i thought of saving the states of each frame to a matrix/data structure (timestamps?) in the VI. I would send trigger signals from windows VI to r-series I/O to inputs of the measurement device (sampled at 1200Hz) marking the current states of the grafic engine/its frames. I would later and offline match the state data recorded by the windows VI to the I/O lines recorded by the measurement device.
Updates of the grafical scene/engine could look like this sequence.:
1) wait for last frame to be drawn/ last 60Hz clock edge to occure
2) raise a trigger "calculating next frame" from windows VI to r-series I/O to measurement device I/O line
3) update scene parameters
4) update scene
5) save scene parameters to a data structure - do i want timestamps here or is aligning to the "calculating next frame" trigger line later on better?
6) lower "calculating next frame" trigger line
7) goto 1)
Im currently triing to structure the task at hand and am looking for advice/recommendations of functions/principles to implement the desired synchronization between grafical scene and measurement device in order to present 60 FPS and to deduct the state of the grafic engine relative to the data measured by the measurement device offline as precise (in time) as possible.
Thank you very much for your time invested and all advice/inspiration shared!
