On Sun, 2001-10-07 at 17:43, Michael Zayats wrote:
> > On Fri, 2001-10-05 at 00:08, Nathan Hand wrote:
> >
> > > XV is completely independent of V4L and the DRI.
> >
> > This is true conceptually and was true implementation-wise until
> > recently. However, the r128 driver uses the DRM to transfer
- Original Message -
From: Michel Dänzer <[EMAIL PROTECTED]>
To: Nathan Hand <[EMAIL PROTECTED]>
Cc: Michael Zayats <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, October 05, 2001 2:14 AM
Subject: Re: [Dri-devel] glDrawPixels on i810
> On Fri, 2001-
- Original Message -
From: Michel Dänzer <[EMAIL PROTECTED]>
To: Nathan Hand <[EMAIL PROTECTED]>
Cc: Michael Zayats <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, October 05, 2001 2:14 AM
Subject: Re: [Dri-devel] glDrawPixels on i810
> On Fri, 2001-
In our case, it isn't necessarily on the i810. We don't really care what accellerator
is used as long as it works well for textures and stenciling. Depth buffering is a
bonus, but not necessary for the majority of things that we do. Dest alpha, on the
other hand IS.
Right now we're evaluating u
Around 13 o'clock on Oct 5, "Roberto Peon" wrote:
> The application (for the company) is:
> Real time video into (main memory) RGBA surface from SDI based video card
> Blit from that surface to FB in accellerator.
> Render with dest alpha in the accellerator.
> blit from the FB surface to the SD
Maybe I'm just paranoid, but why so much on the i810? This chipset is
slower than Mach64, and people never got it in the intention of doing
games, or other intense graphics.
Roberto Peon wrote:
>I'd be happy to get to work making grabbing facilities, etc (for mga, which seems to
>be the most
I'd be happy to get to work making grabbing facilities, etc (for mga, which seems to
be the most stable accellerator) but for lack of experience and not much of a place to
start..
On the other hand, I'm getting paid to do it (part of my job), so chances are I'll
complete it.
Any pointers woul
On Fri, 2001-10-05 at 00:08, Nathan Hand wrote:
> XV is completely independent of V4L and the DRI.
This is true conceptually and was true implementation-wise until
recently. However, the r128 driver uses the DRM to transfer the XvImage
data now when possible, and Peter Surda has been bug^Wasking
On Wed, Oct 03, 2001 at 10:47:08AM +0200, Michael Zayats wrote:
> I will present my problem in it's full, may be you will help me:
>
> I am grabbing frames from bt848 and should both store them for future reuse
> and get them on the screen. The box is i810 based and has many other tasks
> to do.
I will present my problem in it's full, may be you will help me:
I am grabbing frames from bt848 and should both store them for future reuse
and get them on the screen. The box is i810 based and has many other tasks
to do.
putting video on a screen should be fast and very low CPU consuming.
what
>> 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
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 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
>> 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
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
> 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
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 0
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 i81
- 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:
>
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
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
21 matches
Mail list logo
