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
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
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
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
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
-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 for
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
24 matches
Mail list logo
