RE: [Dri-devel] agp: what if memory is fragmented?

2002-01-07 Thread Alexander Stohr

 From: Philip Brown [mailto:[EMAIL PROTECTED]]
 I thought that was just from the perspective of the graphics card.

A GART memory mapping is a memory range that is visible from
the grafics card (if on AGP socket) and from the CPU (or CPUs).

The GART memory area is looking just as a PCI card that has mapped
some amount of memory to the bus. Its a linear chung of memory
in terms of the bus scope and therefore has a physical base address
and its range is contiguous on the bus.

The grafics card simply uses physical adressing.
The CPU muss call the OS to do a remap on those physical range,
as it has to do for any other sort of PCI adapter memory.

 But you are saying that ALL AGP supporting motherboards will remap
 their aperture range, both for the graphics card, AND the cpu?

The motherboard chipset do remap a bunch of individual pages into
a single GART memory area. Its view is independent and seperate
from the regular location of the main memory, there is no overlapping.
GART means an aditional view of the same with the advantage of
getting memory contiguous for the grafics adapter, even if several
could handle fragmentation without that unit. (the CPU already has 
a sufficient paging unit.)

 In which case... doesnt that screw up the OS considerably, to 
 suddenly have a large chunk of memory change its apparent contents? :-/

If you have multiprocessing, a grafics co-processor, a busmaster or
a cpu-external memory manager, then you must flus CPU read or write
caches at certain points of modifications in the sub system.

 I dont know of any kernel routines under solaris that tell the kernel,
 Stop using this specific physical address range now: I'm going to
  take it over

You first allocate pages in main memory before starting to remap them
via GART. After use you have to do this in the reverse direction.

 Also.. seems like if you have a system that has a large amount of memory,
 you would then lose twice the amount of memory you allocate, since a
 previously usable chunk of memory now gets shadowed to another section of
 memory.

You have to mark the memory as used. But its only a single location,
so this single memory is useable for exactly one purpose only.
Its single but shared, multiple visible, magically mirrored, purple-dotted
memory.

The only thing that you need in advance is a memory manager, that
tracks which ranges of the GART range are used and which are free.

 Yeuk.

I thought you are called Philip. :-)
Regards
Alex.


___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Mach64 DMA

2002-01-07 Thread Manuel Teira

Hello again. First of all, happy new year to everybody.

Well, after the holidays, I would like to recover the development in the 
mach64 branch. I started today to investigate the DMA stuff because I think 
that perhaps Frank is very busy and he has no time to do this work. The DMA 
problem was discovered aprox. Oct 21th and we have no news about any progress 
in  DMA. I'm sure  that Frank would do it better than me, but I can try.

And now, the questions:

I've been looking at the r128 freelist implementation, so I've derived that 
the register called R128_LAST_DISPATCH_REG (actually R128_GUI_SCRATCH_REG1) 
is used to store the age of the last discarded buffer. So, the 
r128_freelist_get is able to wait for a discarded buffer if there's no free 
buffer available.

Could this be made in the mach64 driver, say with MACH64_SCRATCH_REG1 ? In my 
register reference it says that these registers can be for exchanging 
information between the BIOS and card drivers, so, is sane to use them for 
this task?

I've also seen that there's no r128_freelist_put (it's present in mga driver, 
for example). Isn't it necessary? 

And, when is a buffer supposed to be discarded. Is this situation produced in 
the client side?


Best regards.

--
Manuel Teira


___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] via kt266a and the Radeon 8500 (QL)

2002-01-07 Thread Noah Romer

I have a Shuttle AK31 Rev3 motherboard (Athlon XP 1800 cpu) and am trying
to get XWindows working. My video card is an ATI Radeon 8500 (QL). I'm 
using XFree86 4.1.99.4 (cvs). With the 2.4.7-10 kernel from Red Hat 7.2, X
will run, but w/o agp/dri/drm support. I've tried updating to the 2.4.16
kernel and the kernel at least claims to be providing agp support, but
when I run startx w/ the 2.4.16 kernel, my monitor loses sync and goes
into its power saving mode and the only thing I can do is hit crtl-alt-del
to reboot. 

The one thing that sticks out to me is that, with the 2.4.16 kernel, the
agpgart driver says the chipset is a KT266 (but not KT266A), but the drm
driver says the chipset is a KT133.

The relevant sections of dmesg output and /var/log/XFree86.0.log, running
2.4.7-10 - 

dmesg output (agpgart doesn't load because it doesn't recognise the
chipset):
[drm] Initialized radeon 1.1.1 20010405 on minor 0

XFree86.0.log:
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmGetBusid returned ''
(II) RADEON(0): [drm] loaded kernel module for radeon driver
(II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0906000
(II) RADEON(0): [drm] mapped SAREA 0xe0906000 to 0x40017000
(II) RADEON(0): [drm] framebuffer handle = 0xe000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(EE) RADEON(0): [agp] AGP not available
(EE) RADEON(0): [drm] failed to remove DRM signal handler
(II) RADEON(0): [drm] removed 1 reserved context for kernel
DRIUnlock called when not locked
(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0906000 at
0x40017000


running the 2.4.16 kernel -
dmesg output:

Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 440M
agpgart: Detected Via Apollo Pro KT266 chipset
agpgart: AGP aperture is 64M @ 0xe800
[drm] Initialized tdfx 1.0.0 20010216 on minor 0
[drm] AGP 0.99 on VIA Apollo KT133 @ 0xe800 64MB
[drm] Initialized radeon 1.1.1 20010405 on minor 1

XFree86.0.log:

drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 1
drmOpenDevice: node name is /dev/dri/card1
drmOpenDevice: open result is 6, (OK)
drmGetBusid returned ''
(II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe08cd000
(II) RADEON(0): [drm] mapped SAREA 0xe08cd000 to 0x40017000
(II) RADEON(0): [drm] framebuffer handle = 0xe000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [agp] Mode 0x1f000211 [AGP 0x1106/0x3099; Card
0x1002/0x514c]
(II) RADEON(0): [agp] 8192 kB allocated with handle 0xe08d
(II) RADEON(0): [agp] ring handle = 0xe800
(II) RADEON(0): [agp] Ring mapped at 0x4423a000
(II) RADEON(0): [agp] ring read ptr handle = 0xe8101000
(II) RADEON(0): [agp] Ring read ptr mapped at 0x40019000
(II) RADEON(0): [agp] vertex/indirect buffers handle = 0xe8102000
(II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x4433b000
(II) RADEON(0): [agp] AGP texture map handle = 0xe8302000
(II) RADEON(0): [agp] AGP Texture map mapped at 0x4453b000
(II) RADEON(0): [drm] register handle = 0xed00
(II) RADEON(0): [dri] Visual configs initialized
(II) RADEON(0): CP in BM mode
(II) RADEON(0): Using 8 MB AGP aperture
(II) RADEON(0): Using 1 MB for the ring buffer
(II) RADEON(0): Using 2 MB for vertex/indirect buffers
(II) RADEON(0): Using 5 MB for AGP textures

Any sugestions? I've run out of ideas.

P.S. I'll follow any responses on the list archive, but if you could CC
me, I'd appreciate it.

--
Noah Romer  |Calm down, it's only ones and zeros. - this message
[EMAIL PROTECTED]   |brought to you by The Network
PGP key available   |Time will have its say, it always does. - Celltrex
by finger or email  |from Flying to Valhalla by Charles Pellegrino




___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] via kt266a and the Radeon 8500 (QL)

2002-01-07 Thread Michel Dänzer

On Mon, 2002-01-07 at 20:32, Noah Romer wrote:
 I have a Shuttle AK31 Rev3 motherboard (Athlon XP 1800 cpu) and am trying
 to get XWindows working. My video card is an ATI Radeon 8500 (QL). I'm 
 using XFree86 4.1.99.4 (cvs). With the 2.4.7-10 kernel from Red Hat 7.2, X
 will run, but w/o agp/dri/drm support.

Don't bother, the 8500 isn't supported for 3D yet.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] via kt266a and the Radeon 8500 (QL)

2002-01-07 Thread Noah Romer

On 7 Jan 2002, Michel [ISO-8859-1] Dänzer wrote:

 On Mon, 2002-01-07 at 20:32, Noah Romer wrote:
  I have a Shuttle AK31 Rev3 motherboard (Athlon XP 1800 cpu) and am trying
  to get XWindows working. My video card is an ATI Radeon 8500 (QL). I'm 
  using XFree86 4.1.99.4 (cvs). With the 2.4.7-10 kernel from Red Hat 7.2, X
  will run, but w/o agp/dri/drm support.
 
 Don't bother, the 8500 isn't supported for 3D yet.

I'm not really looking for 3d support. What I'm looking for is agp and drm
support (dri-devel is listed as the maintainter list for DRM in the linux
kernel). I'd like to be able to use some of the video tools available for
linux, all of those tools, however, require Xv support in XFree86. Xv
support, as far as I can figure, requires DRM support. I've tried several
other mailing list xpert (the XFree list) and linux-kernel. At this point,
I've run out of ideas. I'm not sure if the problem is w/ the kernel's
support for the VIA KT266A chipset or w/ the support for the Radeon 8500.
I'm leaning towards the latter, as there is a post on dri-users about
someone using a Radeon AWI (not familiar with this version of the card)
along with a KT266A based motherboard.

I guess I'll be buying another video card (perhaps a Matrox G450).

--
Noah Romer  |Listen, I'm a politician which means I'm a cheat and
[EMAIL PROTECTED]   |a liar, and when I'm not kissing babies I'm stealing 
PGP key available   |their lollipops.  
by finger or email  |   - Jeffrey Pelt _Hunt for Red October_


___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] via kt266a and the Radeon 8500 (QL)

2002-01-07 Thread Michel Dänzer

On Mon, 2002-01-07 at 22:16, Noah Romer wrote:
 On 7 Jan 2002, Michel [ISO-8859-1] Dänzer wrote:
 
  On Mon, 2002-01-07 at 20:32, Noah Romer wrote:
   I have a Shuttle AK31 Rev3 motherboard (Athlon XP 1800 cpu) and am trying
   to get XWindows working. My video card is an ATI Radeon 8500 (QL). I'm 
   using XFree86 4.1.99.4 (cvs). With the 2.4.7-10 kernel from Red Hat 7.2, X
   will run, but w/o agp/dri/drm support.
  
  Don't bother, the 8500 isn't supported for 3D yet.
 
 I'm not really looking for 3d support. What I'm looking for is agp and drm
 support (dri-devel is listed as the maintainter list for DRM in the linux
 kernel).

I'm afraid no 3D support means no DRM support either.

 I'd like to be able to use some of the video tools available for
 linux, all of those tools, however, require Xv support in XFree86. Xv
 support, as far as I can figure, requires DRM support.

It doesn't.

I understand Xv for the 8500 is broken in XFree86 CVS, gatos.sf.net
apparently has a fix.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] via kt266a and the Radeon 8500 (QL)

2002-01-07 Thread Noah Romer

On 7 Jan 2002, Michel [ISO-8859-1] Dänzer wrote:

 On Mon, 2002-01-07 at 22:16, Noah Romer wrote:
  On 7 Jan 2002, Michel [ISO-8859-1] Dänzer wrote:
  
   On Mon, 2002-01-07 at 20:32, Noah Romer wrote:
I have a Shuttle AK31 Rev3 motherboard (Athlon XP 1800 cpu) and am trying
to get XWindows working. My video card is an ATI Radeon 8500 (QL). I'm 
using XFree86 4.1.99.4 (cvs). With the 2.4.7-10 kernel from Red Hat 7.2, X
will run, but w/o agp/dri/drm support.
   
   Don't bother, the 8500 isn't supported for 3D yet.
  
  I'm not really looking for 3d support. What I'm looking for is agp and drm
  support (dri-devel is listed as the maintainter list for DRM in the linux
  kernel).
 
 I'm afraid no 3D support means no DRM support either.

Ok.

  I'd like to be able to use some of the video tools available for
  linux, all of those tools, however, require Xv support in XFree86. Xv
  support, as far as I can figure, requires DRM support.
 
 It doesn't.
 
 I understand Xv for the 8500 is broken in XFree86 CVS, gatos.sf.net
 apparently has a fix.

Huh. I'd tried using the drivers from the gatos project before, but
without success. Perhaps I followed their instructions incorrectly. Tried
again, and it works. Looking forward to full dri/drm support as well.

Thanks.

--
Noah Romer  |Listen, I'm a politician which means I'm a cheat and
[EMAIL PROTECTED]   |a liar, and when I'm not kissing babies I'm stealing 
PGP key available   |their lollipops.  
by finger or email  |   - Jeffrey Pelt _Hunt for Red October_


___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Radeon 7200

2002-01-07 Thread Robin Forster



I just installed Mandrake 8 with X 4. I am 
having problems with the OpenGL support. X loads fine but when I run 
OpenGL applications they are all screwed up. 

Any help would be appreciated since I am writing an 
Open Source OpenGL application.

Robin FOrster