To all those that are using or attempted to use the mach64 snapshots and
posted on the *dri-users* list,
As I was browsing the dri-users lists I just recentely noticed several
posts regarding the Mach64 branch and its snapshots. Almost all went
unanswered. The reason for that is that neither I
hi,
I have a laptop with the sis 630 chipset and i have the latest X driver
for the sis chipset, xfree86 4.2.0.(redhat 7.3)
Question:
glxinfo output direct rendering =true
and a lot of other stuff
when i load up say chromium or glxgears the latop lock up, when i use an
older version that
in the /usr/X11R6/lib/modules/dri/
there is an file called sis_dri.so.
Its the OpenGL hardware accelleration module for some SIS chipset.
It plugs into the DRI concept when an application does use OpenGL.
Do i have to up date this or what ?
It should have the same version as the rest of
Keith Whitwell wrote:
You also have to cope with the case where clients are killed rather than exit
cleanly, although I guess it doesn't matter too much as the behaviour in that
case will just be suboptimal.
Is this something the Server should clean up? We do that for 3D
contexts,
Jens Owen wrote:
Keith Whitwell wrote:
You also have to cope with the case where clients are killed rather than exit
cleanly, although I guess it doesn't matter too much as the behaviour in that
case will just be suboptimal.
Is this something the Server should clean up? We do that
On Tuesday 14 May 2002 00:25, Michel wrote:
I've left in a hack to allow export TDFX_DEBUG_TEXTURE=something to
make it easy to switch on/off texture debugging.
Should apply against xf_4_2-branch.
Ugh,
Michel you are working with a somewhat outdated codebase.
May I force you to work with
Hi.
It has come to my attention that the DRI website is, well, lacking.
I'd like to offer my services in bringing it up to a nicer standard.
Who should I be working with on this?
___
Have big pipes? SourceForge.net is looking for
Ian Molton wrote:
Hi.
It has come to my attention that the DRI website is, well, lacking.
I'd like to offer my services in bringing it up to a nicer standard.
Who should I be working with on this?
Frank Worsley has done an excellent job with our site...you should have
seen it before
I've been making some tests to the bus mastering in Mach64 chip as I told
yesterday on IRC. Since this was discussed pretty late I would like to
briefly document to the others DRI developers what I'm trying to do:
Since there is no way of caching DMA buffers on the Mach64 chip (is is
On Tue, May 14, 2002 at 03:18:19PM +0100, Michael wrote:
On Tue, May 14, 2002 at 04:02:20PM +0200, Dieter Nützel wrote:
On Tuesday 14 May 2002 00:25, Michel wrote:
I've left in a hack to allow export TDFX_DEBUG_TEXTURE=something to
make it easy to switch on/off texture debugging.
On Wed, May 15, 2002 at 12:33:46AM +0100, José Fonseca wrote:
I've been making some tests to the bus mastering in Mach64 chip as I told
yesterday on IRC. Since this was discussed pretty late I would like to
briefly document to the others DRI developers what I'm trying to do:
Since
Actually, Greg's problem appears to be the AGP FW problem with AMD761 rather
than current DRI+7500 problem.
The DRI+7500 problem happens on all AGP chipsets and usually causes lockup
when running some 3D games (like Q3A) but not at the beginning of X server.
It appears okey to run all Mesa demos.
On Tue, May 14, 2002 at 11:44:34PM -0700, hy0 wrote:
Actually, Greg's problem appears to be the AGP FW problem with AMD761 rather
than current DRI+7500 problem.
The DRI+7500 problem happens on all AGP chipsets and usually causes lockup
when running some 3D games (like Q3A) but not at the
Warning
Unable to process data:
multipart/mixed;boundary==_NextPart_000_00D4_51B23D7B.C8313E56
Hi Jens, Ian and all ...
I don't really care what anybody wants to do with the site. I don't have
time (or much interest to be honest) to do anything more with it, other
than to maintain it.
So, if Ian wants to overhaul the whole thing, then he should go nuts.
I've received emails from several
15 matches
Mail list logo
