--- Brian Paul <[EMAIL PROTECTED]> wrote:
> "Jacob (=Jouk) Jansen" wrote:
> >
> > Hi all,
> >
> > I did not get any answers to my last posts over the last weeks concerning
> > an initialization problem on VMS systems and my proposed solution. (the trafic
> > on Mesa3d-dev is very low last weeks
I've committed fixes and/or workarounds to the following bugs on sourceforge:
101691 - Polygon clipping and GL_LINE
101928 - Polygon clipping and GL_LINE (same fix as above)
101808 - Non-glVertexArrays tristrip bug
101971 - find_last_3f on Dec OSF (worked around)
102369 - segv on dec osf (possibl
There have been a bunch of seperate reports of memory problems under Dec
OSF/Tru64/Digital Unix. They all seem to boild down to the fact that the
VB->IM->OrFlag and VB->IM->AndFlag variables are being computed incorrectly in
gl_compute_orflag() in vbxform.c.
I'm wondering if there is anyone ou
Nicholas Vining wrote:
>
> -Original Message-
> From: Keith Whitwell <[EMAIL PROTECTED]>
> To: Marco Tessore <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; mesa-dev
> <[EMAIL PROTECTED]>
> Date: Thursday, March 16, 200
Marco Tessore wrote:
>
> My system (Slackware 7.0) doesn't compile macros written on multiple
> lines.
> I must compat like the file in attachment.
> Sorry for my English and thank you for Mesa
>
> Marco Tessore <[EMAIL PROTECTED]>
>
> -
Does anybody have code that can reproduce these problems?
If so, I can guarentee a pretty timely fix...
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Another small commit - polygons drawn with polygonmode GL_LINE are now closed
correctly when clipped. I implemented them this way originally, but last
night couldn't recall whether the spec specified one way or the other -- it
does...
Keith
___
Mesa-
Just a note - all these commits have been to 3.3 -- I'll commit to 3.2
tomorrow morning.
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
I've committed a fix to the unfilled tristrip bug (Bug #101808) and another
fix to the clipping problem of Bug #101928 "GL_QUADS clip bug with GL_LINE
polygon mode".
Can the bug owners please review these fixes?
Keith
___
Mesa-dev maillist - [EMAI
Holger Waechtler wrote:
>
> Hi,
>
> here is the fix. Could you check and commit it, Brian ??
>
Committed.
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Neal Tringham wrote:
>
> >What are you really asking for? A documentation on the FX driver (there is
> >lots of stuff in there that I wrote/reworked, but at least as much which I
> >don't really have much background in), or a guide for how to write a modern
> >Mesa driver?
> >
>
> I personally
d...
>
> For whatever its worth, what I personally would appreciate is
> documentation on the optimisations which I think were added (mostly by
> Keith Whitwell?) for Mesa 3.1 / 3.2 / etc as opposed to 3.0, with the FX
> stuff used as an example of how to write a driver to integrat
Brian Paul wrote:
>
> Lately I've been curious about the performance of glTexImage2D under
> various conditions so last night I whipped up a new test program.
> I've check it in demos/texdown.c
>
> You can use the keyboard to change texture size, format, datatype,
> toggle scaling/biasing, glTex
Ralph,
I'm probably the one who should look at this (and a bunch of the other bugs
floating around at the moment), but it won't be till early February that I'll
have the bandwidth to actually get my teeth into them. Apologies for this,
but I'm pretty tied up on the driver side at the moment...
The code that makes windows opengl fast isn't included in the SI released by
SGI. Additionally, the driver you run on windows will have large amounts of
effort expended by the IHV on tweaking for the particular hardware, in
addition to the optimizations not included in the SI.
mitch wrote:
>
Keith Whitwell wrote:
>
> Sven Heyll wrote:
> >
> > On Wed, 26 Jan 2000, Hetz Ben Hamo wrote:
> >
> > Hello,
> >
> > > Hi,
> > >
> > > Well, as the title says - SGI has just released a sample implementation of
> >
Sven Heyll wrote:
>
> On Wed, 26 Jan 2000, Hetz Ben Hamo wrote:
>
> Hello,
>
> > Hi,
> >
> > Well, as the title says - SGI has just released a sample implementation of
> > OpenGL to the Open Source Community.
> >
> > URL:
> >
>http://www.quicken.com/investments/news/story/pr/?story=/news/stori
ralf willenbacher wrote:
>
> polys that should be culled are drawn when they were clipped before.. or
> something like that..
> would it be better to cull and then to clip ?
> sample proggi attached
> draws nothing with mesa 2.6
> --
> ralf willenbacher ([EMAIL PROTECTED])
> *~<:)=- *ching* *ch
I've been out of action with th eflu for the last couple of days - I'm still
pretty sick. I hope to work through the backlog of email over the next few
days, but I can't make any promises.
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://list
Guy Barrand wrote:
>
> Hello Brian
>
> I have a crash in my application on OSF1
> when using the brand new 3.1. A little debugging
> session shows that I am passing in :
>
> vbxform/find_last_3f
>
> static void
> find_last_3f( float data[][3], GLuint flag[], GLuint match,
> GLui
Eero Pajarre wrote:
>
> Keith Whitwell wrote:
> >
> >
> > That's probably not correct. The code looks odd, but basically what it is saying
> > is that if we are lighting in object space and not using Rescale, then we have to
> > introduce the effects
[EMAIL PROTECTED] wrote:
>
> On 02-Dec-99 [EMAIL PROTECTED] wrote:
> >
> >> It seems to trigger some kind of (FX) Mesa bug
> >> on Win95. Specifically do_normal_transform
> >> gets called with a null value
> >> in ctx->NormalTransform
>
> Here is the fix for it:
>
> Index: light.c
> ===
Andre Werthmann wrote:
>
> >> I'm using a linux-2.2.13 kernel with a kernel patch from
> >> "http://people.redhat.com/dledford/linux_kernel.html" written
> >> by Doug Ledford ([EMAIL PROTECTED]).
> >
> >im getting crashes with this one after ~1 hr .. the fpu stack gets
> >messed up somehow..
>
>
Andre Werthmann wrote:
>
> Hello,
>
> Can you help me please with the following questions ?
>
> my first question is:
>
> Is the memory where the parameters (f, m, obj) are pointing to 16 byte aligned ?
> It is somewhat important for using some of the new P3-SIMD instructions.
>
> for example
David Bucciarelli wrote:
> BTW3, I would like to read the opinions of others FX driver developer
> about this problem.
>
I put a bit of work into the FX driver (smiley), and I'm happy to see that
migrate to the XFree license.
Keith
=
__
D
Brian Paul wrote:
>
> I had been building regularly on IRIX and that often caught problems
> that gcc didn't. However, I don't have a compiler on my O2 at this
> time.
>
> If anyone else has access to non-GNU compilers, I encourage you to
> compile Mesa and see if there's problems.
>
I also
OK.
I've recently made some changes that will reduce the footprint of display lists
in mesa 3.1. These are a lot less intrusive than the full solution of a
display-list postprocessor which I'd previously envisaged as necessary to solve
the problem, and contain less possibilities for major inst
Eero Pajarre wrote:
>
> > The reason why I suspected the usefulness of the
> > multitexture emulation is that without multitexture
> > for example my application minimizes texture swapping,
> > but the emulation will swap actively between the two
> > textures. On the other hand the multitexture e
--- Brian Paul <[EMAIL PROTECTED]> wrote:
>
> Well, I'm back on the net and I've checked in some Mesa changes.
>
> 1. I've added some new memory macros to macros.h:
> GL_ALLOC
> GL_CALLOC
> GL_ALLOC_STRUCT
> GL_CALLOC_STRUCT
> GL_FREE
Brian,
There's been a coupl
ralf willenbacher wrote:
>
> i replaced the transform_v16, matmul4 and matmul34 with simd instruction
> functions and there was no performance increase in quake2 or q3test.
> any good reason to have simd support anyway ? :(
>
Q3test is a big application. The matmul routines don't even register
Eero Pajarre wrote:
>
> When using the CVS version (glide driver), it appears
> that line segments (using glBegin(GL_LINE_STRIP) or
> glBegin(GL_LINE_LOOP)) which should be clipped are
> discarded.
>
> Test program attached.
OK. I've committed a fix to this (fxcliptmp.h)
Keith
[EMAIL PROTECTED] wrote:
>
> Hi all,
>
> In the latest CVS in vbxform.c a procedure gl_flush is added. This gives a
> conflict on those systems (like VMS) which have a case insensitive linker with
> the procedure gl_Flush in misc.c. One of the two should get another name.
> I do not know which o
[EMAIL PROTECTED] wrote:
>
> While debugging wrong colors in clipped triangles in the MGA GLX driver
> I discovered that the triangle function was called with
> tri(VB, p0,p1,p2, pv) - with pv being a clipped vertex!
>
> I could fix this in the MGA driver by simply copying the color also
> for c
SiO2 Software wrote:
>
> Who's in charge of CVS access whilst Brian is "away"?
>
> Regards,
>
> Keith Harrison
> SiO2 Software.
> Birmingham, UK.
> [EMAIL PROTECTED] (personal)
> [EMAIL PROTECTED] (work)
Sorry not to get back to you earlier, Keith. (work has been stacking up...).
I've got acc
Dieter Nützel wrote:
>
> linda wrote:
>
> > Dieter Nützel wrote:
> > >
> > > Chris Jones wrote:
> > >
> > > > Heh, one problem after another. I'm getting a build error that I'm not
> > > > sure how to fix.
> > > >
> > > > -functions=2 -c fx_gen_regoff.c
> > > > /bin/sh ../../../libtool --mode=li
Jeff Slutter wrote:
> My G400 is a CVS snapshot from about 8/27/1999 (from
> http://glx.on.openprojects.net/) the TNT is binaries from the NVidia site,
> and they are from around the middle of August. I will get the latest of
> both and test them. The G400 is suffering from more texture issues
hes2 wrote:
>
> I am developing Mesa drivers for my own 3D accelerator based of an FPGA
> board. Specifically I want to show Quake II as a demo for the hardware.
>
> I've written the multi-texturing hardware, and wish to interface to the
> GL_EXT_multitexture extension. In my setup_DD_pointers w
Stephen J Baker wrote:
>
> Someone has to look into the inner workings of glTexCoord4f and find
> the bug.
Stephen,
My guess is it's basically a driver issue as the test program which works ok for
the X and FX drivers failed for him under G400 and TNT. The g200 code is a work
in progress and c
> Jeff Slutter wrote:
>
> Hi,
> I'm currently porting Descent 3 to Linux using Mesa as the OpenGL
> renderer. Using the same source code as the Windows version except for the
> initialization and any other glx specific things I have gotten it all ported.
> However, there seems to be some iss
OK. There are probably a few bugs outstanding, but only truely major ones, or
problems with the build system will delay a beta past this evening.
Thomas: Have you got any more configure/autoconf commits that you want to go
in? Otherwise, can I assume that once whatever's going wrong with build
OK, just trying to package things up for the beta, but I'm having some problems
building the demos after running './bootstrap' and './configure'.
When I type 'make', everything seems to build ok, but nothing happens in the
demos/ directory. If I go in there and type something like:
[keithw@
thierry wilmot wrote:
>
> in some cases, the function glCallLists((CTX_ARG GLuint list )
> hang in function render_vb_lines_clipped( struct vertex_buffer *VB,
> GLuint start,
> GLuint count,
> GLuint parity )
> line 70, file render_tmp.h
>
> *ctx->Driver.LineFunc = NULL
>
> it
[EMAIL PROTECTED] wrote:
>
> Hi all,
>
> Testing the latest CVS-version with the latest version of xlockmore from
> ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/
> I experienced on my VMS system the folowing problems:
>
> -pipes mode : none of the valves connections and meters are visible.
>
I've still got a couple of outstanding bugs, including a lockup in q3test. I'm
interested to get reports of major problems now, rather than an hour after the
beta, so if you've got an app, it's a good time to try it out...
Keith
___
Mesa-dev maillist
Thomas Tanner wrote:
>
> "quad -db" looks wierd if I rotate the object for a while.
>
Good bug. This should be fixed now.
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Wolfram Gloger wrote:
>
> Just in time for Mesa-3.1beta3 :-). I now have what I believe to be a
> very clean fix for the memory leaks I've observed.
Looks good - I'll commit these for the beta.
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
ht
Does anyone know if src-glut is supposed to be understood/recognized by autoconf
- I don't see any mention of it in configure.in, for instance.
Thomas: Are there any special things I have to do about dependancies before I
build/package beta3?
Keith
__
OK. I've committed a big patch which fixes a number of FX driver problems, and
includes a proper treatment of GL_POLYGON_MODE, glEdgeFlag() and the clipping of
these primitives.
All of you who reported FX bugs, please recheck with the latest CVS and see if
this fixed your problems.
Keith
Holger Waechtler wrote:
>
> Hi everybody,
>
> I tried some of the demos last days both with the X and the FX driver.
> Some bugs seem to be there:
> the book/anti.c demo is incredibly coloured and the transparent help
> screen in the 3dfx/demos/tunnel.c demo is not transparent.
>
There was a m
Brian Paul wrote:
>
> Keith Whitwell wrote:
> >
> > It seems there are a couple of FX bugs that have crept in recently. Is it
> > possible to postpone the beta 'till monday so I can clean them up over the
> > weekend?
>
> I won't be able to make
Holger Waechtler wrote:
>
> Hi everybody,
>
> I tried some of the demos last days both with the X and the FX driver.
> Some bugs seem to be there:
> the book/anti.c demo is incredibly coloured and the transparent help
> screen in the 3dfx/demos/tunnel.c demo is not transparent.
>
> The X driver
Thomas Tanner wrote:
>
> On 15-Sep-99 Holger Waechtler wrote:
> > the fixam script, which enables automatic dependency tracking, if gcc and
> > gnu make are available, is now called automatically from bootstrap.
>
> No, the other way round: fixam disables automatic dependency tracking,
> if gc
Stephen J Baker wrote:
>
> On Wed, 15 Sep 1999, Keith Whitwell wrote:
>
> > I think that the long development cycle for 3.1 was justified (I have to say that
> > really...), but it'd be nice to cycle more rapidly for the next few iterations.
>
> Yes - the dev c
Brian Paul wrote:
>
> At PI I'll work on whatever is needed in the OpenGL/Mesa/Linux/hardware
> effort. I can't be specific now but but stand-alone Mesa will still be
> supported by me.
I think that the long development cycle for 3.1 was justified (I have to say that
really...), but it'd be nic
John Carmack wrote:
>
> >This is done inside glide, mesa doesn't see it. I was wondering about
> this for
> >the mga driver - do you have the magic incantations to build the displaced
> >vertices for the two triangles? I don't see any way to avoid taking
> 1/sqrt(area)
> >to get the increments.
Mårten Björkman wrote:
>
> I'm trying to estimate the amount of work required in order to
> optimize the transformation functions for Pentium III. Since the
> functions are many and some of them won't benefit much from using the
> new SIMD instructions, it's probably preferable to spend most ener
John Carmack wrote:
>
> There should probably be a set of standard functions that synthesize lines
> and points with quads, similar to the automatic quad-to-two-triangles
> routines.
>
> The matrox glx driver currently handles colored, depth buffered, and
> blended lines, but can't handle wide l
> (=bad stride + not writeable, which are both true...)
>
> Of course the problem does not show up at the first
> call to draw elements, and the program where it happens
> has > 6 lines of code...
Silly bug - I've committed a fix, thanks for the report.
Keith
___
Looks like the last commit introduced a couple of its own bugs. Also found a
problem of missing depenencies in the FX/X86 assembly.
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
ralf willenbacher wrote:
>
> Keith Whitwell wrote:
>
> > I haven't tried your demo, but I did commit a bunch of fixes to culling
> > yesterday. Can you try again and see if there is still a problem?
> >
> > Keith
> >
> > ___
Wolfram Gloger wrote:
>
> Hi,
>
> I'm strongly suspecting a bug in Mesa-3.1beta2 where either the
> modelview matrix or compiled display list information becomes corrupt
> when multiple GLX contexts are switched between (I'm using the
> standard X11 driver). Both Mesa-3.0 and GLX from Irix6.2 d
Anyhow, the point of my last message was to say that I've committed fixes for
those problems & you might have better luck if you try again now.
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Dieter Nützel wrote:
>
> Q2/Q3 do NOT run at this time :-(
>
> Maybe some 3DNow! vs. 3DNow! Rev. 2 (Athlon) issues?! --- Daryll?
> But that's not so important (for me, at least @ this stage) ;-)
>
For Q3 at least there have been a bunch of things go wrong with the fast path.
This was able t
ralf willenbacher wrote:
>
> i tried to profile mesa by adding -pg to the cflags and then run gears
> but only calls in gears are listed in gmon.out.. what did i do wrong ?
This isn't enough for profiling shared libraries - gprof doesn't have enough
information to do the job (relocation address
Josh Vanderhoof wrote:
>
> Adam Wiggins <[EMAIL PROTECTED]> writes:
>
> > Oh, they're more or less the same - the difference is that Intel's chips
> > have floating point which is comparable to their integer processing,
> > whereas AMD's K6's beat the pants off of Intel for integer, but lagged
>
OK. I've checked in some stuff to fix the remaining outstanding bugs from Miklos
and Eero.
I'll be doing some testing of my own over the next couple of days. Does anyone
else have bug reports (with demos) waiting in the wings?
Keith
___
Mesa-dev
OK.
I've checked in some code which I think fixes the 2 outstanding bugs reported by
Miklos.
It's been a little hard to keep track of what's happening with bugs, so at the
risk of starting a deluge I'm going to ask everyone who's (1) got a bug in mesa
they want fixed and (2) got a small demo p
Brian Paul wrote:
>
> Keith Whitwell wrote:
> >
> > Brian Paul wrote:
> > >
> > > I'm posting the following on behalf of Dave Wilkinson, who's associated
> > > with cosource.com, an organization to provide funding for free software
> >
Brian Paul wrote:
>
> I'm posting the following on behalf of Dave Wilkinson, who's associated
> with cosource.com, an organization to provide funding for free software
> projects.
>
> PIII optimizations for Mesa would be great. I have a few contacts at
> Intel so getting technical information s
Eero Pajarre wrote:
>
> Brian Paul wrote:
> >
> > Eero Pajarre wrote:
> > >
> > > It appears that glEnd does not directly set Current.Primitive
> > > to GL_POLYGON+1, leaving this task to vbxform code. (which
> > > is not always called here)
> > >
> > > glGetError checks the Current.Primitive dir
Brian Paul wrote:
>
> 1. Resizing a window didn't always update the internal frame buffer
>boundary values, causing rendering to get clipped to the old window
>size. Fixed now.
>
> 2. glReadPixels(format=GL_ALPHA) didn't work. Fixed.
>
> 3. Also have been doing clean-up work in glBitm
Thomas Tanner wrote:
>
> On 14-Jul-99 Keith Whitwell wrote:
> > I note in the current src/... Makefile.am's there is the line:
> >
> > AUTOMAKE_OPTIONS = no-dependencies
> >
> > which stops the use of gcc-generated dependencies. My questions are:
&g
I note in the current src/... Makefile.am's there is the line:
AUTOMAKE_OPTIONS = no-dependencies
which stops the use of gcc-generated dependencies. My questions are:
why?
what should we be using instead?
Keith
___
Mes
I've merged code from the experimental branch upto the tag 'merge-1' back into
the main branch. I'd like to see that branch shut down fairly shortly - I'd like
to merge any new code that's appeared over the last week or so in the next couple
of days.
If people want to continue on on that branc
I've been thinking...
If we've renamed libMesaGL.so to libGL.so, shouldn't we also adopt the .so
numbering that is expected for libGL, ie. libGL.so.1.2 (instead of
libGL.so.3.1.2)?
We would still have a single digit for the mesa version...
Keith
___
Brian Paul wrote:
>
> I've seen this before but I can't recall the reasoning for it.
> When defining a multi-statement macro people use this construct:
>
> #define MY_MACRO(FOO) \
>do {\
> statement1(FOO); \
> statement2(FOO); \
> statemen
Eero Pajarre wrote:
>
> When Vtuning my app I noticed a spike in CPU time in the
> routine responsible for calculating the color values for
> clipped triangles. This was caused by the float to int
> conversions.
>
> I did the following change (output from WinCVS diff) to
> clip.c
>
> 39a40
> >
Miklós Fazekas wrote:
>
> Hello!
>
> Ken Dyke posted some notes while ago about texture alignament
> problems in Quake3.
> If you look at the sky you can notice it.
> There are two screenshots:
> http://valerie.inf.elte.hu/~boga/shot0002.jpg
> shows the problem
Miklós Fazekas wrote:
>
> Hello!
>
> Looking at the OpenGL specification, and then looking at Mesa sources. One
> thing is not clear. When using non-compiled vertex arrays the OpenGL 1.1
> specification warns you no to change the elements of memory previously
> specified glVertexPointer between
Miklós Fazekas wrote:
>
> Hello!
>
> When will Keith new optimalizations be merged from the Experimental branch?
> Will it be the last biggest change before the 3.1 release?
I'll be starting on it tomorrow. Its the last big change from me for 3.1 - and I
don't know of any other ones floating a
Hi
I've made a couple of changes on the experimental branch. The main one
is the removal of SGIS multitexture. Additionally I've added a pair of
macros:
#define MESA_VERSION MESA_VER(MESA_MAJOR_VERSION, \
MESA_MINOR_VERSION, \
MESA_BR
Miklós Fazekas wrote:
>
> Hello!
>
> Here is a program which demonstrates a bug in Mesa 3.1beta2. (It's in latest
> CVS also.) I've tried it with FX defined (ie. VB_SIZE=72).
>
> It draws a series of lines, then a point then a series of lines again.
> When it overflows the VB, the line falls o
Can't we do anything about this???
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Happy birthday!
Keith
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Stephen J Baker wrote:
>
>
> One SPECIFIC reason to go this way is that it gives people
> writing low level drivers a stable (even numbered) platform
> to work with.
>
> What does everyone else think about this idea?
OK, but really that's what having a development and stable branch in cvs
ache
Brian Paul wrote:
>
> Keith, I'd like to hear what your longer-term coding plans are. Do
> you see a milestone in your work for a 3.1 release?
I think you could say that the latest batch of changes pretty much
represents the end of a certain line of improvements. I know Holger is
doing some 3d
There is another dead lock on the CVS repository, this time restricted
to the src/FX directory. It's been there at least six hours.
I've sent a message to Rob Walker, but I don't know who else is capable
of looking at this.
Keith
___
Mesa-dev maill
"C.J. Beyer" wrote:
>
> > Ah, I'd was curious why there'd been no cvs updates in so long! It the
> > experimental-1 branch where development occurs, then? A note about this
> > on the website would be helpful!
>
> Actually, I was under the impression that the experimental branch was just
> a tem
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:
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 experi
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 experi
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
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
"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 t
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
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 insid
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 i
Citizens,
I've committed some updates on the experimental branch. The major
changes since my last post on this are:
- Fast path implemented in the FX driver for the common
transformation and rasterization only pipeline configurations.
- Fake multitexture support for single tmu
Eero Pajarre wrote:
>
> Some time ago I reported problems with using CVA and flat triangles.
> Now I have a problem which might be related, at least this happens when
> I (again) used flat shaded triangles (by accident (again)).
>
> This time I think I have been able to locate the problem pretty
Kai Schütz wrote:
>
> By enabling FLAT shading I get a really large speedup:
>
> ==
> *** /tmp/gamma.cSat Jun 5 16:32:58 1999
> --- gamma.c Sat Jun 5 16:33:13 1999
> ***
> *** 38,41
> --- 38,42 --
1 - 100 of 169 matches
Mail list logo
