Re: [Dri-devel] Server-side GLX / DRI issues

On Thu, Mar 27, 2003 at 03:06:03AM +0100, Michel Dänzer wrote: > On Don, 2003-03-27 at 00:37, Keith Whitwell wrote: > > Ian Romanick wrote: > > > Michel Dänzer wrote: > > > > > >> On Mit, 2003-03-26 at 21:22, Ian Romanick wrote: > > >> > > >>> If the paged memory system is only used when DRI is en

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 12:22:48PM -0800, Ian Romanick wrote: > Philip Brown wrote: > >So since it is orthogonal, you should have no objections to lowest-level > >allocation of video memory being done by GLX calling xf86Allocate > >routines, yes? > >(ie: "leave the X core code alone") > > That is

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 09:08:51AM -0800, Ian Romanick wrote: > Michel Dänzer wrote: > >On Mit, 2003-03-26 at 08:45, Philip Brown wrote: > > > >>Video mem is a core X server resource, and should be reserved through the > >>core server, always. > > > >Actually, I thought we're talking about a scheme

Re: [Dri-devel] Server-side GLX / DRI issues

On Don, 2003-03-27 at 00:37, Keith Whitwell wrote: > Ian Romanick wrote: > > Michel Dänzer wrote: > > > >> On Mit, 2003-03-26 at 21:22, Ian Romanick wrote: > >> > >>> If the paged memory system is only used when DRI is enabled, does it > >>> really matter where the code the X server calls is loca

Re: [Dri-devel] Server-side GLX / DRI issues

Ian Romanick wrote: Michel Dänzer wrote: On Mit, 2003-03-26 at 21:22, Ian Romanick wrote: If the paged memory system is only used when DRI is enabled, does it really matter where the code the X server calls is located? Could we make the memory manager some sort of API-registered callback? It

Re: [Dri-devel] Server-side GLX / DRI issues

Michel Dänzer wrote: On Mit, 2003-03-26 at 21:22, Ian Romanick wrote: If the paged memory system is only used when DRI is enabled, does it really matter where the code the X server calls is located? Could we make the memory manager some sort of API-registered callback? It would be one that on

Re: [Dri-devel] Server-side GLX / DRI issues

On Mit, 2003-03-26 at 21:22, Ian Romanick wrote: > > If the paged memory system is only used when DRI is enabled, does it > really matter where the code the X server calls is located? Could we > make the memory manager some sort of API-registered callback? It would > be one that only DRI (and

Re: [Dri-devel] Server-side GLX / DRI issues

Suzy Deffeyes wrote: Jens- I agree with you, supporting HW accelerated indirect rending would be a good thing. Take a look at the DRI high level design doc: http://dri.sourceforge.net/doc/design_high_level.html In section 4.3, Indirect Rendering, there's a section on Multi-rendering in a singl

Re: [Dri-devel] Server-side GLX / DRI issues

Ian Romanick wrote: Jens Owen wrote: Ian, I think you're making a mountain out of a mole hill, but I like the mountain that you're trying to build. Supporting HW accellerated indirect rendering would be a good thing, but it's not necessary for the change you're trying to make. Right. It's

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 12:22:48PM -0800, Ian Romanick wrote: > ... The memory management code that is in the 3D driver (for doing > the allocations and communicating with the DRM) really has to be there. > Moving it into the X server would really hurt performance. There's > really only four

Re: [Dri-devel] Server-side GLX / DRI issues

Philip Brown wrote: So since it is orthogonal, you should have no objections to lowest-level allocation of video memory being done by GLX calling xf86Allocate routines, yes? (ie: "leave the X core code alone") That is what's currently done. The goal was two fold. One (very minor, IMO) goal was

Re: [Dri-devel] Server-side GLX / DRI issues

Andreas Ehliar wrote: On Wed, Mar 26, 2003 at 07:23:09PM +, Keith Whitwell wrote: Actually that's not my code at all, if you're talking about the stuff in common/mm.[ch]. I know it's ended up with my name on it, but that's bogus. I can't remember who's it is, but it's lifted from Utah so ma

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 11:18:18AM -0800, Ian Romanick wrote: > Philip Brown wrote: > > > > > > New client comes in. Requests new corse chunk o' VRAM from GLX > > Oops. we've used up the 16 megs pre-allocated. > > Used to be 11 megs free, but X server has been busy, and there is > > now

Re: [Dri-devel] Server-side GLX / DRI issues

The current memory management system looks like this: Core X routines | V Coarse grained, block oriented cache / paged memory system | V Keith's mmHeap_t code Actually that's not my code at all, if you're talking about the stuff in commo

Re: [Dri-devel] Server-side GLX / DRI issues

Philip Brown wrote: On Wed, Mar 26, 2003 at 09:14:37AM -0800, Ian Romanick wrote: Philip Brown wrote: Consider the GLX_dri_reserve_mem as equivalent to sbrk() Then have a more local memory allocator for subdividing the large chunk. That's going to be a lot more efficient that relying on the XFree

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 09:14:37AM -0800, Ian Romanick wrote: > Philip Brown wrote: > > Consider the GLX_dri_reserve_mem as equivalent to sbrk() > > Then have a more local memory allocator for subdividing the large chunk. > > That's going to be a lot more efficient that relying on the XFree routine

Re: [Dri-devel] Server-side GLX / DRI issues

Jens Owen wrote: Ian, I think you're making a mountain out of a mole hill, but I like the mountain that you're trying to build. Supporting HW accellerated indirect rendering would be a good thing, but it's not necessary for the change you're trying to make. Right. It's not required for what I

Re: [Dri-devel] Server-side GLX / DRI issues

Philip Brown wrote: On Wed, Mar 26, 2003 at 12:10:48AM -0800, Ian Romanick wrote: Philip Brown wrote: Well, okay, there needs to be a little extra handholding between server and client. So, you add a GLX_dri_reserve_mem extension or something that reserves video memory by proxy. Or do it in some

Re: [Dri-devel] Server-side GLX / DRI issues

Michel Dänzer wrote: On Mit, 2003-03-26 at 08:45, Philip Brown wrote: Video mem is a core X server resource, and should be reserved through the core server, always. Actually, I thought we're talking about a scheme where the server is only a client of the DRM memory manager. Yes. It would be a lot

Re: [Dri-devel] Server-side GLX / DRI issues

On Mit, 2003-03-26 at 08:45, Philip Brown wrote: > > Video mem is a core X server resource, and should be reserved through the > core server, always. Actually, I thought we're talking about a scheme where the server is only a client of the DRM memory manager. -- Earthling Michel Dänzer (MrCoop

Re: [Dri-devel] Server-side GLX / DRI issues

http://www.realitydiluted.com/mirrors/reality.sgi.com/ --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?k

Re: [Dri-devel] Server-side GLX / DRI issues

> [KHLS94] Mark J. Kilgard, Simon Hui, Allen A Leinwand, and Dave >Spalding. X Server Multi-rendering for OpenGL and PEX. 8th Annual X >Technical Conference, Boston, Mass., January 25, 1994. Available from >. > > However

Re: [Dri-devel] Server-side GLX / DRI issues

Jens- I agree with you, supporting HW accelerated indirect rending would be a good thing. > Take a look at the DRI high level design doc: > >http://dri.sourceforge.net/doc/design_high_level.html > > In section 4.3, Indirect Rendering, there's a section on Multi-rendering > in a single address

Re: [Dri-devel] Server-side GLX / DRI issues

Ian, I think you're making a mountain out of a mole hill, but I like the mountain that you're trying to build. Supporting HW accellerated indirect rendering would be a good thing, but it's not necessary for the change you're trying to make. Ian Romanick wrote: There is no easy way for the DD

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, 2003-03-26 at 01:15, Ian Romanick wrote: > From a security perspective, people may want to disable direct > rendering. There is a shared memory segment that an "evil" program > could muck with and cause DoS problems. I probably haven't thought > about it enough, but I can't see how wo

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 12:10:48AM -0800, Ian Romanick wrote: > Philip Brown wrote: > > Well, okay, there needs to be a little extra handholding between server and > > client. So, you add a GLX_dri_reserve_mem extension or something that > > reserves video memory by proxy. Or do it in some more dir

Re: [Dri-devel] Server-side GLX / DRI issues

Ian Romanick wrote: Alan Hourihane wrote: On Tue, Mar 25, 2003 at 11:27:17PM +, Keith Whitwell wrote: Alan Hourihane wrote: If there's any architectural reason why we can't use XFree86's module loader for OS indepence here ? The whole point of the drmCommand*() interface is that it's portab

Re: [Dri-devel] Server-side GLX / DRI issues

Philip Brown wrote: On Tue, Mar 25, 2003 at 11:21:22PM -0800, Ian Romanick wrote: Philip Brown wrote: On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote: The idea is that the X server and the 3D driver can use the same memory manager for off-screen memory. That way pixmap cache, text

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 11:21:22PM -0800, Ian Romanick wrote: > Philip Brown wrote: > > On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote: > >>The idea is that the X server and the 3D driver can use the same memory > >>manager for off-screen memory. That way pixmap cache, textures, and

Re: [Dri-devel] Server-side GLX / DRI issues

Philip Brown wrote: On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote: Philip Brown wrote: The core X server should not be making calls into extension modules. Extension modules should be making calls to xfree-exported functions. If there arent sufficient xfree-exported functions, exte

Re: [Dri-devel] Server-side GLX / DRI issues

On Mit, 2003-03-26 at 02:07, Ian Romanick wrote: > > The idea is that the X server and the 3D driver can use the same memory > manager for off-screen memory. That way pixmap cache, textures, and > vertex buffers all get managed in the "same" way and share ALL of off > screen memory. Currently

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote: > Philip Brown wrote: > > The core X server should not be making calls into extension modules. > > Extension modules should be making calls to xfree-exported functions. > > If there arent sufficient xfree-exported functions, extend or ad

Re: [Dri-devel] Server-side GLX / DRI issues

Alan Hourihane wrote: On Tue, Mar 25, 2003 at 11:27:17PM +, Keith Whitwell wrote: Alan Hourihane wrote: If there's any architectural reason why we can't use XFree86's module loader for OS indepence here ? The whole point of the drmCommand*() interface is that it's portable, so I don't see a

Re: [Dri-devel] Server-side GLX / DRI issues

Alan Cox wrote: On Tue, 2003-03-25 at 21:48, Keith Whitwell wrote: The final point that I would like to make is that we're going to NEED to load the DRI driver on the server-side at some point in order to support accelerated server-side rendering. We could then implemented a server-side softwa

Re: [Dri-devel] Server-side GLX / DRI issues

Philip Brown wrote: On Tue, Mar 25, 2003 at 12:37:17PM -0800, Ian Romanick wrote: This could also pave the way for the X server to use the new memory manager that is being developed. We could make some sort of a conduit for the X server to call into the DRI driver to allocate graphics / AGP me

Re: [Dri-devel] Server-side GLX / DRI issues

On Die, 2003-03-25 at 21:37, Ian Romanick wrote: > > In the current GLX visual mechanism, the DDX driver exports an array of > __GLXvisualConfigRec objects that is used by the GLX extension. This is > done because the DDX driver is the only place in the server that knows > what display modes

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 11:33:31PM +, Keith Whitwell wrote: > Alan Hourihane wrote: > >On Tue, Mar 25, 2003 at 11:18:45PM +, Keith Whitwell wrote: > > > My impression is that a patch trying to add a dlopen() call to one of > the xfree86 hosted ddx drivers would be rejected. > >>> >

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 11:27:17PM +, Keith Whitwell wrote: > Alan Hourihane wrote: > >On Tue, Mar 25, 2003 at 10:51:05PM +, Keith Whitwell wrote: > > > >>Gareth Hughes wrote: > >> > >>>Keith Whitwell wrote: > >>> > >>> > Yes, very nice. > > Utah did have some stuff going for i

Re: [Dri-devel] Server-side GLX / DRI issues

Alan Hourihane wrote: On Tue, Mar 25, 2003 at 11:18:45PM +, Keith Whitwell wrote: My impression is that a patch trying to add a dlopen() call to one of the xfree86 hosted ddx drivers would be rejected. Last I looked at the XF86 loader, it had some stuff in it that implied to me that it cou

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 11:18:45PM +, Keith Whitwell wrote: > > >>My impression is that a patch trying to add a dlopen() call to one of > >>the xfree86 hosted ddx drivers would be rejected. > > > > > >Last I looked at the XF86 loader, it had some stuff in it that implied > >to me that it cou

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 12:37:08AM +, Alan Cox wrote: > On Tue, 2003-03-25 at 23:15, Philip Brown wrote: > > There are already AGP (and memory alloc) related calls in the X server > > framework; xf86BindGARTMemory(), xf86EnableAGP(), etc. > > > > The core X server should not be making calls in

Re: [Dri-devel] Server-side GLX / DRI issues

Alan Hourihane wrote: On Tue, Mar 25, 2003 at 10:51:05PM +, Keith Whitwell wrote: Gareth Hughes wrote: Keith Whitwell wrote: Yes, very nice. Utah did have some stuff going for it. It was designed as a server-side-only accelerated indirect renderer. My "innovation" was to figure out tha

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, 2003-03-25 at 23:15, Philip Brown wrote: > There are already AGP (and memory alloc) related calls in the X server > framework; xf86BindGARTMemory(), xf86EnableAGP(), etc. > > The core X server should not be making calls into extension modules. > Extension modules should be making calls to

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 10:51:05PM +, Keith Whitwell wrote: > Gareth Hughes wrote: > >Keith Whitwell wrote: > > > >> > >>Yes, very nice. > >> > >>Utah did have some stuff going for it. It was designed as a > >>server-side-only accelerated indirect renderer. My "innovation" was > >>to figure

Re: [Dri-devel] Server-side GLX / DRI issues

My impression is that a patch trying to add a dlopen() call to one of the xfree86 hosted ddx drivers would be rejected. Last I looked at the XF86 loader, it had some stuff in it that implied to me that it couldn't simply be treated as a wrapper for dlopen(), dlsym(), etc. I don't remember the

Re: [Dri-devel] Server-side GLX / DRI issues

Philip Brown wrote: On Tue, Mar 25, 2003 at 09:48:21PM +, Keith Whitwell wrote: Utah did have some stuff going for it. It was designed as a server-side-only accelerated indirect renderer. My "innovation" was to figure out that the client could pretty easily play a few linker tricks &

Re: [Dri-devel] Server-side GLX / DRI issues

Keith Whitwell wrote: Gareth Hughes wrote: Keith Whitwell wrote: Yes, very nice. Utah did have some stuff going for it. It was designed as a server-side-only accelerated indirect renderer. My "innovation" was to figure out that the client could pretty easily play a few linker tricks & load

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 12:37:17PM -0800, Ian Romanick wrote: > > This could also pave the way for the X server to use the new memory > manager that is being developed. We could make some sort of a conduit > for the X server to call into the DRI driver to allocate graphics / AGP > memory. The

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 09:48:21PM +, Keith Whitwell wrote: > > Utah did have some stuff going for it. It was designed as a server-side-only > accelerated indirect renderer. My "innovation" was to figure out that the > client could pretty easily play a few linker tricks & load that ser

Re: [Dri-devel] Server-side GLX / DRI issues

Gareth Hughes wrote: Keith Whitwell wrote: Yes, very nice. Utah did have some stuff going for it. It was designed as a server-side-only accelerated indirect renderer. My "innovation" was to figure out that the client could pretty easily play a few linker tricks & load that server module with

Re: [Dri-devel] Server-side GLX / DRI issues

Alan Cox wrote: On Tue, 2003-03-25 at 21:48, Keith Whitwell wrote: The final point that I would like to make is that we're going to NEED to load the DRI driver on the server-side at some point in order to support accelerated server-side rendering. We could then implemented a server-side softwa

Re: [Dri-devel] Server-side GLX / DRI issues

Keith Whitwell wrote: Yes, very nice. Utah did have some stuff going for it. It was designed as a server-side-only accelerated indirect renderer. My "innovation" was to figure out that the client could pretty easily play a few linker tricks & load that server module with dlopen(), and then wi

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, 2003-03-25 at 21:48, Keith Whitwell wrote: > > The final point that I would like to make is that we're going to NEED to > > load the DRI driver on the server-side at some point in order to support > > accelerated server-side rendering. We could then implemented a > > server-side softwar

Re: [Dri-devel] Server-side GLX / DRI issues

Ian Romanick wrote: As many of you know, I've been doing a lot of thinking lately about the GLX part of XFree86 & DRI. In that process I've come across a few stumbling blocks. A few things that make forward progress more difficult. To this point my efforts have been focused on the client-sid

[Dri-devel] Server-side GLX / DRI issues

As many of you know, I've been doing a lot of thinking lately about the GLX part of XFree86 & DRI. In that process I've come across a few stumbling blocks. A few things that make forward progress more difficult. To this point my efforts have been focused on the client-side of things. Some o