Eero Pajarre wrote:
>
> Keith Whitwell wrote:
>
> > The buffer will actually have 3024 elements, leaving enough room for the
> > clipped vertices. I think the problem is because VB->ColorPtr is zero
> > or pointing to invalid memory. I've fixed a problem in this area in the
> > experimental bra
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'
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
> > ASSERT_OUTSIDE_BEGIN_END() comma
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 -DUSE_MMX_A
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 th
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 this:
>
> For a x86 ta
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 shoul
"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).
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, Rmas
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=0x
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 seper
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
Holger Waechtler wrote:
>
> 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
| 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 to
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 s
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
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
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 c
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 h
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 t
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 Sys
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 genera
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:
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
cl
24 matches
Mail list logo
