On Sat, 2001-09-29 at 18:41, Steven P. Lilly wrote:
> I just installed Slackware 8 with XFree86 4.1.0 and I've come across some
> weirdness with glxgears. When I'm running a window manager everything is
> fine but when I don't run a window manager I get a much higher frame rate
> but what I see is
Does current i810 drm accelerate 2D path?
I get about 6mln pps in drawpix :(
Michael
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Sun, 30 Sep 2001 07:50, Regard Inbox wrote:
> Does current i810 drm accelerate 2D path?
>
No.
Keith
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Dri-devel
- Original Message -
From: Keith Whitwell <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; Regard Inbox <[EMAIL PROTECTED]>
Sent: Sunday, September 30, 2001 3:59 PM
Subject: Re: [Dri-devel] glDrawPixels on i810
> On Sun, 30 Sep 2001 07:50, Regard Inbox wrote:
> > Does current i810 drm acce
On Sun, 30 Sep 2001 09:06, you wrote:
> - Original Message -
> From: Keith Whitwell <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; Regard Inbox <[EMAIL PROTECTED]>
> Sent: Sunday, September 30, 2001 3:59 PM
> Subject: Re: [Dri-devel] glDrawPixels on i810
>
> > On Sun, 30 Sep 2001 07:50, Re
so what approach should be faster: just Xlib or DrawPixels + DRI?
- Original Message -
From: Keith Whitwell <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 30, 2001 4:22 PM
Subject: Re: [Dri-devel] glDrawPixels on i810
> On Sun, 30 Sep 2001 09:06, you wrote:
> > -
> The DMA buffers and the frame buffer are in
> a
> > unified memory pool, so it isn't any quicker to put the data into DMA
and
> > then have hardware upload it. Very little consumer hardware provides
> support
> > for the operations necessary to implement much of drawpixels anyway.
what about
Michael Zayats wrote:
>
> what about glPixelsZoom? I would have been very pleased to see it hardware
> accelerated...
>
when the pixmap wont change i would load it as a texture
and draw it as a quad.
if its changing use gltexsubimage to update it. i dont think its a
special path
for the 810 dr
>> Keith Whitwell <[EMAIL PROTECTED]> writes:
> Very little consumer hardware provides support for the operations
> necessary to implement much of drawpixels anyway.
Could you please elaborate on this? As someone who has suffered
because of poor glDrawPixels and glReadPixels performance in
On Sun, Sep 30, 2001 at 10:09:47PM +0200, Marcelo E. Magallon wrote:
| Is it really a pure hardware problem? Rumors on comp.graphics.opengl
| are that the vendors don't invest time optimizing that path (in the
| driver) because there's not much demand for it. ...
Most consumer-level hardware
On Sun, Sep 30, 2001 at 10:09:47PM +0200, Marcelo E. Magallon wrote:
> >> Keith Whitwell <[EMAIL PROTECTED]> writes:
>
> > Very little consumer hardware provides support for the operations
> > necessary to implement much of drawpixels anyway.
>
> Could you please elaborate on this? As someon
On Thu, 2001-09-20 at 22:52, Michel Daenzer wrote:
> Log message:
> flush indirect buffer in the BlockHandler
>
> Modified files:
> xc/xc/programs/Xserver/hw/xfree86/drivers/ati/:
> r128_driver.c
I just noticed that the radeon driver doesn't do this yet - does it work
well with
>> Allen Akin <[EMAIL PROTECTED]> writes:
> Most consumer-level hardware doesn't support the esoteric functions
> in the pixel path, but there's no hardware reason for the most common
> case (data format matches the window pixel format; no scale/bias,
> convolutions, scaling, etc.) to be slow
13 matches
Mail list logo
