* Reduce the amount of sleep you need
* Cause wounds to heal faster
* Lose weight while your sleeping
* Become less winded when excersizing
* Put color back in grey hair
* Grow hair back where it had once fallen out
* Tighten skin
* Strengthen bones
* Body builders - use this to build your
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
> -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 memory management...
>
>
[snip]
> > Also, using an age variable le
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
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 ha
> -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
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
On Fri, Jan 17, 2003 at 12:42:41PM -0800, Ian Romanick wrote:
> jordan muscott wrote:
> >Greets all,
> >
> >Linux-mandrake 8.1 , kernel 2.4.18
> >PIII
> >ati rage pro - mach64.
> >
> >On the above setup i can get hardware acceleration with the Xfree 3.3.6
> >that came with my distro via GLX. I bui
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
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 lev
jordan muscott wrote:
Greets all,
Linux-mandrake 8.1 , kernel 2.4.18
PIII
ati rage pro - mach64.
On the above setup i can get hardware acceleration with the Xfree 3.3.6
that came with my distro via GLX. I built Xfree 4.2 from the mandrake
8.2 src rpms because i read that the support for my card
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 apertures
cvs server: [11:27:06] waiting for anoncvs_dri's lock in
/cvsroot/dri/xc/xc/extras/freetype2/builds/win32/devel
What do you get?
-Dieter
---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the hi
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 tha
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 discipl
=3Chtml=3E
=3Chead=3E
=3Ctitle=3EDo you remember me=3F=3C=2Ftitle=3E
=3Cmeta http-equiv=3D=22Content-Type=22 content=3D=22text=2Fhtml=3B
charset=3Dwindows-1252=22=3E
=3C=2Fhead=3E
=3Cbody bgcolor=3D=22#FF=22 text=3D=22#00=22=3E
=3Cfont size=3D=225=22=3E=3Ca
href=3D=22http=3A=2F=2Fwww=2El
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 ar
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 m
6828CCQel8
For a Limited Time Only...
An Incredible MAGAZINE SUBSCRIPTION SALE!
You may NOW sign up for :
5 One Year Magazine Subscriptions for a flat rate of
ONLY $35.95!.
THAT IS LESS THAN $0.60 PER MAGAZINE! There are no
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
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 tha
magenta wrote:
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 (forg
I think this needs to go to dri-devel. That's where the busy person lurks,
and it seems to be a good start.
> > Actually there has been some work to create a script which will
> > identify the card and advise which driver to download, but holiday
> > season plus busy people does not make these thi
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
> an
24 matches
Mail list logo
