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
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00D4_51B23D7B.C8313E56"
Set mem=nopentium in your boottime kernel options, this will make
the AMD761 Radeon lockups go away. Sorry if this has been mentioned
already...
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardwa
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 b
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 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:
>
>
> S
On Tuesday 14 May 2002 05:05 pm, Ian Molton wrote:
> Hi
>
> I am looking for information resembling
>
> http://dri.sourceforge.net/other/radeon_dri_features.html
>
> For ofther cards in the dri project.
>
> please can people direct me to where this information can be found?
Liam (Smitty <[EMAIL P
Hi
I am looking for information resembling
http://dri.sourceforge.net/other/radeon_dri_features.html
For ofther cards in the dri project.
please can people direct me to where this information can be found?
___
Have big pipes? Source
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.
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
done
Rick,
On 2002.05.14 22:21 Rick Knight wrote:
> About 3 months ago I wrote to the dri-users list after getting DRI
> working with my Mach64 equiped notebook PC. The only reply I received
> was smart#@! remark. Below is the text of the message, now that I know
> where to ask, maybe I can get an
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
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 dow
About 3 months ago I wrote to the dri-users list after getting DRI
working with my Mach64 equiped notebook PC. The only reply I received
was smart#@! remark. Below is the text of the message, now that I know
where to ask, maybe I can get an answer...
I've just built the DRI-Mach64 driver with
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.
> >
> > Should apply against xf_4_2-branch.
>
> Ugh,
>
> Mich
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 w
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? W
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, drawab
> 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
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 Direct
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 or
21 matches
Mail list logo
