On Tue, 05 Aug 2003 12:00:50 -0600
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Ian Romanick wrote:
> > Ian Romanick wrote:
> >
> >> I'm also having second thoughts about allowing drivers to add function
> >> calls to the GLX dispatch table. This is a global table that has no
> >> way to identify the "owner" of a dispatch function. This
> >> functionality is currently only used by a single feature of the r200
> >> driver. I think we'd be better off adding proper support for
> >> GLX_NV_vertex_array_range and GLX_MESA_agp_offset, hackish though they
> >> are, than supporting __glXRegisterGLXFunction. There's just way too
> >> much that can go wrong with it in a multi-card environment.
> >>
> >> It should be easy enough to add entry-points for glXAllocateMemoryNV,
> >> glXFreeMemoryNV, and glXGetAGPOffsetMESA to the __DriverAPIRec. Is
> >> that okay with you, Keith?
> >
> >
> > I'm going to *strongly* vote that we axe these interfaces altogether.
> > Aparently, the folks at Nvidia didn't care too much about multi-card
> > environments when the created {GLX,WGL}_NV_vertex_array_range. The spec
> > says "Because wglAllocateMemoryNV and wglFreeMemoryNV are not OpenGL
> > rendering commands, these commands do not require a current context."
> > However, there is no screen / display information passed into the
> > functions. How is the API supposed to identify the card to allocate
> > memory on?
> >
> > GLX_MESA_agp_offset isn't any better. It has the same "context free"
> > nature and doesn't have any screen / display information. What about
> > the case of a AGP card and a PCI card w/PCIGART in the same system?
> >
> > I know that this isn't the use-cases for which these extensions were
> > added to DRI, but we still have to support this stuff in the "general"
> > case. I am *very* open to suggestions of how to fix this *and* keep
> > everybody happy. :)
>
> I'm happy to drop these once we have identified & implemented a suitable
> replacement.
I was just about to start working on a patch that drops them. I don't
know enough about the kinds of extensions this will be used for to
suggest a good replacement. But the existing interfaces for registring
new glx functions and adding new extensions is plain broken as it
doesn't handle multi-head configurations at all. And it is not used
either.
Therefore I think we can drop it for the sake of clarity and
correctness. When someone comes up with a good replacement it can still
be added.
Note that with the changes I'm proposing drivers will still be able to
enable extensions that already have client support in libGL and for
which they implement direct rendering support. Furthermore this will
work correctly with multi-head and drivers will be able to enable
extensions conditionally depending on e.g. actual hardware support.
>
> Keith
>
Felix
------------ __\|/__ ___ ___ -------------------------
Felix ___\_e -_/___/ __\___/ __\_____ You can do anything,
Kühling (_____\Ä/____/ /_____/ /________) just not everything
[EMAIL PROTECTED] \___/ \___/ U at the same time.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
