Hi Nikolai,
I merged your patches - thank you very much !
Vladimir Dergachev
On Tue, 25 May 2004, Nicolai Haehnle wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As you may be aware, I was trying to get R300 support into a state where it
is possible to start OpenGL a
This may be unrelated, but what version of Xfree? 4.3.0 contains the
first version of the savage driver, which imo is quite horrible
compaired to the second version. (Its so bad, that the vesa 2D driver is
faster than the savage 2D driver.) So, if you're doing a comparison
between 4.3.0 and an X th
--- [EMAIL PROTECTED] wrote:
> Is there savage guide with lspci names and numbers (TwisterK
> 5553:8d02 (rev 01)
> etc) for cards?
take a look a the savage DDX (2d driver). it should give you a pretty
good idea of which chips fall into which categories.
Also my savage guid should give a you a ge
--- [EMAIL PROTECTED] wrote:
> # > My Computer:
> # > aspire laptop +1600xp, via motherboard, savage twister (8d02),
> 2.6.6
> # kernel
> # > xfree log attached with this mail.
> #
> # It's hard to know what is causing the performance difference
> without
> # knowing what both computers are. Is
Dave Airlie wrote:
at the moment texrect, projtex and all the alphas in texenv look broken on
i830 compared to indirect...
I'm not sure if these are regressions since the t_vertex changes and/or
the extra texture units..
I might get a change to install FC2 with X.org so I can at least check it
with
Keith Whitwell wrote:
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAG
at the moment texrect, projtex and all the alphas in texenv look broken on
i830 compared to indirect...
I'm not sure if these are regressions since the t_vertex changes and/or
the extra texture units..
I might get a change to install FC2 with X.org so I can at least check it
with an old copy ..
> Suse 9.0).
>
> I tested a texture and a long anti-aliased line strip.
>
> This is both with r100 and r200.
>
> I don't think DRI has become slower since that older version, so I haven't
> tested X with a recent DRI. I think the problem must be in the adaptations
> made for mesa solo.
>
> Any opin
Maurice van der Pot wrote:
On Mon, May 24, 2004 at 08:54:27AM -0700, Ian Romanick wrote:
For a developer, the best bet is to get the DRI tree and the Mesa tree.
Build the DRI tree and do a 'make install' as root *once*.
The thing is that I didn't want to modify (pollute? ruin?) my working X
ins
Thanks for your response Ian.
On Mon, May 24, 2004 at 08:54:27AM -0700, Ian Romanick wrote:
>
> How are you building? Are you building everything in the DRI tree?
> libGL in the DRI tree and the drivers in the Mesa tree? The libGL built
> in the Mesa tree is *NOT* the one used with the DRI dr
On Tue, 25 May 2004 23:47:46 +0300
[EMAIL PROTECTED] wrote:
> I have compiled savage dri (included mesa and also drm) cvs. With glxgears I
> get
> 267 fps. According to glxinfo dri is working. I use via-agp module.
You have a ProSavage chip which has a lower memory bandwidth than e.g. a
ProSavage
[EMAIL PROTECTED] wrote:
I have compiled savage dri (included mesa and also drm) cvs. With glxgears I
get
267 fps. According to glxinfo dri is working. I use via-agp module.
My friend has also savage. He gets 390fps! He uses intel-agp module.
Why so big difference? Who is developing those agp drive
Is there savage guide with lspci names and numbers (TwisterK 5553:8d02 (rev 01)
etc) for cards?
edie
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle
I have compiled savage dri (included mesa and also drm) cvs. With glxgears I
get
267 fps. According to glxinfo dri is working. I use via-agp module.
My friend has also savage. He gets 390fps! He uses intel-agp module.
Why so big difference? Who is developing those agp drivers? Are there any pages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As you may be aware, I was trying to get R300 support into a state where it
is possible to start OpenGL applications, let them hang the CP and *not*
bring down the entire machine.
Looks like I was successful :)
The attached patch ati.unlock.1.patc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've attached a new version of the patch. This should fix a minor bug: I put
the call to init_timer() too late, which resulted in a kernel warning when
the module was loaded/unloaded without actually being used.
On Sunday 23 May 2004 14:37, Michel D
Jon Smirl wrote:
Mesa-solo does not build with x86 asm turned on and DRI is using x86 asm. It
shouldn't be too hard to make a linux-solo-x86 target.
DRI also includes:
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
That sounds believable. Thank you.
I also believe mesa-solo defaults to
Mesa-solo does not build with x86 asm turned on and DRI is using x86 asm. It
shouldn't be too hard to make a linux-solo-x86 target.
DRI also includes:
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
I also believe mesa-solo defaults to debug optimizations.
If you get all of the compil
Robert Voigt wrote:
I noticed that my test programs run at about half the frame rate with
mesa solo than with XFree86 4.3.0 and DRI 20020611 and mesa 4.0.4 (as it
comes with Suse 9.0).
I believe the drivers built in the Mesa tree are built with -fPIC, so
that should make some differenc. I would
I noticed that my test programs run at about half the frame rate with
mesa solo than with XFree86 4.3.0 and DRI 20020611 and mesa 4.0.4 (as it
comes with Suse 9.0).
I tested a texture and a long anti-aliased line strip.
This is both with r100 and r200.
I don't think DRI has become slower since t
After finding the 3 places where the reg I wanted to control was changed I
went about normalising the code by creating a function
r200UpdateColorOffset.
Added it to the .h and used in in other files that included that .h.
After a succsesfull build I got this error??? I then verrified the output
o
Eric Anholt wrote:
I think I've noticed a problem in i830_tris.c, in i830RenderStart.
Let's say you've got fog turned on but not specular. Then v0 has
VRTX_HAS_SPEC set, and you're emitting the fog factor and a 3-byte pad.
If you then turn on specular, v0 still has VRTX_HAS_SPEC set, so the
test
22 matches
Mail list logo
