Hi Andrew, I think the problem you've identified is much more fundamental than the closed source hardware drivers. What it comes down to is that OpenGL is is fundamentally *not* an API with predictable latency. Extremely small changes in input state can cause drastic variation in the amount of work required down the pipeline for the same geometric object. (Consider the effect of the Z translation entry in the modelview matrix on a fill-rate-bound triangle rendered under a perspective projection). On top of that, the effect of interactions between different state settings on rendering latency for a given object is virtually impossible to determine, at least not without doing much of the work required to render the object in the first place.
In a previous job I worked on an OpenGL driver that supported hard real-time _partitioning_ of rendering resources between multiple graphics windows. That is, the driver guaranteed a minimum GPU execution time quota for each window for a given fraction of a second. In that system we actually computed an estimated cost of rendering for every primitive sent to the GPU, and terminated the window's DMA command list once the rendering time quota was reached. But we were only able to do this computation after we had performed transformation, lighting, and window-boundary clipping in software, so we could account for fill rate in the cost estimation. The fact that the GPU had limited texturing capabilities helped with the predictability as well. Current GPUs do all those operations in hardware and have a lot more state that can have significant impacts on rendering performance (e.g. shaders), so there's probably no hope of accurately predicting latencies for anything other than very limited rendering states. -Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Straw Sent: Monday, September 11, 2006 1:04 AM To: osg users Subject: Re: [osg-users] OSG/Hard Real-Time By 'Hard Real-Time' are you talking about not just short, but also deterministic, latencies? I think most people mean so when using this phrase. In that case, assuming you're using some sort of hardware accelerated graphics (nvidia, ati, other?) my question is, how do you expect the latency of a presumably closed-source OpenGL driver to be deterministic? Or is there something special about the commercial software you mention that deals specifically with this issue of closed-source graphics drivers? Is it reasonable to assume that just because rendering something (and putting it out to the VGA/DVI commector) once took X microseconds, it will always take X microseconds? And finally, how are you going to measure these things, just to be sure? (For 'soft real-time' purposes, I've settled on using a photo-diode attached to the display, measuring changes in luminance, and correlating that to an output signal such a digital output pulse initiated by my program.) Thanks in advance for any answers -- I've always been curious about these issues. -Andrew Ed wrote: > Thanks for the good info... > > Ed > > Don Burns wrote: >> One more piece of information that might be important. When you run >> a Producer::CameraGroup based application you will get at least these >> threads: >> >> main (includes CameraGroup) >> KeyboardMouse >> BackgroundThread for Each RenderSurface >> Thread for Each Camera >> >> Your KeyboardMouse and Background RenderSUrface threads should run at >> high priority as they spend most of their time asleep in I/O. Camera >> threads should run at normal priority and main should run at normal >> or low priority. >> >> Your main's thread is accessible by default, KeyboardMouse, >> RenderSurface and Camera are all derived from OpenThread::Thread so >> calling getThreadID() on each of those will work. >> >> -don >> >> On 9/8/06, *Don Burns* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Hi Ed, >> >> Management of process/thread priority/scheduling is actually >> orthogonal to what OSG does. Beyond simple affinity assignation >> within OpenThreads, there is little support for use of hard >> real-time tools. >> >> However, the good news is that an OpenThread::Thread has a method >> called getThreadID(). You can then use this to allocate to CPUS, >> raise priorities to real-time, non-preemptable levels, etc. via >> the tools available on RedHawk. I think these might be >> implemented in the pthread interface, but I can't remember. There >> should be some good docs on that and the API is fairly small and >> easy to get familiar with quickly. >> >> Let me caution you on one detail. It is often the temptation to >> think of the rendering thread as the "most important" and >> therefore the one we want to raise the priority on. Actually, the >> opposite is true. The threads/processes for which you want >> highest priority are the ones that use the CPU the least, but need >> quick response. These are normally threads that are doing >> critical I/O, like waiting on a joystick, a network packet, or >> keyboard/mouse entry. The rendering thread is going to be >> hogging most of the CPU during frame time and if you raise its >> priority, the little time it takes to sleep in I/O waits, is the >> only time the other components will get to do their job. This can >> cause a system to feel unresponsive or eratic. >> >> Keep your rendering thread at normal priority and raise the >> priority of the light-weight tasks. Spend as little time as >> possible in critical real-time sections. >> >> -don >> >> >> On 9/8/06, *Ed* < [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> [Anyone - Please correct me if my terminology or understanding >> is incorrect] >> >> My limited experience with Real-time programming has been with >> RTLinux/RTCore. If I understand correctly, the way to write a >> real-time >> task with RTCore, is that it is written as a kernel >> module. You have a >> small main() which initializes a pthread where you task work >> is done. >> If I do need my rendering to be done in a real time task, is >> this >> something that can be done with OSG? Is that how it's done >> under >> RedHawk? Sorry this is so off topic.... >> >> Is there an example which shows how to have a separate thread, >> from the >> main app thread, which does all the OSG stuff? >> >> Ed >> >> >> Don Burns wrote: >> > Hi Ed, >> > >> > Ive used OSG on RedHawk. In fact, many trips around the sun >> ago, I >> > used to be a systems engineer for Concurrent >> Computer. IITSEC of 2003 >> > I put my hang-glider simulator in Concurrent's booth and >> drove a >> > cluster, using the ccur running RedHawk as the master >> channel. The >> > role of graphics does not really call for hard-real time, but >> some of >> > the other activities associated with the simulator did, >> including the >> > frame scheduler and synchronization of the slave channels >> with the master. >> > >> > The real-time extensions that CCUR brings to the Linux kernel >> are the >> > same ones they've been using since SVR5mp in the early >> nineties, and >> > conform to Posix 1003.b and 1003.c real-time standards. The >> extensions >> > allow for a fully preemptable kernel with resource allocation >> and very >> > good thread priority support. >> > >> > My experience was quite positive with Red Hawk. >> > >> > -don >> > >> > On 9/6/06, *Ed* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> > <mailto: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>>> wrote: >> > >> > I am working on a project which has as its end goal a >> hard real-time >> > system using OSG for the rendering. I have been >> considering RTLinux >> > Pro and RedHawk Linux as my RTOS. Anyone have any >> experience, good or >> > bad, with OSG on RTLinux or RedHawk? Anyone out that >> using OSG in >> > hard real-time? >> > >> > Ed >> > >> > _______________________________________________ >> > osg-users mailing list >> > osg-users@openscenegraph.net >> <mailto:osg-users@openscenegraph.net> <mailto: >> osg-users@openscenegraph.net >> <mailto:osg-users@openscenegraph.net>> >> > http://openscenegraph.net/mailman/listinfo/osg-users >> > http://www.openscenegraph.org/ >> > >> > >> > >> ------------------------------------------------------------------------ >> >> > >> > _______________________________________________ >> > osg-users mailing list >> > osg-users@openscenegraph.net >> <mailto:osg-users@openscenegraph.net> >> > http://openscenegraph.net/mailman/listinfo/osg-users >> > http://www.openscenegraph.org/ >> >> _______________________________________________ >> osg-users mailing list >> osg-users@openscenegraph.net >> <mailto:osg-users@openscenegraph.net> >> http://openscenegraph.net/mailman/listinfo/osg-users >> http://www.openscenegraph.org/ >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> osg-users mailing list >> osg-users@openscenegraph.net >> http://openscenegraph.net/mailman/listinfo/osg-users >> http://www.openscenegraph.org/ > > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
