Dave Airlie wrote:
A better scheme for a movie player would be to create a single texture
and then keep replacing it's contents. Or use two textures and double
buffer. But once created these textures would not move in the LRU list
unless you started something like a game in another window.
if we s
On Sat, 2005-02-05 at 01:31 +0100, Felix KÃhling wrote:
> Aha, you have a SuperSavage. Unfortunately it seems like vertex DMA
> locks up these cards. Other SuperSavage users reported the same. I don't
> know why and I can't debug the problem because I don't have a
> SuperSavage to test (and neither
On Sat, 2005-01-29 at 11:57 +0100, Martin Bouzek wrote:
> Hello,
>
> I am complete newbie to this mailing list and to programming of modern
> graphic HW, but have the following problem: I want to grab complete X
> window screen (eg. root window) reasonably fast. When I use standard way
> by XGetIm
On Fri, 2004-12-31 at 10:45 -0500, Jon Smirl wrote:
> [...] Some kind of
> fbdev/drm merge is a requirement of getting X on GL working.
[ straying off-topic for this list... ]
I would argue that this isn't necessarily true. As soon as you can get
dri
drivers running within the X server, it woul
On Mon, 2004-11-08 at 11:32 -0800, Ian Romanick wrote:
> Owen Taylor wrote:
> > Over a last few days, I've been working on a tool to allow watching
> > a live view of the texture usage of a DRI application. I'm not going to
> > go into a lot of detail here - there is
On Mon, 2004-11-08 at 02:43 +, Dave Airlie wrote:
> > > I've just patched this into the radeon driver (and texmem.c)
> > > http://freedesktop.org/~airlied/patches/dri/radeon_texturetop.patch
>
> Okay the patch above should now work on the radeon driver, I had forgotten
> a call to update the t
On Sat, 2004-11-06 at 18:11 +, Keith Whitwell wrote:
> > My questions would be:
> >
> > - Is this interesting to anybody but me? It's been quite useful to me
> >so far in just the couple of hours I've had it working...
>
> It's definitely interesting. Have you been using it to tune an
Over a last few days, I've been working on a tool to allow watching
a live view of the texture usage of a DRI application. I'm not going to
go into a lot of detail here - there is a more complete description at:
http://fishsoup.net/software/texturetop/
And an even more complete README files lin
It's a little suprising to me that removing some (fairly unimportant)
accelerations makes 2D "painfully slow"; except for a few things
like blits and solid area fills, acceleration just doesn't matter
much any more. What applications were you testing with?
I've seen DRI slow 2D down to a "crawl"
