> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ian Romanick
> Sent: Friday, January 24, 2003 12:29 PM
> To: DRI developer's list
> Subject: [Dri-devel] 64-bit kernel, 32-bit user. Possible? Painful?
>
>
> So, I was thinking about some CPUs that are
>
> 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
> -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
> -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 Ha
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
Ian,
I meant 4096 bytes, I'll fix it.
Btw, you wouldn't have happened to note where the typos were did you? If
you did could you forward the sections where the typos were to me?
-Jeff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ian Ro
Something that has always been requested of me as the agpgart maintainer is
for an operation that could just give someone a block of agp memory at an
arbitrary location in the aperture. I never kept around the necessary data
to make that sort of decision, however during the latest round of
Well after spending some time today reviewing, polishing and extending this
document I would like to accounce that I've made it available in the agpgart
module in the repository. There currently is an html version and Open
Office version of the document.
Now people have a reference
[EMAIL PROTECTED]]On Behalf Of Linus
Torvalds
Sent: Friday, January 10, 2003 10:46 PM
To: Jeff Hartmann
Cc: Dieter Nützel; [EMAIL PROTECTED]
Subject: RE: [Dri-devel] [ANNOUNCE] AGPGART Version 2.0
On Fri, 10 Jan 2003, Jeff Hartmann wrote:
>
> I have been in contact with Dave Jones, and I&#
rt vm
stuff.
-Jeff
-Original Message-
From: Dieter Nützel [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 9:32 PM
To: Jeff Hartmann; [EMAIL PROTECTED]
Cc: Dave Jones @SunWave1
Subject: Re: [Dri-devel] [ANNOUNCE] AGPGART Version 2.0
Am Samstag, 11. Januar 2003 03:59 schrieb
I'm pleased to announce the long awaited 2.0 release of the linux agpgart
kernel module. It has significant internal improvements over the previous
version, and it provides the infrastructure to completely support AGP 3.0
devices. While it does not provide implementations for a few bits o
Alan,
I know we have talked about this issue before, but I want to rehash. The
statement that only what the bios programs is not entirely correct, but this
does hold true for some chipsets where we don't know all the details of agp
mode switching. In fact the agp specification does not r
Keith Whitwell wrote:
> Benjamin Herrenschmidt wrote:
>
>>> HOWEVER, if you tied the GART mapping to the DRM lock, you might be ok.
>>> That gives you the required system exclusion, and if you make it an
>>> explicit "get my GART context" function that is only called under
>>> the DRM
>>> lock
David S. Miller wrote:
>From: "Mike A. Harris" <[EMAIL PROTECTED]>
>Date: Wed, 12 Jun 2002 21:39:23 -0400 (EDT)
>
>Basically, someone has asked for me to default AGPMode to 4 in
>our config file, which I thought was absolutely crazy. The claim
>is that AGP defaulted to
Mike A. Harris wrote:
> On Wed, 12 Jun 2002, David S. Miller wrote:
>
>> Date: Wed, 12 Jun 2002 18:08:37 -0700 (PDT)
>> From: David S. Miller <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]
>> Content-Type: Text/Plain; charset=us-ascii
>> Subject: Re: [Dri-devel] Default AG
Looks good. I'll forward them tomorrow.
-Jeff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bjorn Helgaas
Sent: Monday, April 01, 2002 2:23 PM
To: Jeff Hartmann
Cc: [EMAIL PROTECTED]
Subject: [Dri-devel] [PATCH] agpgart support for HP ZX1
I would do some maintainance on the I830, but unfortunately I don't have
hardware anymore. I have a driver here thats mostly the way to Mesa 3.5 and
I would assume getting it to 4.0 wouldn't be hard. If anyone wants to send
or loan me a production I830, I can work on getting this port done.
---
n the I810 anyhow).
Add the fields to the top of the user space declaration and you should still
work correctly.
-Jeff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Jens Owen
Sent: Tuesday, April 02, 2002 11:33 PM
To: dri-devel
Cc: Jeff Hartmann
Subject:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kevin E
Martin
Sent: Thursday, March 28, 2002 8:25 AM
To: David Dawes
Cc: dri-devel
Subject: Re: [Dri-devel] Restoring DRM Library Device Independence
> I'm losing track of what the goal was with the chan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jens Owen
Sent: Wednesday, March 27, 2002 6:23 AM
To: Alan Hourihane
Cc: dri-devel
Subject: Re: [Dri-devel] Restoring DRM Library Device Independence
Alan Hourihane wrote:
>
> On Tue, Mar 26, 2002 at 10:3
-
From: Bjorn Helgaas [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 04, 2002 9:53 AM
To: Jeff Hartmann
Cc: Chris Ahna; dri-devel
Subject: agpgart/DRM page_mask changes
Hi Jeff,
I'm still trying to resolve this issue for clean support of both the
Intel 460GX and the corresponding HP IA64 ch
> About the Mesa backing store for textures, is there any reason why this
> memory cannot be mapped into AGP space? Admittedly, my knowledge of AGP
is
> very thin, but I always thought that you had some amount of virtual AGP
> address space that you could map to basically arbitrary physical pag
Sottek, Matthew J wrote:
> This is a repost with the patch against 2.4.17 attached. I think Jeff
> is back on the list so I'll save him from having to read the archives
> for the original.
>
> -Matt
>
>
>
> I posted a RFC about a new type of "Shared" agp memory a while back
> but didn't get
Stephen C. Tweedie wrote:
> Hi,
>
> On Mon, May 21, 2001 at 01:25:59PM -0600, Jeff Hartmann wrote:
>
>> Could you make a debug build (add "#define DoLoadableServer NO" to your
>> host.def), and step through the RADEONSave and RADEONModeInit functions
>&
Stephen C. Tweedie wrote:
> Hi,
>
> On Mon, May 21, 2001 at 08:53:56AM -0600, Jeff Hartmann wrote:
>
>> seeing. I need to spend some time with an AMD engineer to get AGP
>> completely stable on all the Irongate revisions. I have been told there
>> are some
Stephen C. Tweedie wrote:
> Hi,
>
>> On Sat, May 19, 2001 at 02:10:43PM +1000, Gareth Hughes wrote:
>>
>>> I'm currently working on some kernel-related tasks, but I can take a
>>> look into the problems you (and others) have mentioned regarding the
>>> Radeon driver early next week. Are you ru
Mike A. Harris wrote:
> On Thu, 17 May 2001, Will Newton wrote:
>
>>> Unfortunately, until 4.x supports all the hardware, or at least
>>> the hardware that we consider important, we need to ship 3.3.6
>>> servers in addition to 4.x, and that has some really crummy side
>>> effects, like having t
Jeffrey W. Baker wrote:
>
> On Thu, 3 May 2001, Brian Paul wrote:
>
>> Mark Allan wrote:
>>
>>> Brian Paul wrote:
>>>
> On Radeon we aren't doing TCL, cube textures, 3D textures and only
> support 2 of the 3 texture units. There's probably a few other things
> but that's off the
Karl Lessard wrote:
>
>
> Jeff Hartmann wrote:
>
>> Fred Black wrote:
>>
>>> Hello everyone,
>>>
>>> I've been reading about how drm works and going through some code.
>>> To understand the whole thing I'm trying a c
Fred Black wrote:
> Hello everyone,
>
> I've been reading about how drm works and going through some code. To
> understand the whole thing I'm trying a couple of stuff. But I now
> need some help.
>
> I'm trying to find a way for sending some intructions through bus
> mastering. I underst
Sottek, Matthew J wrote:
> All,
> I'm doing a direct rendered HWMC (XvMC protocol) driver for the i81x, I am
> compiling the drm Libs outside of the X server and have run into a problem.
> The
> current Linux kernel is allocating minor numbers for the device dynamically,
> but
> the drm Libs don
Bas van den Heuvel wrote:
> Hi all,
>
> I've wrote a Message a few days ago telling that Quake's running slow at
> the moment using the current DRI-CVS
>
> Now I've noticed that the vid card is not using an IRQ anymore (with
> 4.0.3 I saw a mga@pci:1:0:0 or equiv in /proc/interrupts), Also
> It
Kevin E Martin wrote:
> On Tue, Apr 03, 2001 at 10:01:38AM -0600, Jeff Hartmann wrote:
>
>> Jay Estabrook wrote:
>>
>>> I've got a problem with a PCI Radeon on an Alpha that I've just about
>>> started tearing my hair out over, and I don't
Jay Estabrook wrote:
> I've got a problem with a PCI Radeon on an Alpha that I've just about
> started tearing my hair out over, and I don't have that much to
> waste, hence my plea for help... ;-}
>
> Background: ported the pcigart-0-0-1-branch to Alpha and successfully
> ran OpenGL apps (gears
Joseph Carter wrote:
> On Thu, Mar 29, 2001 at 01:36:40PM -0700, Jeff Hartmann wrote:
>
>>> I haven't, I'll comment the drm/dri modules out and see how that works.
>>> Just to be on the safe side, I will also make sure radeon/agpgart are not
>>> loade
Trond Eivind Glomsrød wrote:
> Jeff Hartmann <[EMAIL PROTECTED]> writes:
>
>> Are you using the radeon module from the kernel? If you are this
>> could possibly be a source of the problems. If you are using DRI CVS
>> use the kernel modules from the CVS tree. T
Joseph Carter wrote:
> On Fri, Mar 30, 2001 at 06:07:19AM +1000, Gareth Hughes wrote:
>
>>> Current speculation is that it might be some issue with agpgart and my
>>> Abit KT-7A.. Of course, since it's crashing in 2D, I don't see how that
>>> can be the source of the problem.
>>
>> If the DRI
Joseph Carter wrote:
>
> Current speculation is that it might be some issue with agpgart and my
> Abit KT-7A.. Of course, since it's crashing in 2D, I don't see how that
> can be the source of the problem.
It actually VERY unlikely that agpgart is your problem. VIA support has
been pretty so
38 matches
Mail list logo
