I've commited the last major chunk of the Mesa 4 merge, mainly in
mach64_tris.c. The branch should now compile and run, but it needs
debugging, as glxgears is still segfaulting.
glxinfo reports:
display: :0.0 screen:0
direct rendering: Yes
server glx vendor string: SGI
server glx version str
Leif,
I just finished _vb.c. It compiles with just a warning of a missing
defintion. Do you prefer I commit or do you want to take a look first?
Are you still working on this? Have you some spare minutes for IRC?
Regards,
José Fonseca
On 2002.02.28 23:38 Leif Delgass wrote:
> On Thu, 28 Feb
On Thu, 28 Feb 2002, José Fonseca wrote:
> Leif,
>
> I've finished the work on the the mach64_* files except for the
> *_{tris,vb} ones. I've also included the remaining of your changes.
>
> There still are several things that I'm not sure, but I'll leave those
> issues to the moment that we
Leif,
I've finished the work on the the mach64_* files except for the
*_{tris,vb} ones. I've also included the remaining of your changes.
There still are several things that I'm not sure, but I'll leave those
issues to the moment that we are able to link the driver. At that time it
will be ne
Oops, brain fart. I meant to say this:
I think the deal might be that their drivers are optimized for
professional applications, like CAD, and whatever else the SPECViewPerf
benchmark measures, not games. That would explain a lot of things:
non-standard fullscreen interface, the cost, the fac
Lance Stringham wrote:
> Adam K Kirchhoff wrote:
>
>> On Thu, 28 Feb 2002, Lance Stringham wrote:
>>
>>
>>> Adam K Kirchhoff wrote:
>>>
On Thu, 28 Feb 2002, Laurent Pinchart wrote:
> Hi,
>
> I recently found out that Xi Graphics (http://www.xig.com), a
> comp
Adam K Kirchhoff wrote:
> On Thu, 28 Feb 2002, Lance Stringham wrote:
>
>
>>Adam K Kirchhoff wrote:
>>
>>>On Thu, 28 Feb 2002, Laurent Pinchart wrote:
>>>
>>>
>>>
Hi,
I recently found out that Xi Graphics (http://www.xig.com), a company
that provides accelerated 3D drivers for
Adam K Kirchhoff wrote:
> On Thu, 28 Feb 2002, Laurent Pinchart wrote:
>
>
>>Hi,
>>
>>I recently found out that Xi Graphics (http://www.xig.com), a company
>>that provides accelerated 3D drivers for UNIX systems (including Linux),
>> claimed that their drivers performances are much better tha
On Thu, 28 Feb 2002, Laurent Pinchart wrote:
> Hi,
>
> I recently found out that Xi Graphics (http://www.xig.com), a company
> that provides accelerated 3D drivers for UNIX systems (including Linux),
> claimed that their drivers performances are much better than the DRI
> drivers for most
Hi,
I recently found out that Xi Graphics (http://www.xig.com), a company
that provides accelerated 3D drivers for UNIX systems (including Linux),
claimed that their drivers performances are much better than the DRI
drivers for most graphic chips.
Has any of you heard about them, and has be
On Thu, 28 Feb 2002, José Fonseca wrote:
> On 2002.02.28 10:56 Leif Delgass wrote:
> > Jose,
> >
> > I've been hacking on the tex/texmem/texstate stuff. I just did an update
> > and it looks like you've done much of the same thing, so I'm sending a
> > diff for you to compare to your changes.
On 2002.02.28 10:56 Leif Delgass wrote:
> Jose,
>
> I've been hacking on the tex/texmem/texstate stuff. I just did an update
> and it looks like you've done much of the same thing, so I'm sending a
> diff for you to compare to your changes. I'm going to download your
> changes and have a look b
Jose,
I've been hacking on the tex/texmem/texstate stuff. I just did an update
and it looks like you've done much of the same thing, so I'm sending a
diff for you to compare to your changes. I'm going to download your
changes and have a look before I continue.
I think the next big chunk is t
On r128_tex.c the 't' debug output statement on r128AllocTexObj shouldn't
be there and has no meaning.
static r128TexObjPtr r128AllocTexObj( struct gl_texture_object *texObj )
{
r128TexObjPtr t;
if ( R128_DEBUG & DEBUG_VERBOSE_API ) {
fprintf( stderr, __FUNCTION__"( %p, %p )\n",
Hi Anybody,
Hope you can help me.
I am getting the following (permanent) error on logging out
from KDE :
[drm]radeon_cp_indirect - process using buffer owned by 0
is the PID of the X server and the "owned by" is always 0.
The effect is that the top
15 matches
Mail list logo
