On Mon, Dec 10, 2001 at 07:29:47PM -0800, [EMAIL PROTECTED] wrote:
> >
> > I'm not sure but maybe this is related to the AGP aperture size as
> > configured in the BIOS setup?
>
> I found out what it is, but I do not know yet what to do about it.
>
> Gareth - could you comment please ?
Sure.
> > > >
> > > > Hi, I am the maintainer of V4L capture module for All-in-Wonder cards.
> > > > I need some help figuring out how to interface with drm.
> > > >
> > > > The problem: the module works fine, except that (at least Radeons) want
> > > > physical memory from AGP addressable range.
On Mon, Dec 10, 2001 at 05:53:32PM -0800, Gareth Hughes wrote:
> On Mon, Dec 10, 2001 at 05:33:09PM -0800, Philip Brown wrote:
> > ...
> > But... isnt there a straightforward mmap type way to access the RAM on
> > board the card, then?
> > Or is it usually "load the data to the aperture, then copy
On Mon, Dec 10, 2001 at 05:33:09PM -0800, Philip Brown wrote:
> On Mon, Dec 10, 2001 at 08:52:26PM +0100, Benjamin Herrenschmidt wrote:
> > ...
> > Some chipsets (and the original agpgart supported those only) can
> > let the CPU access the AGP aperture directly. All mmap had to do
> > was then to
On Mon, Dec 10, 2001 at 08:52:26PM +0100, Benjamin Herrenschmidt wrote:
> ...
> Some chipsets (and the original agpgart supported those only) can
> let the CPU access the AGP aperture directly. All mmap had to do
> was then to map the user pages to the aperture physical pages,
> if they had memory
The point of this patch is to remove a chipset dependency from DRM so it
can cleanly support both the Intel 460GX and an HP IA64 chipset. I would
normally send this to Jeff Hartmann, but he seems to have disappeared,
leaving agpgart without an obvious maintainer.
DRM needs to know the physica
> Try the tunnel demo. For me it went from 0.7fps to 25fps.
For me, numbers are similar. Though, there are problems with fog: tunnel
cannot turn it on (in fact, nothing happens on "f" - the fog is always
off). For pre-pre-pre-alpha, this is not crucual though...
Just one question to gurus:
Supp
On Mon, Dec 10, 2001 at 08:52:26PM +0100, Benjamin Herrenschmidt wrote:
> ...
> Some chipsets (and the original agpgart supported those only) can
> let the CPU access the AGP aperture directly. All mmap had to do
> was then to map the user pages to the aperture physical pages,
> if they had memory
On Mon, 2001-12-10 at 14:16, [EMAIL PROTECTED] wrote:
>
>
> On Mon, 10 Dec 2001, Alan Hourihane wrote:
>
> > On Sun, Dec 09, 2001 at 03:29:35PM -0500, [EMAIL PROTECTED] wrote:
> > >
> > > Hi, I am the maintainer of V4L capture module for All-in-Wonder cards.
> > > I need some help figuring ou
>There's another way? :-/
>My reading of the drivers so far made it seem like an agp driver HAS to do
>all of:
>
>1. allocate actual RAM when an ioctl(ALLOC) is done
>2. "bind" it by making an entry in the GATT when ioctl(BIND) is done
>3. mmap the RAM in step #1 to userspace when an mmap() is req
On Mon, Dec 10, 2001 at 07:14:15PM +0100, Benjamin Herrenschmidt wrote:
> ...
> Please, beware of another problem with AGP. Several chipsets including
> Apple's UniNorth or some ia64 ones can't let the CPU access the AGP
> aperture. So the kernel has to map real physical memory pages into
> the pr
On Mon, Dec 10, 2001 at 10:06:45AM -0800, Philip Brown wrote:
>On Mon, Dec 10, 2001 at 09:56:28AM -0800, Daryll Strauss wrote:
>> On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote:
>> > But I thought that GATT is simply a scatter/gather table, so
>> > you only have to update the GATT wh
ww.hack.sehri.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
>On Mon, Dec 10, 2001 at 09:19:16AM -0800, Gareth Hughes wrote:
>> On Mon, Dec 10, 2001 at 12:39:57AM -0800, Philip Brown wrote:
>> > So I'm looking through the AGP stuff, still learning...
>> > and it seems that there's a whole lot of redundancy in the current API.
>> > ...
>> > The allocate and
On Mon, 10 Dec 2001, Daryll Strauss wrote:
> On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote:
> > But I thought that GATT is simply a scatter/gather table, so
> > you only have to update the GATT when you "allocate and bind" pages.
> > Then, if you "allocate and bind" the whole ran
On Mon, Dec 10, 2001 at 09:56:28AM -0800, Daryll Strauss wrote:
> On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote:
> > But I thought that GATT is simply a scatter/gather table, so
> > you only have to update the GATT when you "allocate and bind" pages.
> > Then, if you "allocate and b
On Mon, Dec 10, 2001 at 07:00:22PM +0100, Alexander Stohr wrote:
> > But I thought that GATT is simply a scatter/gather table, so
> > you only have to update the GATT when you "allocate and bind" pages.
> > Then, if you "allocate and bind" the whole range at once,
> > you're done, and
> > you don
On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote:
>
> But I thought that GATT is simply a scatter/gather table, so
> you only have to update the GATT when you "allocate and bind" pages.
> Then, if you "allocate and bind" the whole range at once, you're done, and
> you dont have to do
> But I thought that GATT is simply a scatter/gather table, so
> you only have to update the GATT when you "allocate and bind" pages.
> Then, if you "allocate and bind" the whole range at once,
> you're done, and
> you dont have to do any cache flushing from that point on.
Huh, a GART window can
On Mon, Dec 10, 2001 at 12:05:47PM +0200, Abraham vd Merwe wrote:
> ...
> It is not always necessary to memory map the device. For instance with the
> I810 driver, just plain 2D, there is no need to mmap the device, but the GTT
> (or GATT if you wish) must be populated because the card has no onbo
On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote:
> But I thought that GATT is simply a scatter/gather table, so
> you only have to update the GATT when you "allocate and bind" pages.
> Then, if you "allocate and bind" the whole range at once, you're done, and
> you dont have to do any
On Mon, Dec 10, 2001 at 09:19:16AM -0800, Gareth Hughes wrote:
> On Mon, Dec 10, 2001 at 12:39:57AM -0800, Philip Brown wrote:
> > So I'm looking through the AGP stuff, still learning...
> > and it seems that there's a whole lot of redundancy in the current API.
> > ...
> > The allocate and bind p
On Mon, Dec 10, 2001 at 12:39:57AM -0800, Philip Brown wrote:
> So I'm looking through the AGP stuff, still learning...
> and it seems that there's a whole lot of redundancy in the current API.
>
> If I'm understanding the sequence properly, generally programs do the
> following:
> 1. open /dev/a
On Sunday 09 December 2001 10:28 pm, you wrote:
> And this is true about the kernel-level API as well. I have just figured
> out that agp_memory_t.memory field is an array of addresses to allocated
> pages - but I have not figured out whether these are physical or not.
The memory[] table currentl
Hi,
On Mon, 2001-12-10 at 14:44, Michael Thaler wrote:
> Hello,
>
> I downloaded the trunk and the mach64 branch from CVS. I compiled
> everything with make world and loaded the mach64 module into the
> kernel. I used XFree 4.10 from debian unstable to test the driver.
>
I don't know what part
Hello,
I downloaded the trunk and the mach64 branch from CVS. I compiled
everything with make world and loaded the mach64 module into the
kernel. I used XFree 4.10 from debian unstable to test the driver.
First I ran glxgears with the libGL that came with debian. I got:
525 frames in 5.0 second
On Mon, 10 Dec 2001, Alan Hourihane wrote:
> On Sun, Dec 09, 2001 at 03:29:35PM -0500, [EMAIL PROTECTED] wrote:
> >
> > Hi, I am the maintainer of V4L capture module for All-in-Wonder cards.
> > I need some help figuring out how to interface with drm.
> >
> > The problem: the module works f
On Sun, Dec 09, 2001 at 03:29:35PM -0500, [EMAIL PROTECTED] wrote:
>
> Hi, I am the maintainer of V4L capture module for All-in-Wonder cards.
> I need some help figuring out how to interface with drm.
>
> The problem: the module works fine, except that (at least Radeons) want
> physical memor
Hi Philip!
> So I'm looking through the AGP stuff, still learning...
> and it seems that there's a whole lot of redundancy in the current API.
>
> If I'm understanding the sequence properly, generally programs do the
> following:
> 1. open /dev/agpgart
> 2. ioctl(ACQUIRE)
> 3. ioctl(INFO) to
Hello
Make the diff using 'diff -u testgart_original.c testgart_modified.c',
which gives a 'unified' version of the output, which is then correctly
unserstood by the 'patch' command.
*Updated* I saw your other mail and the 'patch -c' gets the context
diffs you sent. However, the 'tradition' f
Philip Brown wrote:
> On Mon, Dec 10, 2001 at 08:02:48AM +0100, Nicolas Aspert wrote:
>
>>...
>>Thanks for the patch. I have not looked at it yet, but let me just tell
>>you that I did NOT write testgart.c ;-) I think that Jeff Hartmann did,
>>
Now I have lokked a bit more into your patch.
1
So I'm looking through the AGP stuff, still learning...
and it seems that there's a whole lot of redundancy in the current API.
If I'm understanding the sequence properly, generally programs do the
following:
1. open /dev/agpgart
2. ioctl(ACQUIRE)
3. ioctl(INFO) to determine amountof memory f
32 matches
Mail list logo
