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? F=
> > the ones that don't what sort of performance impact does it take switch=
> > 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 Matr=
> cards might too. I think for all of these cases you're merely increasing=
> number of hardware contexts from one to (say) eight, so you'll still have=
> switch contexts sometimes.
> You don't necessarily have to flush the pipeline on hardware context swit=
> You just need to resynchronize the state on the card with the state of th=
> 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 eta@...