On Mon, 2005-09-12 at 23:40 -0400, Adam Jackson wrote: > On Monday 12 September 2005 22:24, Tim Long wrote: > > I am wondering if any PC level hardware implements the same features? For > > the ones that don't what sort of performance impact does it take switch GL > > threads if the pipeline has to be flushed on a context switch. I am > > guessing that at least older style PC hardware designed for games would > > assume that the only openGL context (full screen first person shooter). > > 3dlabs cards have multiple hardware contexts. My understanding of nVidia > cards is that they kinda have multiple hardware contexts. The newer Matrox > cards might too. I think for all of these cases you're merely increasing the > number of hardware contexts from one to (say) eight, so you'll still have to > switch contexts sometimes. > > You don't necessarily have to flush the pipeline on hardware context switch. > You just need to resynchronize the state on the card with the state of the > context you're switching to. > > - ajax
So, the simple solution we've done for most of our drivers now is "oh, someone else used the context? *dump all state again*". I may be remembering a simple test to measure the penalty that I did with radeon: I just didn't dump state on context switching (something rather prone to hangs, obviously) and got a win of around 5% for the two-app case. Thus, it looks like context switching isn't a major bottleneck for us, at least on some hardware. The cmdbuf system on Radeons (I think) should mitigate the number of lock grabs and trips to the kernel, and thus the number of context switches that have to happen anyway. That said, I may not have used the best app (ipers) for the test -- it was dominated by fillrate, so there might not have been many opportunities for pingponging state. Or maybe not, since it was the best app I found for reproducing that race in state updating that we were dealing with. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
