-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
>>>pr
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 0x7
> > 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
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 t
-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
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
t
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
-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 commi
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
On Maw, 2005-08-23 at 14:48 -0700, Keith Packard wrote:
> I'm starting to look at multi-user environments where each user has an X
> server which isn't in control of the whole screen, but rather just
> paints X windows into off-screen memory where an external trusted
> application can take those ap
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.
1.
-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
>>>pr
On Wed, 2005-08-24 at 08:47 -0700, 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 ne
> 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 l
-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 t
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 processes.
-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
-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 off
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/me
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 en
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
>
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 r
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
> >>- 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 advan
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 mov
> 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
be
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
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 acces
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 s
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_
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, bu
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
> allocatio
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 s
-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 th
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
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
-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 anywa
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
-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 ca
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 t
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 w
On Thu, 18 Aug 2005 16:53:37 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
> [1] http://marc.theaimsgroup.com/?l=mesa3d-dev&m=01398019810&w=2
Couple links on the subject:
http://doom-ed.com/john-carmack/virtualized-video-card-local-memory-is-the-right-thing.html
http://appft1.uspto.gov/netacg
-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 #dri-
43 matches
Mail list logo
