[PULL] MAXSCREENS removal preparation

[Aaron Plattner]

On Mon, Apr 26, 2010 at 11:37:54AM -0700, Jamey Sharp wrote:
> On Mon, Apr 26, 2010 at 9:27 AM, Aaron Plattner <aplattner at nvidia.com> wrote:
> >> Jamey Sharp (3):
> >>       xfree86: use screen privates for Xv offscreen images.
> >
> > Why does xf86XVRegisterOffscreenImages call dixRequestPrivate every time,
> > with a constant size?  You should be able to call it in, say,
> > xf86XVScreenInit and just rely on dixLookupPrivate to allocate the
> > requested size for you.
> 
> I tried initializing the private record in xf86XVScreenInit, but
> xf86XVRegisterOffscreenImages gets called before that, at least in
> some drivers.
> 
> dixRequestPrivate is a no-op after the first call, so this just makes
> it clear that the memory is definitely allocated (assuming you don't
> call xf86XVQueryOffscreenImages without registering them first). I
> don't see a problem for either performance or clarity here; can you
> explain what you're objecting to?

Ah, okay, I didn't realize there was an ordering problem there.  It's kind
of weird that clients are allowed to do that, but given that, calling
dixRequestPrivate each time seems okay.  It might be nice to have a comment
to that effect in xf86XVRegisterOffscreenImages.

> >>       xfree86: use screen privates for exclusive DGA clients
> >
> > Can we ditch DGAClientPrivateKey and combine the two DGA keys into one?
> > I'm worried that we're going to hit PRIV_MAX (currently 256) soon.
> 
> I thought about this. I think a separate patch to merge private keys
> that are always used on different types of objects would be
> worthwhile. This patch follows the existing convention though.

Fair enough.

> A quick check says there's something like 140 keys allocated anywhere
> in the server source tree right now though, so I don't think this is a
> big danger yet.

Cool, thanks for checking.

> > Speaking of that, we should probably increase PRIV_MAX or make it dynamic
> > somehow if we're going to move a lot of stuff to devPrivates.
> 
> It's an implementation detail of privates.c, so making it dynamic is
> trivial, and I doubt the extra memory fetch per private access would
> show up in any profiling.
> 
> Jamey