I've figured out what was causing the emission of vertexes with humongous
coordinates: the vertex_stride_shift wasn't being updated because all
mach64 vertex formats (*_VERTEX_FORMAT) were defined to 0, so the vertexes
were being overlapped with a step of 1 byte.
I guess that these defines map
José Fonseca wrote:
>
> The previous mail got badly formated. I'm sending again the broken lines.
>
> ...
>
> : /* placeholder for a command */
> 0004: /* VERTEX_1_S */
> 0008: /* VERTEX_1_T */
> 000c: /* VERTEX_1_W */
On 2002.03.03 13:48 Keith Whitwell wrote:
> ...
>
> The advantages of doing it this way:
> - unmapping rather than copying the data is probably faster.
> - no need to reformat data in kernel space.
>
> The disadvantages:
> - you have to re-write '_vbtmp.h' and maybe '_tritmp.h"
Pasi Kärkkäinen wrote:
>
> Hello!
>
> Any plans yet about supporting OpenGL 2 in Mesa (and DRI) ?
No, not yet.
> How much work will it require to have basic OpenGL 2 support in Mesa?
Hard to say before the spec is finished. It'll be some time before
2.0 is finalized and it's not at all clea
On Satterday, 1. März 2002 22:55:48, Thomas Dodd wrote:
> Anyone get these to compile with XFree86-4.2.0 and DRI?
Yes, SPECviewperf worked out of the box, GLperf never tried.
Got SPECviewperf running several times for testing the tdfx driver since
'2000.
I only changed CDEBUGFLAGS in makefile.l
Dieter Nützel wrote:
>
> Yes, SPECviewperf worked out of the box, GLperf never tried.
> Got SPECviewperf running several times for testing the tdfx driver since
> '2000.
>
> I only changed CDEBUGFLAGS in makefile.linux for better Athlon optimization.
>
> CDEBUGFLAGS = -O -mcpu=k6 -pipe -mprefe
On Sonntag, 3. März 2002 18:09:18, Gareth Hughes wrote:
> Dieter Nützel wrote:
> > Yes, SPECviewperf worked out of the box, GLperf never tried.
> > Got SPECviewperf running several times for testing the tdfx driver since
> > '2000.
> >
> > I only changed CDEBUGFLAGS in makefile.linux for better At
On Saturday, 2. März 2002 23:03:06, you wrote:
> On Sun, Mar 03, 2002 at 11:44:44PM +0100, Laurent Pinchart wrote:
> > I'll have a look at that.
> >
> > Which CVS branch should I start with ?
>
> On the glide side you want to use glide3x, but I don't think they ever
> created any branches there. T
On Sonntag, 3. März 2002 18:49:18, Dieter Nützel wrote:
U, wrong subject!!!
It should be "Re: assimilate Glide into tdfx_dri ?"
Sorry!
Dieter
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dr
José Fonseca wrote:
>
> On 2002.03.03 13:48 Keith Whitwell wrote:
> > ...
> >
> > The advantages of doing it this way:
> > - unmapping rather than copying the data is probably faster.
> > - no need to reformat data in kernel space.
> >
> > The disadvantages:
> > - you have to re
Can anyone offer an explanation why my Radeon 7500 will constantly lockup
on Tribes2 after loading the mission data, but an original DDR 64 Meg
Radeon doesn't lockup on the exact same machine with the exact same verion
of X (namely, the main DRI branch)?
I find this kind of peculiar :-)
Adam
Adam K Kirchhoff wrote:
>
> Can anyone offer an explanation why my Radeon 7500 will constantly lockup
> on Tribes2 after loading the mission data, but an original DDR 64 Meg
> Radeon doesn't lockup on the exact same machine with the exact same verion
> of X (namely, the main DRI branch)?
>
I do
On Sun, 3 Mar 2002, Keith Whitwell wrote:
> Adam K Kirchhoff wrote:
> >
> > Can anyone offer an explanation why my Radeon 7500 will constantly lockup
> > on Tribes2 after loading the mission data, but an original DDR 64 Meg
> > Radeon doesn't lockup on the exact same machine with the exact same
Hello!
I have this lockups with quake3arena, too.
I found a temporary (and slow) workaround: disable
the use of OpenGL-extensions in the q3a-setup-menu.
Its strange, as I can remember that some people
reported they were using XFree 4.1.0 with the Radeon7500,
I wonder, didnt they play quake3?
W
So I've done some more playing around with the TCL branch (updated
about an hour ago).
I haven't spent much time on it, but since it seems to relate to
the problems I was experiencing earlier I thought I'd pass this tidbit
along: Where the Radeon 7500 is having the same problems
Me again,
Here's the rundown...
With the main DRI branch, the original Radeon has no problems with
any of the GL apps and games I have. This includes all the xscreensaver
GL apps, the Mesa demos and the following games: tuxracer, gltron, Heretic
2, Heavy Gear 2, Parsec, Rune,
On Sun, Mar 03, 2002 at 10:23:18PM -0500, Adam K Kirchhoff wrote:
>
> Me again,
>
> Here's the rundown...
Could you try the 7500 in 16 bit, does that render for the mesa/demos
games etc you say give you a blank screen?
If it does, I did a patch that used 24BIT_FLOAT_Z depth buffer inst
Michael wrote:
>
> On Sun, Mar 03, 2002 at 10:23:18PM -0500, Adam K Kirchhoff wrote:
> >
> > Me again,
> >
> > Here's the rundown...
>
> Could you try the 7500 in 16 bit, does that render for the mesa/demos
> games etc you say give you a blank screen?
>
> If it does, I did a patch that us
18 matches
Mail list logo
