On Mon, 2003-03-17 at 21:29, Bhavana Nagendra wrote:
> > On Fre, 2003-03-14 at 17:42, Bhavana Nagendra wrote:
>
> > > Since the driver opens /dev/dri/card0 as it boots up,
> > > I'd like to know how exactly does it use the DRIVER_MAJOR,
> > > DRIVER_MINOR macros? Are these macros required?
>
Michel D?nzer <[EMAIL PROTECTED]> wrote:
> BTW, are you actually using 4x transfer rate? If so, have you tried
> lowering it?
I't like to note that the lockups I saw with FlightGear and Solace were
completely independent from the AGP transfer rate of my Radeon7500. I did
quite a few tests to be s
Qgxxbqrauxrdfoklpptxytakicwkdmwymwmhrrdqtdhfjhexyxg
DON'T MISS
THE LOWEST MORTGAGE RATES IN HISTORY!
Mortgage
refinance rates may be as low as 4.95%!
Poor credit not a problem! Act now before they go up!
For the best
mortgage rates on Planet Earth.
Excellent, Poor, or Fa
Title: Will holiday purchases put you over your LIMIT?
if
you feel you have received this email in error or you no longer wish to
receive this email from us please follow th
On Die, 2003-03-18 at 00:26, Magnus Vage wrote:
> When enabling DRI in my XF86Config-4, All OpenGL applications are
> completely black.
This is a known problem which has been reported to the Debian BTS (too)
many times already. Try the packages from
http://penguinppc.org/~daniels/README or
http://
When enabling DRI in my XF86Config-4, All OpenGL
applications are completely black.
When disabling it, software rendering works just
fine.
The machine is a laptop, Compaq
2812EA.
With this config, the LCD screen _and_ the VGA
output are active, and S-VHS isn't. Don't know why.
I will att
On Mon, 2003-03-17 at 20:39, Charl P. Botha wrote:
> On Mon, Mar 17, 2003 at 08:34:44PM +0100, Jacek Pop?awski wrote:
> > blender: r200_vtxfmt.c:1083: r200VtxfmtUnbindContext: Assertion `vb.context ==
> > ctx' failed.
>
> This is fixed in current DRI CVS. In XFree86 4.3 you can work around it by
> >
> > Thanks for your reply. I'm using the DRM templates.
> > These are the values I have, I must have got them from an
> > example.
> > DRIVER_MAJOR 1
> > DRIVER_MINOR 0
> > DRIVER_PATCHLEVEL 0
> >
> > How do I find out what's the major, minor and patch level for
> > the DRM I'm using? Th
> On Fre, 2003-03-14 at 17:42, Bhavana Nagendra wrote:
> > I have a DRI based DRM driver and wanted to know if it needs a
> > major device number assigned by the linux community, like any
> > standalone driver.
>
> >From linux/Documentation/devices.txt:
>
> 226 charDirect Rendering
Hello,
just discovered that the fallback in radeon_Materialfv()
in radeon_vtxfmt.c seems to do not work.
I disabled the fallback by just printing the function
glMaterialfv() to stderr
(so I know I'm now running the modified radeon_dri.so)
and the result is the same as before, not better, not worse.
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
4:00PM EST or 1:00PST, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous IRC m
On Mon, Mar 17, 2003 at 08:34:44PM +0100, Jacek Pop?awski wrote:
> blender: r200_vtxfmt.c:1083: r200VtxfmtUnbindContext: Assertion `vb.context ==
> ctx' failed.
This is fixed in current DRI CVS. In XFree86 4.3 you can work around it by
setting the environment variable RADEON_NO_VTXFMT before runn
I don't know if this is helpful, but at least I can report it:
blender: r200_vtxfmt.c:1083: r200VtxfmtUnbindContext: Assertion `vb.context ==
ctx' failed.
PS. XFree86-4.3.0rc2, Radeon 9000, Linux
--
Free Software - find interesting programs and change them
NetHack - meet interesting creatures,
On Mon, 2003-03-17 at 08:13, Michel Dänzer wrote:
> BTW, are you actually using 4x transfer rate? If so, have you tried
> lowering it?
>
Yes, I am using 4x AGP
> > One thing I have to add is that the system does not lock up. I can ssh
> > in. The Xserver cannot be killed, however; even kill
Martin Spott wrote:
Michel D?nzer <[EMAIL PROTECTED]> wrote:
You could try to set the environment variables RADEON_NO_CODEGEN,
RADEON_NO_VTXFMT and RADEON_TCL_FORCE_DISABLE [...]
BTW, I just aquired a Radeon9100 clone to see if serveral 'features'
r
Michel D?nzer <[EMAIL PROTECTED]> wrote:
> You could try to set the environment variables RADEON_NO_CODEGEN,
> RADEON_NO_VTXFMT and RADEON_TCL_FORCE_DISABLE [...]
BTW, I just aquired a Radeon9100 clone to see if serveral 'features'
resemble the behav
On Mon, Mar 17, 2003 at 02:41:43PM +0100, Michel Dänzer wrote:
> On Mon, 2003-03-17 at 14:11, Martin Spott wrote:
> > Michel D?nzer <[EMAIL PROTECTED]> wrote:
> > Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45
> >
> > Log message:
> > Fix recycle lockup (Michel Danzer)
> >
> > Modified
On Mon, 2003-03-17 at 14:11, Martin Spott wrote:
> Michel D?nzer <[EMAIL PROTECTED]> wrote:
>
> > The texmem branch doesn't have the FlushVertices fix yet, which seems to
> > help with a number of lockups. Try
> > http://penguinppc.org/~daenzer/DRI/applied/r200-radeon-flushvertices.diff
>
> If it
Michel Dänzer wrote:
On Mon, 2003-03-17 at 06:15, Jonathan Thambidurai wrote:
On Sun, 2003-03-16 at 19:59, Michel Dänzer wrote:
On Mon, 2003-03-17 at 01:36, Jonathan Thambidurai wrote:
When playing Serious Sam: The Second Encounter, the game (and maybe the
system, or just the input) lock
Michel D?nzer <[EMAIL PROTECTED]> wrote:
> The texmem branch doesn't have the FlushVertices fix yet, which seems to
> help with a number of lockups. Try
> http://penguinppc.org/~daenzer/DRI/applied/r200-radeon-flushvertices.diff
If it does not work, try this one - I never experienced any Radeon-l
On Mon, 2003-03-17 at 06:15, Jonathan Thambidurai wrote:
> On Sun, 2003-03-16 at 19:59, Michel Dänzer wrote:
> > On Mon, 2003-03-17 at 01:36, Jonathan Thambidurai wrote:
> > > When playing Serious Sam: The Second Encounter, the game (and maybe the
> > > system, or just the input) locks up after s
TURKIYE'DE BIR
ILK !
SADECE
25.000.000 TL
HACKER ve GUVENLIK REHBERI
CD'SI
Hack ve Guvenlik
konusunda bilmek istediginiz hersey, ihtiyaciniz olan her program bu
cd'de. Sadece 25.00
Dieter Nützel wrote:
But maybe you should stop the CPU scanning on AMD after 3DNow!
(normal/ext/prof) detection, so that AMD's run 3DNow! and not SSE.
Any progress?
Thanks,
Dieter
Hello Dieter,
not much really... I did some more code 'readability' changes in the
asm co
23 matches
Mail list logo