Sven Luther wrote:
On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote:
1. Single-copy textures
Right now each texture exists in two or three places. There is a copy
in on-card or AGP memory, in system memory (managed by the driver), and
in application memory. Any solution should
Jeff Hartmann wrote:
2. We consider the block or group of blocks as an entire unit, everything
is done on units, not individual pieces of the blocks. That prevents people
swapping out the first page of a group of textures and someone having to
wait for just that block to come back.
I believe
On Mon, Jan 20, 2003 at 09:30:50AM -0800, Ian Romanick wrote:
Sven Luther wrote:
On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote:
1. Single-copy textures
Right now each texture exists in two or three places. There is a copy
in on-card or AGP memory, in system memory
Sven Luther wrote:
On Mon, Jan 20, 2003 at 09:30:50AM -0800, Ian Romanick wrote:
Sven Luther wrote:
On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote:
1. Single-copy textures
Right now each texture exists in two or three places. There is a copy
in on-card or AGP memory, in
On Mon, Jan 20, 2003 at 11:15:18AM -0800, Ian Romanick wrote:
But that is not reason for not supporting it or something, who knows,
Creative and 3Dlabs may release a consumer board supporting those next
year, and there will be lot of those around.
Right, but without documentation, it's hard
The potential problem is there are somethings that can't be tracked by a
simple age. The one thing I can think of is back-buffers. An
application might have several buffer-swap operations that are blocked
waiting for a certain vertical blank number. There could be other
rendering
On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote:
What follows is the collected requirements for the new DRI memory
manager. This list is the product of several discussions between Brian,
Keith, Allen, and myself several months ago. After the list, I have
included some of my
On Thu, Jan 16, 2003 at 11:03:21PM -0800, Allen Akin wrote:
On Thu, Jan 16, 2003 at 10:16:30PM -0800, magenta wrote:
|
| Should it even be possible for one process to swap out other processes'
| context data?
In the same way that one process can cause the ordinary memory pages of
another
Am Freitag, 17. Januar 2003 08:42 schrieb magenta:
On Thu, Jan 16, 2003 at 11:03:21PM -0800, Allen Akin wrote:
On Thu, Jan 16, 2003 at 10:16:30PM -0800, magenta wrote:
| Should it even be possible for one process to swap out other processes'
| context data?
In the same way that one
Ian,
I had a chance to read your ideas on memory managment last night. First
off, I'd like to thank you for doing a very good job of collecting
requirements and then seperating out your ideas for implementation.
This level of discipline really helps me understand where you are
constrained by
Ian,
I've looked through your general proposal and it looks really good. Here
are some implementation things I've been thinking about.
That may not be possible. Right now the blocks are tracked in the
SAREA, and that puts an upper limit on the number of block available.
On a 64MB
Jens Owen wrote:
Ian,
I had a chance to read your ideas on memory managment last night. First
off, I'd like to thank you for doing a very good job of collecting
requirements and then seperating out your ideas for implementation. This
level of discipline really helps me understand where you
Am Freitag, 17. Januar 2003 18:37 schrieb Jens Owen:
Ian,
I had a chance to read your ideas on memory managment last night. First
off, I'd like to thank you for doing a very good job of collecting
requirements and then seperating out your ideas for implementation.
This level of discipline
On Thu, Jan 16, 2003 at 11:42:31PM -0800, magenta wrote:
| I'd personally take the school of thought that if the user is running a
| game which takes up 60MB of texture memory and then tries to concurrently
| launch something which takes up another 60MB of texture memory, it's their
| own fault
Jeff Hartmann wrote:
That may not be possible. Right now the blocks are tracked in the
SAREA, and that puts an upper limit on the number of block available.
On a 64MB memory region, the current memory manager ends up with 64KB
blocks, IIRC. As memories get bigger (both on-card and AGP
Dieter Nützel wrote:
Am Freitag, 17. Januar 2003 18:37 schrieb Jens Owen:
Ian,
I had a chance to read your ideas on memory managment last night. First
off, I'd like to thank you for doing a very good job of collecting
requirements and then seperating out your ideas for implementation.
This
On Fri, Jan 17, 2003 at 11:26:02AM -0800, Allen Akin wrote:
On Thu, Jan 16, 2003 at 11:42:31PM -0800, magenta wrote:
| I'd personally take the school of thought that if the user is running a
| game which takes up 60MB of texture memory and then tries to concurrently
| launch something which
On Fri, Jan 17, 2003 at 12:09:58PM -0800, Ian Romanick wrote:
struct memory_block {
u32 age_variable;
u32 status;
};
Where the age variable is device dependant, but I would imagine in most
cases is a monotonically increasing unsigned 32-bit number. There needs
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ian Romanick
Sent: Friday, January 17, 2003 2:10 PM
To: DRI developer's list
Subject: Re: [Dri-devel] The next round of texture memory management...
Jeff Hartmann wrote:
That may not be possible
Jeff Hartmann wrote:
struct memory_block {
u32 age_variable;
u32 status;
};
Where the age variable is device dependant, but I would imagine in most
cases is a monotonically increasing unsigned 32-bit number. There needs to
be a device driver function to check if an age has happened on the
magenta wrote:
On Fri, Jan 17, 2003 at 12:09:58PM -0800, Ian Romanick wrote:
struct memory_block {
u32 age_variable;
u32 status;
};
Where the age variable is device dependant, but I would imagine in most
cases is a monotonically increasing unsigned 32-bit number. There needs to
be a device
On Fri, Jan 17, 2003 at 08:13:05PM -0600, Jeff Hartmann wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ian Romanick
Sent: Friday, January 17, 2003 7:12 PM
To: DRI developer's list
Subject: Re: [Dri-devel] The next round of texture
What follows is the collected requirements for the new DRI memory
manager. This list is the product of several discussions between Brian,
Keith, Allen, and myself several months ago. After the list, I have
included some of my thoughts on the big picture that I see from these
requirements.
On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote:
1. In a scheme like this, how could processes be forced to update the
can-swap bits on blocks that they own?
Should it even be possible for one process to swap out other processes'
context data? Alternatively (forgive me if
On Thu, Jan 16, 2003 at 10:16:30PM -0800, magenta wrote:
|
| Should it even be possible for one process to swap out other processes'
| context data?
In the same way that one process can cause the ordinary memory pages of
another process to be swapped out, I'd say yes.
As the old saying goes,
25 matches
Mail list logo
