Keith Whitwell wrote:
The real problem with this is that changing to flat shade back again
means a buffer flush per rectangle. This is masked by the fact that in
the current model we have to do a buffer flush inside the
ASSERT_OUTSIDE_BEGIN_END() command, although this hopefully won't
Hi Ralph,
The asm_???.c /.h /.S files are not used at this time. Take a look into
the files in src/X86 instead (prefer the experimental-1 CVS branch,
there are the 3Dnow related things in this folder, too).
It should work once like this:
For a x86 target, cmopile with -DUSE_X86_ASM
Keith Whitwell wrote:
Brian Paul wrote:
Keith Whitwell wrote:
The real problem with this is that changing to flat shade back again
means a buffer flush per rectangle. This is masked by the fact that in
the current model we have to do a buffer flush inside the
Keith Whitwell wrote:
Holger Waechtler wrote:
Hi Ralph,
The asm_???.c /.h /.S files are not used at this time. Take a look into
the files in src/X86 instead (prefer the experimental-1 CVS branch,
there are the 3Dnow related things in this folder, too).
It should work once like
"Adam D. Moss" wrote:
Keith Whitwell wrote:
I believe that you can, as long as your binutils can cope.
and do the
test at runtime to decide which ones to activate?
Again, I read Holger's last paragraph to indicate that that is
what happens (correct me if I'm wrong).
I'm a bit
Brian Paul wrote:
The following TrueColor (and DirectColor) visuals use optimized code
which directly pokes pixels into the XImage instead of using XPutPixesl:
32bpp, Rmask=0xff, Gmask=0x00ff00, Bmask=0xff
32bpp, Rmask=0xff, Gmask=0x00ff00, Bmask=0xff
24bpp,
Keith Whitwell wrote:
Brian Paul wrote:
The following TrueColor (and DirectColor) visuals use optimized code
which directly pokes pixels into the XImage instead of using XPutPixesl:
32bpp, Rmask=0xff, Gmask=0x00ff00, Bmask=0xff
32bpp, Rmask=0xff, Gmask=0x00ff00,
On 07-Jun-99 Keith Whitwell wrote:
I believe that you can, as long as your binutils can cope.
and do the
test at runtime to decide which ones to activate?
...
I'm a bit naive on the make options as I usually hack my own makefiles.
I was really referring to the need for the seperate
On Mon, 7 Jun 1999, Keith Whitwell wrote:
I think a better approach would be to compile everything
we are capable of do the checks at runtime.
That's exactly the thing I want to do. The linux-3dnow target is currently
the one which compiles in all available optimisations
| I think rendering of Rects should always take place with flat rendering,
| because smooth rendering doesn't make sense because it's impossible to
| specify different colors/normals for the vertices. ...
| ... Did I miss something ? Maybe fogging ?
Lighting can cause the vertices
On 07-Jun-99 Keith Whitwell wrote:
(And if the autoconf stuff works, we won't need these targets anymore - )
This sounds like it is done,
Yep.
perhaps we should disable the old methods
on the experimental branch for the same reasons - get people using
autoconf by default so we can shake
Thomas Tanner wrote:
On 07-Jun-99 Keith Whitwell wrote:
(And if the autoconf stuff works, we won't need these targets anymore - )
This sounds like it is done,
Yep.
perhaps we should disable the old methods
on the experimental branch for the same reasons - get people using
Thomas Tanner wrote:
On 07-Jun-99 Keith Whitwell wrote:
(And if the autoconf stuff works, we won't need these targets anymore - )
This sounds like it is done,
Yep.
perhaps we should disable the old methods
on the experimental branch for the same reasons - get people using
On 7 Jun, Holger Waechtler wrote:
Hi Ralph,
The asm_???.c /.h /.S files are not used at this time. Take a look into
the files in src/X86 instead (prefer the experimental-1 CVS branch,
there are the 3Dnow related things in this folder, too).
Ah, I'd was curious why there'd been no cvs
On 7 Jun, Thomas Tanner wrote:
Please contact also Thomas Tanner, who is trying to write autoconf support
for Mesa.
... who has finished converting Mesa to autoconf.
I need testers, please !!.
Please checkout the experimental-1 branch or download the
current snapshot
Thomas Tanner wrote:
I think that'd be a very bad idea.
Let's try to avoid monolithic designs and select drivers via configure
options or, even better, make Mesa modular (a nice alliteration :) !
I could add portable dlopen support to Mesa, if you like.
Yes, I think this is the way to
Thomas Tanner wrote:
... who has finished converting Mesa to autoconf.
I need testers, please !!.
Please checkout the experimental-1 branch or download the
current snapshot http://picasso.ffii.org/mesa/mesa-exp.tar.gz
Ok, I tested the packet: (If got a PentiumPro, Debian 2.1 System)
On Mon, 7 Jun 1999 14:04:49 -0700, Keith Whitwell wrote:
Can't we have a prebuilt ./configure in the repository?
This is generally considered to be a Bad Idea, since configure is
autogenerated code and it's easy to forget to update it before checking
in changes (and it wastes space). The
Kai Schütz wrote:
Thomas Tanner wrote:
... who has finished converting Mesa to autoconf.
I need testers, please !!.
Please checkout the experimental-1 branch or download the
current snapshot http://picasso.ffii.org/mesa/mesa-exp.tar.gz
Ok, I tested the packet: (If got a
I've optimized dithered 16bpp TrueColor (5r-6g-5b) in the X driver.
Basically, I added a new pixel format case: PF_DITHER_5R6G5B. I
haven't benchmarked it but it seems to work correctly and should
be a little faster than before.
Also, I've rewritten most of the 24bpp TrueColor code to make it
20 matches
Mail list logo
