-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
On Wed, 2005-08-24 at 08:47 -0700, Ian Romanick wrote:
Brian Paul wrote:
I think it would be worthwhile to start a specification document for
this project (or perhaps a wiki page) where the requirements, issues and
proposed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
There's been quite a bit of discussion about this on #dri-devel the past
few days. I thought I'd write up a quick summary and post it to the
list. I know that there are a lot of interested parties that are on the
list, but
On Thu, 2005-09-01 at 11:32 -0700, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
There's been quite a bit of discussion about this on #dri-devel the past
few days. I thought I'd write up a quick summary and post it to the
list. I know that there
At current count we need 6 ioctls for the memory manager. However,
there are only 5 available ioctl numbers available below 0x40. Is it
possible to use numbers above 0x79?
I count 0x08-0x0f, 0x1e-0x1f, 0x2d-0x2f, 0x3b-0x3f, or 18. While it
should be doable to use numbers 0x80 and up,
On Thu, 2005-09-01 at 13:18 -0700, Eric Anholt wrote:
On Thu, 2005-09-01 at 11:32 -0700, Ian Romanick wrote:
At current count we need 6 ioctls for the memory manager. However,
there are only 5 available ioctl numbers available below 0x40. Is it
possible to use numbers above 0x79?
I
Michel Dänzer wrote:
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote:
Alan Cox wrote:
The log design presents numerous opportunities for rogue processes to do
bad things. At some level, that's inherent in the nature of direct
rendering. If you don't trust the processes, don't
On Wed, 2005-08-24 at 09:18 -0600, Brian Paul wrote:
Michel Dänzer wrote:
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote:
Alan Cox wrote:
Other stuff like textures is merely annoyance value. Knowing who owned a
block for cleanup matters and the DRI lock/mem handling on some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
1. I'd like an allocator that can be used outside/independent of the
Xserver. Specifically, an allocator that EGL and EGL drivers can use.
2. There needs to be a way to share memory blocks between processes.
So that an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
On Wed, 2005-08-24 at 09:18 -0600, Brian Paul wrote:
1. The location of the object in memory (perhaps the framebuffer has
to be at the start of memory).
2. Particular byte/word alignments
3. Can we use VRAM and/or AGP
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
1. I'd like an allocator that can be used outside/independent of the
Xserver. Specifically, an allocator that EGL and EGL drivers can use.
2. There needs to be a way to share memory blocks between
The framebuffer (including color, Z, stencil, etc)
Pbuffers
Renderbuffer/Framebuffer objects
Pixel/Vertex buffer objects
Texture images
OpenGL miscellaneous (e.g. vertex/fragment programs)
X server miscellaneous (pixmap cache, etc)
Most of these are fairly static objects.
1. The location
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
In the prototype code that I posted to the list several months ago,
these four things were handled together. Each object has an associated
region ID. The region IDs are allocated to a process by the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
On Wed, 2005-08-24 at 08:47 -0700, Ian Romanick wrote:
Brian Paul wrote:
I think it would be worthwhile to start a specification document for
this project (or perhaps a wiki page) where the requirements, issues and
proposed
Alan Cox wrote:
The framebuffer (including color, Z, stencil, etc)
Pbuffers
Renderbuffer/Framebuffer objects
Pixel/Vertex buffer objects
Texture images
OpenGL miscellaneous (e.g. vertex/fragment programs)
X server miscellaneous (pixmap cache, etc)
Most of these are fairly static objects.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
1. Video card has 8MB.
2. 1MB of the card memory is allocated for the front buffer and pinned.
3. Process A allocates (and commits) a 7MB region for a big texture.
4. Process B allocates (and commits) a 2MB
On Mer, 2005-08-24 at 11:18 -0600, Brian Paul wrote:
2. 1MB of the card memory is allocated for the front buffer and pinned.
3. Process A allocates (and commits) a 7MB region for a big texture.
4. Process B allocates (and commits) a 2MB region for a texture. To do
this, it kick out part
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
In the prototype code that I posted to the list several months ago,
these four things were handled together. Each object has an associated
region ID. The region IDs are allocated to a
Michel Dänzer wrote:
Security is more than just the memory manager. To enforce video memory
protection, we'd have to audit the code and add memory protection to
existing drm modules. That is quite a lot of work, and requires
extensive knowledge of each card. So I don't think it's worth the
Stephane Marchesin wrote:
Now, there is one question that sounds to me like it will have
implications over the whole memory manager design : do we want to
enforce video memory ownership ?
Ok, here is what came out of the irc meeting :
- we don't need to enforce video memory ownership, but
On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote:
Ok, here is what came out of the irc meeting :
- we don't need to enforce video memory ownership, but the drm needs to
be able to track allocation owners anyway, for example if a process dies
unexpectedly.
How expensive would it be
On Tue, 2005-08-23 at 10:00 -0700, Ian Romanick wrote:
Keith Packard wrote:
On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote:
Ok, here is what came out of the irc meeting :
- we don't need to enforce video memory ownership, but the drm needs to
be able to track allocation
On Tue, Aug 23, 2005 at 01:31:43PM -0400, Michel Dänzer wrote:
On Tue, 2005-08-23 at 10:00 -0700, Ian Romanick wrote:
Keith Packard wrote:
On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote:
Ok, here is what came out of the irc meeting :
- we don't need to enforce video
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
Stephane Marchesin wrote:
Now, there is one question that sounds to me like it will have
implications over the whole memory manager design : do we want to
enforce video memory ownership ?
Ok, here is what came out of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote:
Ok, here is what came out of the irc meeting :
- we don't need to enforce video memory ownership, but the drm needs to
be able to track allocation owners anyway, for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
Also, with the current log design for the memory manager, it is possible
for a rogue process to make the log wrap and not call the
force_log_update ioctl, thus being able to create some kind of race
condition where the
Michel Dänzer wrote:
You'd need the same stuff that you need to protect system memory. You'd
need a hardware MMU that could block the accesses. It might be possible
to do it in software by looking at the command stream, but I suspect
that would be pretty expensive. It would be worth a try, I
On Tue, 2005-08-23 at 20:45 +0300, Ville Syrjälä wrote:
On Tue, Aug 23, 2005 at 01:31:43PM -0400, Michel Dänzer wrote:
Another part would be to only allow mapping owned parts of the
framebuffer.
Is there any way to make that work without going to the kernel for each
allocation?
You
On Tue, 2005-08-23 at 20:08 +0200, Stephane Marchesin wrote:
Michel Dänzer wrote:
You'd need the same stuff that you need to protect system memory. You'd
need a hardware MMU that could block the accesses. It might be possible
to do it in software by looking at the command stream, but I
On Tue, Aug 23, 2005 at 11:04:22AM -0700, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
Also, with the current log design for the memory manager, it is possible
for a rogue process to make the log wrap and not call the
force_log_update
On Maw, 2005-08-23 at 20:45 +0300, Ville Syrjälä wrote:
Is there any way to make that work without going to the kernel for each
allocation? Personally I'd like to have the protection even if it
degrades performance slightly.
X allows applications to read the displayed video memory anyway so
On Maw, 2005-08-23 at 20:08 +0200, Stephane Marchesin wrote:
Another part would be to only allow mapping owned parts of the
framebuffer.
You'd have to get the cliprects from a trusted source then...
Memory management hardware isn't that fine grained. Doing cliprect
register access via
On Tue, 2005-08-23 at 21:46 +0100, Alan Cox wrote:
X allows applications to read the displayed video memory anyway so what
is the big deal here ?
X will not always be in control of the full screen.
I'm starting to look at multi-user environments where each user has an X
server which isn't in
The log design presents numerous opportunities for rogue processes to do
bad things. At some level, that's inherent in the nature of direct
rendering. If you don't trust the processes, don't enable direct rendering.
Thats a very poor answer to the problem. DRI needs to be moving towards
Alan Cox wrote:
The log design presents numerous opportunities for rogue processes to do
bad things. At some level, that's inherent in the nature of direct
rendering. If you don't trust the processes, don't enable direct rendering.
Thats a very poor answer to the problem. DRI needs to be
- regions that are marked as preserve have a matching backing store
region in system ram. That region is made of pinned pages.
Do they really need to be pinned? That's a huge waste of memory.
We had this discussion too. The problem is you need the memory
allocated in advance to avoid
On Wed, 24 Aug 2005, Stephane Marchesin wrote:
Alan Cox wrote:
The log design presents numerous opportunities for rogue processes to do
bad things. At some level, that's inherent in the nature of direct
rendering. If you don't trust the processes, don't enable direct
rendering.
Thats a
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote:
Alan Cox wrote:
The log design presents numerous opportunities for rogue processes to do
bad things. At some level, that's inherent in the nature of direct
rendering. If you don't trust the processes, don't enable direct rendering.
On Tue, Aug 23, 2005 at 10:49:28PM -0400, Michel Dänzer wrote:
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote:
Alan Cox wrote:
Its critical that the kernel knows what memory on the video space is
being used for command queue and protects it. From the description of
the SiS
Ian Romanick a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There's been quite a bit of discussion about this on #dri-devel the past
few days. I thought I'd write up a quick summary and post it to the
list. I know that there are a lot of interested parties that are on the
list, but
On Thu, 18 Aug 2005 16:53:37 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
[1] http://marc.theaimsgroup.com/?l=mesa3d-devm=01398019810w=2
Couple links on the subject:
http://doom-ed.com/john-carmack/virtualized-video-card-local-memory-is-the-right-thing.html
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There's been quite a bit of discussion about this on #dri-devel the past
few days. I thought I'd write up a quick summary and post it to the
list. I know that there are a lot of interested parties that are on the
list, but who don't hang out in
41 matches
Mail list logo
