On Thu, 2006-03-09 at 08:55 -0700, Brian Paul wrote:
> David Reveman wrote:
> > On Thu, 2006-03-09 at 07:34 -0700, Brian Paul wrote:
> >
> >>David Reveman wrote:
> >>
> >>>Biggest problem with using Xgl and compiz on DRI drivers is that I can't
> >>>efficiently update part of the screen. On propri
David Reveman wrote:
On Thu, 2006-03-09 at 07:34 -0700, Brian Paul wrote:
David Reveman wrote:
Biggest problem with using Xgl and compiz on DRI drivers is that I can't
efficiently update part of the screen. On proprietary drivers it's
efficiently done by using DrawBuffer (GL_FRONT) and CopyPi
On Thu, 2006-03-09 at 07:34 -0700, Brian Paul wrote:
> David Reveman wrote:
> > Biggest problem with using Xgl and compiz on DRI drivers is that I can't
> > efficiently update part of the screen. On proprietary drivers it's
> > efficiently done by using DrawBuffer (GL_FRONT) and CopyPixels.
> >
>
Dave Airlie wrote:
efficiently done by using DrawBuffer (GL_FRONT) and CopyPixels.
I've got a first attempt at accelerating copy pixels on r200 using bitblt,
http://www.skynet.ie/~airlied/patches/dri/r200_copy_pixels_bitblt.diff
Same code would be useful in radeon and r300 so I'd like to me
David Reveman wrote:
Biggest problem with using Xgl and compiz on DRI drivers is that I can't
efficiently update part of the screen. On proprietary drivers it's
efficiently done by using DrawBuffer (GL_FRONT) and CopyPixels.
The attached patch for mesa 6.4.2 is just something I created to prove
On Thu, 2006-03-09 at 13:07 +, Keith Whitwell wrote:
> David Reveman wrote:
>
> >>I think the texture rectangle extensions are pretty widely supported. I
> >>take it you can work with either as necessary?
> >
> >
> > Yes, but I have compositing manager features that use mipmapping when
> >
David Reveman wrote:
I think the texture rectangle extensions are pretty widely supported. I
take it you can work with either as necessary?
Yes, but I have compositing manager features that use mipmapping when
possible and that only works with 2D texture targets so I definitely
prefer ARB_tn
On Thu, 2006-03-09 at 12:11 +, Keith Whitwell wrote:
> David Reveman wrote:
> > On Thu, 2006-03-09 at 10:55 +, Keith Whitwell wrote:
> >
> >>David,
> >>
> >>Beyond copypixels/partial swaps, do you have a feel for the remaining
> >>driver requirements for Xgl in the intermediate term?
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=3050
--- Additional Comments From [EMAIL PROTECTED] 2006-03-09 23:36 ---
(In r
David Reveman wrote:
On Thu, 2006-03-09 at 10:55 +, Keith Whitwell wrote:
David,
Beyond copypixels/partial swaps, do you have a feel for the remaining
driver requirements for Xgl in the intermediate term? I know in your
talks you were mentioning things like FBO's and of course GLX_EXT_
efficiently done by using DrawBuffer (GL_FRONT) and CopyPixels.
I've got a first attempt at accelerating copy pixels on r200 using bitblt,
http://www.skynet.ie/~airlied/patches/dri/r200_copy_pixels_bitblt.diff
Same code would be useful in radeon and r300 so I'd like to merge it ..
However I
On Thu, 2006-03-09 at 10:55 +, Keith Whitwell wrote:
> David,
>
> Beyond copypixels/partial swaps, do you have a feel for the remaining
> driver requirements for Xgl in the intermediate term? I know in your
> talks you were mentioning things like FBO's and of course GLX_EXT_tfp,
> which
David,
Beyond copypixels/partial swaps, do you have a feel for the remaining
driver requirements for Xgl in the intermediate term? I know in your
talks you were mentioning things like FBO's and of course GLX_EXT_tfp,
which the drivers don't currently support -- have these requirements
been
Biggest problem with using Xgl and compiz on DRI drivers is that I can't
efficiently update part of the screen. On proprietary drivers it's
efficiently done by using DrawBuffer (GL_FRONT) and CopyPixels.
The attached patch for mesa 6.4.2 is just something I created to prove
that Xgl and compiz run
14 matches
Mail list logo
