Hi,
Is there any update on the situation I reported? (Full thread on
http://sourceforge.net/mailarchive/forum.php?thread_id=4872625&forum_id=7177
)
Could someone please answer the questions I posted? :)
Thanks in advance...
(Just a user checking if there's a fix for his problems in the mean time
Ville Syrjälä wrote:
This part of the kernel should be as dumb as possible. I think the best
interface would be simply one accepting almost complete DMA buffers. The
only thing missing from these buffers would be real memory addresses. The
client should just use a surface id (handed out by the m
--- Patrick McFarland <[EMAIL PROTECTED]> wrote:
> On 05-Jun-2004, Ville Syrj?l? wrote:
> > On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel D?nzer wrote:
> > > I'm not sure about that; pseudo-command buffers that the DRM parses
> and
> > > generates the actual DMA buffers from on the fly might be
--- Patrick McFarland <[EMAIL PROTECTED]> wrote:
> On 05-Jun-2004, Michel D?nzer wrote:
> > On Sat, 2004-06-05 at 12:21 +0300, Ville Syrj??l?? wrote:
> > > The client should just use a surface id (handed out by the memory
> allocator)
> > > instead of a real address. The kernel would then check
On 05-Jun-2004, Ville Syrj?l? wrote:
> On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel D?nzer wrote:
> > I'm not sure about that; pseudo-command buffers that the DRM parses and
> > generates the actual DMA buffers from on the fly might be better for
> > security and/or performance reasons.
>
> Qu
On 05-Jun-2004, Michel D?nzer wrote:
> On Sat, 2004-06-05 at 12:21 +0300, Ville Syrj??l?? wrote:
> > This part of the kernel should be as dumb as possible. I think the best
> > interface would be simply one accepting almost complete DMA buffers. The
> > only thing missing from these buffers would
On Sat, 2004-06-05 at 14:09 +0300, Ville SyrjÃlà wrote:
> On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel DÃnzer wrote:
> > On Sat, 2004-06-05 at 12:21 +0300, Ville SyrjÃlà wrote:
> > > On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
> > > >
> > > > expose 2D and 3D hardware ac
On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel Dänzer wrote:
> On Sat, 2004-06-05 at 12:21 +0300, Ville Syrjälä wrote:
> > On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
> > >
> > > expose 2D and 3D hardware acceleration
> > > functions, allow applications (DirectFB, xservers
On Sat, 2004-06-05 at 12:21 +0300, Ville SyrjÃlà wrote:
> On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
> >
> > expose 2D and 3D hardware acceleration
> > functions, allow applications (DirectFB, xservers) to query the
> > available acceleration methods,
>
> I disagree.
>
>
On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
>
> Which brings me to mention something else: I fully believe that the
> kernel should be completely managing all aspects of memory and state
> management of both 2D and 3D hardware. The kernel's portion of DRI
> should be providi
On 04-Jun-2004, Mike Mestnik wrote:
> Right, but thay must not EVER step on each other. From the time one
> uploades a texture and then later unloads it, that space can't be used.
> After an unload the memory can be maped back to system use.
>
> I think the kernel's memory subsystem should be th
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
> > --- Ian Romanick <[EMAIL PROTECTED]> wrote:
> >>Michel Dänzer wrote:
> >>
> >>>It could waste a lot of RAM.
> >>
> >>Yup. This is one of the bad parts of the AGP implementation on Linux.
>
> >>Once the AGP aperture is setup,
Ian Romanick wrote:
Manuel Bilderbeek wrote:
(II) RADEON(0): [agp] GART texture map handle = 0xe0302000
(II) RADEON(0): Using 5 MB for GART textures
(II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5
The card has 32MB RAM and I'm usually running at 1600x1200x24 is
this reasonabl
Roland Scheidegger wrote:
Ian Romanick wrote:
implications. What if one process removes the backing from a region
of the AGP aperture a the same instant another process tries to
texture from that range? Random memory reads? System crash? Dunno...
This just can't heppen, no sharing of AGP spa
Ian Romanick wrote:
implications. What if one process removes the backing from a region
of the AGP aperture a the same instant another process tries to
texture from that range? Random memory reads? System crash? Dunno...
This just can't heppen, no sharing of AGP space, right?
Video memory a
Mike Mestnik wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Michel Dänzer wrote:
It could waste a lot of RAM.
Yup. This is one of the bad parts of the AGP implementation on Linux.
Once the AGP aperture is setup, it always has non-swappable memory
backing it. If you set a 256MB aperture, it
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Michel Dänzer wrote:
> >>Couldn't it just use the largest GART size possible (set by the bios),
> >>or would this have some negative consequences?
I think the Idea Here is to fallback after a failed bind!!! I.E. AGPSize
== 124MB where only a 64MB la
Michel DÃnzer wrote:
It doesn't seem to change the reported maximum texture sizes though for
the r200 at least (could be different on radeon I guess), does it
actually support using agp memory for texturing? Some environment
variable suggests that so though.
In contrast to radeon, r200 only uses th
Felix Kühling wrote:
It could waste a lot of RAM.
But is this a problem? It surely eats away some of the 3GB user address
space I believe (afaik the low-mem kernel address space agpgart takes is
gone anyway), but unless the driver is really stupid and just fills it
up even if it doesn't need to t
On Fri, 04 Jun 2004 16:48:09 +0200
Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Michel Dänzer wrote:
> >> A simpler option would be to axe support for AGPSize...
> >
> >
> > I don't think we should break working configurations as long as we
> > can support them so easily.
> Ok.
>
> >> Couldn
On Fri, 2004-06-04 at 16:48 +0200, Roland Scheidegger wrote:
> Michel DÃnzer wrote:
>
> >> Couldn't it just use the largest GART size possible (set by the
> >> bios), or would this have some negative consequences?
> >
> >
> > It could waste a lot of RAM.
> But is this a problem? It surely eats a
Michel DÃnzer wrote:
A simpler option would be to axe support for AGPSize...
I don't think we should break working configurations as long as we
can support them so easily.
Ok.
Couldn't it just use the largest GART size possible (set by the
bios), or would this have some negative consequences?
It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 04 June 2004 12:22, Michel DÃnzer wrote:
> > Currently, if you set the gart size manually higher than what's possible
> > (set in bios), dri will just get disabled due to missing agp support,
> > which I consider bad behaviour, and that you
On Fri, 2004-06-04 at 04:16 +0200, Roland Scheidegger wrote:
> Ian Romanick wrote:
> > Manuel Bilderbeek wrote:
> >
> > Option "GARTSize" "64M"
> >
> This doesn't work for me, the driver ignores all values supplied to that
> parameter (dri tree). It accepts though values supplied to the old,
> de
Ian Romanick wrote:
Manuel Bilderbeek wrote:
(II) RADEON(0): [agp] GART texture map handle = 0xe0302000 (II)
RADEON(0): Using 5 MB for GART textures (II) RADEON(0): Will use
2752 kb for textures at offset 0x1d5
The card has 32MB RAM and I'm usually running at 1600x1200x24
is this reasonable
Manuel Bilderbeek wrote:
(II) RADEON(0): [agp] GART texture map handle = 0xe0302000
(II) RADEON(0): Using 5 MB for GART textures
(II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5
The card has 32MB RAM and I'm usually running at 1600x1200x24 is
this reasonable?
It seems the Rade
Roland Scheidegger wrote:
I have been using the latest Debian packages from Michel Daenzer
since a few years and that solved most problems with GL apps.
However, there are still a few left: - in the XScreensaver hack
"AntSpotlight", I don't get to see the desktop... Only the ant
walking on a black
Manuel Bilderbeek wrote:
Hello all,
I have been using the latest Debian packages from Michel Daenzer
since a few years and that solved most problems with GL apps.
However, there are still a few left: - in the XScreensaver hack
"AntSpotlight", I don't get to see the desktop... Only the ant
walking o
Hello all,
I have been using the latest Debian packages from Michel Daenzer since a
few years and that solved most problems with GL apps. However, there are
still a few left:
- in the XScreensaver hack "AntSpotlight", I don't get to see the
desktop... Only the ant walking on a black surface... A
29 matches
Mail list logo
