José Fonseca wrote:
> While I was debugging a new vertex buffer template for Mach64 I've
> discovered that this piece of code doesn't work:
>
> INTERP_F( t, (*dst++).f, (*out++).f * qout, (*in++).f * qin );
> INTERP_F( t, (*dst++).f, (*out++).f * qout, (*in++).f * qin );
>
> The problem is tha
>
> The DRI User Guide (on the website) has some information about what's
> done in hardware vs. software for most drivers, but it's not deeply
> detailed.
>
> If you need high-performance GL_LINE or GL_POINT-mode polygons, you're
> often better-off writing your own rendering loop using glBegin
José Fonseca wrote:
> Preliminary support Mach64 native vertex buffer template was added to
> CVS. The measures on the increase of performance in doing this are
> rather marginal unfortunately: I got an increase of 800 poly/sec (over
> 35400) on ipers mesademo on the previous mach64-0-0-4-branch,
José Fonseca wrote:
> Preliminary support Mach64 native vertex buffer template was added to
> CVS. The measures on the increase of performance in doing this are
> rather marginal unfortunately: I got an increase of 800 poly/sec (over
> 35400) on ipers mesademo on the previous mach64-0-0-4-branch,
Title: Updated dri-devel
Günlük update edilen en genis video arsivi
Bu sayfalari gezmeden porno gördük demeyin. Kaliteli, seri
video arsivi
Günlük Videolar
On Mon, 1 Jul 2002, José Fonseca wrote:
> On Sun, Jun 30, 2002 at 08:01:58PM -0400, Leif Delgass wrote:
> >This is just temporary transitional code, right? Isn't the idea to add
>
> I hope not...
>
> >the commands in the drm when copying to a private buffer? That way we
>
> .. as I hope be a
On Sun, Jun 30, 2002 at 08:01:58PM -0400, Leif Delgass wrote:
>This is just temporary transitional code, right? Isn't the idea to add
I hope not...
>the commands in the drm when copying to a private buffer? That way we
.. as I hope be able to use this code in the DRM.
>don't need to verify t
Is the Radeon 8500 supported yet?
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourcefor
This is just temporary transitional code, right? Isn't the idea to add
the commands in the drm when copying to a private buffer? That way we
don't need to verify the commands and the Mesa driver can just copy the
vertex data unchanged into the buffer (or have Mesa use DMA buffers
directly).
On
On Sun, 2002-06-30 at 23:56, José Fonseca wrote:
>
> This is still disabled by default since some things are still missing.
> One of them is support for bigendian architectures, and therefore a
> doubt that I came about: is it necessary to swap bytes when writting a
> IEEE fp number on a bigendia
Preliminary support Mach64 native vertex buffer template was added to
CVS. The measures on the increase of performance in doing this are
rather marginal unfortunately: I got an increase of 800 poly/sec (over
35400) on ipers mesademo on the previous mach64-0-0-4-branch, but on the
new branch the r
Keith Whitwell wrote:
> Tim Smith wrote:
>
>> I found a few other ways of provoking the problem while I was at it,
>> and dragging an xclock window over the 3D view did it too (with a
>> window manager and "solidmove" turned on). In fact, I also managed to
>> provoke the lockup by persistently
Tim Smith wrote:
> I found a few other ways of provoking the problem while I was at it, and
> dragging an xclock window over the 3D view did it too (with a window
> manager and "solidmove" turned on). In fact, I also managed to provoke the
> lockup by persistently dragging xclock around over a
While I was debugging a new vertex buffer template for Mach64 I've
discovered that this piece of code doesn't work:
INTERP_F( t, (*dst++).f, (*out++).f * qout, (*in++).f * qin );
INTERP_F( t, (*dst++).f, (*out++).f * qout, (*in++).f * qin );
The problem is that INTERP_F is defined in src/mma
On Sun, 30 Jun 2002, Alan Hourihane wrote:
> On Sun, Jun 30, 2002 at 12:39:30 +0200, Felix Kühling wrote:
> > Hi mach64 folks,
> >
> > after several weeks of extreme busyness/absence I am back now and
> > testing the mach64-0-0-4 and 0-0-5 branches again (still the best I can
> > do :( ). It's g
On Sun, Jun 30, 2002 at 12:39:30 +0200, Felix Kühling wrote:
> Hi mach64 folks,
>
> after several weeks of extreme busyness/absence I am back now and
> testing the mach64-0-0-4 and 0-0-5 branches again (still the best I can
> do :( ). It's great that you got 2D accel working. However, there is
>
Hi mach64 folks,
after several weeks of extreme busyness/absence I am back now and
testing the mach64-0-0-4 and 0-0-5 branches again (still the best I can
do :( ). It's great that you got 2D accel working. However, there is
still one problem.
Moving a GL window caused the X-server to segfault wi
17 matches
Mail list logo
