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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Mackerras wrote:
> I found why my G5 was crashing when using the linux-2.6 version of the
> DRM + git-drm.patch from 2.6.13-rc6-mm1, but not with the CVS DRM.
> The reason was that dev->agp->cant_use_aperture wasn't getting set,
> and the reason
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
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4150
--- Additional Comments From [EMAIL PROTECTED] 2005-08-23 12:49 ---
(In r
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
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4207
[EMAIL PROTECTED] changed:
What|Removed |Added
--
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=4207
Summary: Build is failing unable to find "r200_vtxtmp_x86.S"
Pro
24 matches
Mail list logo
