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 where the
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 what's
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 enabled, does it
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
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 direct
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 would
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
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!
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
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
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
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
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 routines
to
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
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
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 only 8 megs
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
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
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
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
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
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 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 located? Could we
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
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
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 software-only
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 with
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
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 server
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. There
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
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
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 that the client
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
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 that
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 into
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 couldn't simply
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 the
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
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
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
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 add new
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
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 it. It was designed as a
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.
Last I looked at
45 matches
Mail list logo
