mesa3d-dev

[Mesa3d-dev] Callbacks/API hookouts vs. NEW_* flags

[Keith W. <ke...@va...>]

Brian,

I've been thinking about this a little bit & it seems to me there will always
be good reason to keep both of these state update mechanisms around. 
Additionally, by extending the use of the _NEW_ flags we can overcome a couple
of uglinesses in the current code base.

We've talked about this before and I'd said that my position was roughly:

	- Callbacks (to be replaced/augmented by API hookouts) are the mechanism for
keeping the hardware driver uptodate
	- _NEW_ flags are used 
		- to wake up things like the software rasterizer or t&l mechanism after
being put to sleep
			- a large amount of state may have changed without any other notification
		- to keep those components uptodate during normal operation
			- this is the current gl_update_state mechanism, split up between core,
rasterizer and t&l

The two uses for the _NEW_ flags can be handled by the same code -- the only
difference is the amount of state that might have changed.

To this I'd like note another use for the _NEW_ flags:  to notify the driver
itself after a very large state-change, when using callbacks would be
cumbersome.  The obvious example of such a state-change is in glPopAttrib(). 
Rather than attempting to call callbacks for every piece of state in an
attribute, consider adding:

	ctx->Driver.NotifyStateChange( GLcontext *ctx, GLuint newstate )

or, for consistency:

	ctx->Driver.Wakeup( GLcontext *ctx, GLuint newstate )

which can be called in these cases.  The driver would be expected to know
enough about it's internal state to handle this event.

Keith

Re: [Mesa3d-dev] unresolved symbol and other errors

[Brian P. <br...@va...>]

Stefan Seefeld wrote:
> 
> I use a recent cvs version of mesa to build, specifically
> to test the new GGI changes Jon applied. However, there are
> a couple of little problems:
> 
> * a problem related to libtool:
> 
>   libGL.* can't be linked. libtool gets messed up with some
>   input file. The error message is:
> 
>   /usr/local/lib/libggi.la: file not recognized: File format not recognized
>   (the file is specified in Mesa/src/GGI/libMesaGGI.la)
> 
>   same problem for libvga...
> 
> * other libtool related problems prevent the GGI demos (gears2) from linking

I think Jon is still working on that.


> * when compiling in the src/X directory, xm_api.c complains
>   about 'unknown function CLAMP', which ultimately results in a linking
>   error, as CLAMP appears to be a macro. I added an #include "macros.h"
>   to xm_api.c which fixed it.

Already fixed.  There have been a lot of check-ins recently.  If you
find a problem, wait a bit and do another check-out.  That'll often
fix things.

-Brian

Re: [Mesa3d-dev] samples/sphere broken in last two weeks?

[Brian P. <br...@va...>]

Brian Paul wrote:
> 
> Gareth Hughes wrote:
> >
> > One of the updates to the Mesa-3.4 codebase in the last two weeks seems
> > to have broken texturing in this demo app.  Software rendering with
> > standalone Mesa fails to texture the torus at all, and thus it's not
> > surprising that the hardware drivers also fail to texture it.  I just
> > updated with
> >
> > cvs update -D "2 weeks ago"
> >
> > which pulls in the code from directly before the tdfx branch changes
> > were added.  I'll create a diff of what's changed in that period and try
> > to track it down.
> 
> It doesn't texture with any recent version of Mesa for me.
> 
> It looks like a problem in texture completeness.  I'm digging deeper...

It's the ppm image loader.  I converted a .rgb file to .ppm but
the image size is read as 0 by 0.

I changed the program to read a .rgb file and it seems to work with 3.5,
though there's a texture coordinate problem in the rendering.

It's still not texturing with 3.4 though.

-Brian

Re: [Mesa3d-dev] samples/sphere broken in last two weeks?

[Brian P. <br...@va...>]

Gareth Hughes wrote:
> 
> One of the updates to the Mesa-3.4 codebase in the last two weeks seems
> to have broken texturing in this demo app.  Software rendering with
> standalone Mesa fails to texture the torus at all, and thus it's not
> surprising that the hardware drivers also fail to texture it.  I just
> updated with
> 
> cvs update -D "2 weeks ago"
> 
> which pulls in the code from directly before the tdfx branch changes
> were added.  I'll create a diff of what's changed in that period and try
> to track it down.

It doesn't texture with any recent version of Mesa for me.

It looks like a problem in texture completeness.  I'm digging deeper...

-Brian

[Mesa3d-dev] unresolved symbol and other errors

[Stefan S. <see...@MA...>]

I use a recent cvs version of mesa to build, specifically
to test the new GGI changes Jon applied. However, there are
a couple of little problems:

* a problem related to libtool: 

  libGL.* can't be linked. libtool gets messed up with some
  input file. The error message is:

  /usr/local/lib/libggi.la: file not recognized: File format not recognized
  (the file is specified in Mesa/src/GGI/libMesaGGI.la)

  same problem for libvga...

* other libtool related problems prevent the GGI demos (gears2) from linking


* when compiling in the src/X directory, xm_api.c complains
  about 'unknown function CLAMP', which ultimately results in a linking
  error, as CLAMP appears to be a macro. I added an #include "macros.h"
  to xm_api.c which fixed it.

Regards,	Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: see...@ma...

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...

Re: [Mesa3d-dev] __FUNCTION__ ????

[Brian P. <br...@va...>]

Keith Whitwell wrote:
> 
> "Jacob (=Jouk) Jansen" wrote:
> >
> > Hi
> >
> > Compiling today's CVS my compiler complained in VARRAY.C en REDER_TMP.H on a
> > not defined __FUNCTION__. To me this seems DEBUG code left in the source by
> > accident. Is that true?
> 
> The varray.c is leftover debugging.  The render_tmp.h references I would have
> liked to leave in but if this construct isn't portable I guess they've got to
> go.
> 
> I'll check in a fix.

You could put

#ifndef __FUNCTION__
#define __FUNCTION__ ""
#endif

in each function as a work-around, though that's kind of klunky.

-Brian

Re: [Mesa3d-dev] __FUNCTION__ ????

[Keith W. <ke...@va...>]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi
> 
> Compiling today's CVS my compiler complained in VARRAY.C en REDER_TMP.H on a
> not defined __FUNCTION__. To me this seems DEBUG code left in the source by
> accident. Is that true?

The varray.c is leftover debugging.  The render_tmp.h references I would have
liked to leave in but if this construct isn't portable I guess they've got to
go.

I'll check in a fix.

Keith

[Mesa3d-dev] __FUNCTION__ ????

[<jo...@hr...>]

Hi

Compiling today's CVS my compiler complained in VARRAY.C en REDER_TMP.H on a
not defined __FUNCTION__. To me this seems DEBUG code left in the source by
accident. Is that true?

               Jouk


Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

[Mesa3d-dev] samples/sphere broken in last two weeks?

[Gareth H. <ga...@va...>]

One of the updates to the Mesa-3.4 codebase in the last two weeks seems
to have broken texturing in this demo app.  Software rendering with
standalone Mesa fails to texture the torus at all, and thus it's not
surprising that the hardware drivers also fail to texture it.  I just
updated with

cvs update -D "2 weeks ago"

which pulls in the code from directly before the tdfx branch changes
were added.  I'll create a diff of what's changed in that period and try
to track it down.

-- Gareth

[Mesa3d-dev] Re: [Dri-devel] Fog on tdfx (was: GL_EXT_fog_coord, etc.)

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> I'm thinking that if we're using orthographic projection that we
> could use GR_FOG_WITH_TABLE_ON_FOGCOORD_EXT (available on Voodoo3
> and later, don't know about Banshee or Voodoo1/2) if we added a
> fog coord to the Glide vertices and computed it from the vertex Z
> somewhere in the vertex setup code.
> 
> I think this would be much more easily done in the new tdfx-3-0-0
> driver than the current driver.
> 
> Gareth, could we put GR_FOG_COORD into the vertex struct where
> we currently have a GLuint padding?  I haven't examined the vertex
> layouts very much yet.

Yes.  It's on my tdfx-3-0-0 todo list (which, unfortunately, is still
rather long).

I can look into this sooner rather than later if you like.  I'm
travelling again today, but was going to investigate the 32bpp
performance hit tonight.  It should be fairly easy to hook up the fog
coordinate stuff, especially since we've got a place for it in the
default vertex structure already.

-- Gareth

[Mesa3d-dev] Fog on tdfx (was: GL_EXT_fog_coord, etc.)

[Brian P. <br...@va...>]

Michael Vance wrote:
> 
> On Fri, Oct 27, 2000 at 12:46:32PM -0600, Keith Whitwell wrote:
> 
> > Not really.  The FX driver basically turns this code off as the hardware
> > normally fogs from the z or 1/w values (I can't remember which).  I'm sure
> > it's just a matter of setting up the fog table correctly for orthographic
> > projections & making sure that some usable value gets into the vertex format.
> 
> The w-value is always 1 (or 0, can't remember) for vertices in an
> orthographic projection, and the 3Dfx card uses the w-value for
> indexing into the fog table--thus everything is fogged with the fog
> color from entry 1 (or 0).
> 
> In the past, Brian and Daryll mentioned using an alternatve fogging
> method available in Glide3 (a z fogging method), but I don't believe
> it was pursued.


In glide.h we see this:

typedef FxI32 GrFogMode_t;
#define GR_FOG_DISABLE                     0x0
#define GR_FOG_WITH_TABLE_ON_FOGCOORD_EXT  0x1
#define GR_FOG_WITH_TABLE_ON_Q             0x2
#define GR_FOG_WITH_TABLE_ON_W             GR_FOG_WITH_TABLE_ON_Q
#define GR_FOG_WITH_ITERATED_Z             0x3
#define GR_FOG_WITH_ITERATED_ALPHA_EXT     0x4
#define GR_FOG_MULT2                       0x100
#define GR_FOG_ADD2                        0x200

So using GR_FOG_WITH_TABLE_ON_Q or GR_FOG_WITH_TABLE_ON_W is the
same and neither works with orthographic projection since the W
value is always 1.0.

I'm thinking that if we're using orthographic projection that we
could use GR_FOG_WITH_TABLE_ON_FOGCOORD_EXT (available on Voodoo3
and later, don't know about Banshee or Voodoo1/2) if we added a
fog coord to the Glide vertices and computed it from the vertex Z
somewhere in the vertex setup code.

I think this would be much more easily done in the new tdfx-3-0-0
driver than the current driver.

Gareth, could we put GR_FOG_COORD into the vertex struct where
we currently have a GLuint padding?  I haven't examined the vertex
layouts very much yet.

I can't find any documentation for GR_FOG_WITH_ITERATED_Z but I'd
guess that f (fog factor) is just a multiple of the fragment's Z and
can only be used for GL_LINEAR fog if near=0 and far=1.

-Brian

Re: [Mesa3d-dev] EXT_fog_coord, EXT_secondary_color

[Michael V. <bri...@lo...>]

On Fri, Oct 27, 2000 at 12:46:32PM -0600, Keith Whitwell wrote:

> Not really.  The FX driver basically turns this code off as the hardware
> normally fogs from the z or 1/w values (I can't remember which).  I'm sure
> it's just a matter of setting up the fog table correctly for orthographic
> projections & making sure that some usable value gets into the vertex format.  

The w-value is always 1 (or 0, can't remember) for vertices in an
orthographic projection, and the 3Dfx card uses the w-value for
indexing into the fog table--thus everything is fogged with the fog
color from entry 1 (or 0).

In the past, Brian and Daryll mentioned using an alternatve fogging
method available in Glide3 (a z fogging method), but I don't believe
it was pursued.

m.

-- 
Programmer             "Ha ha." "Ha ha." "What are you laughing at?"
Loki Software                      "Just the horror of being alive."
http://lokigames.com/~briareos/                   - Tony Millionaire

Re: [Mesa3d-dev] EXT_fog_coord, EXT_secondary_color

[Keith W. <ke...@va...>]

Brian Paul wrote:
> 
> Keith Whitwell wrote:
> >
> > I've implemented these two extensions.  EXT_secondary_color hasn't been hooked
> > into dispatch, and so hasn't been tested & isn't enabled yet.
> 
> I'm getting some compile errors in the FX driver:
> 
> FX/fxcva.c: In function `fxDDMergeAndRender':
> FX/fxcva.c:482: structure has no member named `Specular'
> 
> FX/fxsetup.c: In function `fxSetupFog':
> FX/fxsetup.c:1438: structure has no member named `FogMode'
> FX/fxsetup.c:1438: `FOG_FRAGMENT' undeclared (first use in this function)
> FX/fxsetup.c:1438: (Each undeclared identifier is reported only once
> FX/fxsetup.c:1438: for each function it appears in.)
> 
> FX/fxvs_tmp.h:152: structure has no member named `FogMode'
> FX/fxvs_tmp.h:152: `FOG_FRAGMENT' undeclared (first use in this function)
> 
> Commenting-out references to VB->Specular, and ctx->FogMode fixes the
> compile-time problems.

I'll check out why this wasn't committed.

> > I've tested EXT_fog_coord with ATI's demo, after some de-windows-ing.
> 
> It would be nice to have a demo of fog_coord and secondary_color in
> Mesa/demos/.  Hint, hint. :)
> 
> > The treatment of fog in the software rasterzer has changed somewhat.  The
> > trick of merging fog colors into vertex colors during the vertex pipeline has
> > been removed.  This wasn't happening for any of the accelerated drivers (FX,
> > utah or dri), to my knowledge, as any driver that asserted it has hardware fog
> > would disable this stage.   We can do this inside the triangle functions if
> > anyone decides they want to.
> 
> Merging fog colors into vertex colors was really only legal when not
> using texturing anyway (or at least particular tex env modes).
> 
> > I was unwilling to play with the logic for choosing line/point/triangle
> > functions at this point, so the fog coordinate will be interpolated whenever z
> > is interpolated.  This is wasteful & will probably be fixed before too long.
> >
> > Brian:  It occurs to me that calculating a fog factor at the vertices and
> > interpolating linearly across the triangle is less accurate than doing the fog
> > equation at each pixel.  Is there a requirement to do it per pixel (in certain
> > hint modes, for instance)?
> 
> That's what GL_FOG_HINT controls.  GL_NICEST implies doing it per-pixel,
> but implementations are allowed to ignore hints entirely.

It's a simple change to get perpixel fog back.  I still have to be able to fog
pixels based on z values for drawing bitmaps etc.

> > Drivers with table fog don't need fog calculations except during fallbacks.
> > The FX driver has an example of how this can be done, though further testing
> > of this is required.
> >
> > Drivers with fog in the 4th component of specular color (mga, i810, r128) no
> > longer need to fiddle with the pipeline to get fog coordinates, as this is now
> > the standard mechanism for calculating fog at the vertices.
> 
> Is this expected to fix the problem with fog not working when using an
> orthographic projection in the 3dfx driver?

Not really.  The FX driver basically turns this code off as the hardware
normally fogs from the z or 1/w values (I can't remember which).  I'm sure
it's just a matter of setting up the fog table correctly for orthographic
projections & making sure that some usable value gets into the vertex format.  

I don't really know much about how table fogging on the tdfx cards works...

Keith

Re: [Mesa3d-dev] EXT_fog_coord, EXT_secondary_color

[Brian P. <br...@va...>]

Keith Whitwell wrote:
> 
> I've implemented these two extensions.  EXT_secondary_color hasn't been hooked
> into dispatch, and so hasn't been tested & isn't enabled yet.

I'm getting some compile errors in the FX driver:

FX/fxcva.c: In function `fxDDMergeAndRender':
FX/fxcva.c:482: structure has no member named `Specular'

FX/fxsetup.c: In function `fxSetupFog':
FX/fxsetup.c:1438: structure has no member named `FogMode'
FX/fxsetup.c:1438: `FOG_FRAGMENT' undeclared (first use in this function)
FX/fxsetup.c:1438: (Each undeclared identifier is reported only once
FX/fxsetup.c:1438: for each function it appears in.)

FX/fxvs_tmp.h:152: structure has no member named `FogMode'
FX/fxvs_tmp.h:152: `FOG_FRAGMENT' undeclared (first use in this function)

Commenting-out references to VB->Specular, and ctx->FogMode fixes the
compile-time problems.


> I've tested EXT_fog_coord with ATI's demo, after some de-windows-ing.

It would be nice to have a demo of fog_coord and secondary_color in
Mesa/demos/.  Hint, hint. :)


> The treatment of fog in the software rasterzer has changed somewhat.  The
> trick of merging fog colors into vertex colors during the vertex pipeline has
> been removed.  This wasn't happening for any of the accelerated drivers (FX,
> utah or dri), to my knowledge, as any driver that asserted it has hardware fog
> would disable this stage.   We can do this inside the triangle functions if
> anyone decides they want to.

Merging fog colors into vertex colors was really only legal when not
using texturing anyway (or at least particular tex env modes).


> I was unwilling to play with the logic for choosing line/point/triangle
> functions at this point, so the fog coordinate will be interpolated whenever z
> is interpolated.  This is wasteful & will probably be fixed before too long.
> 
> Brian:  It occurs to me that calculating a fog factor at the vertices and
> interpolating linearly across the triangle is less accurate than doing the fog
> equation at each pixel.  Is there a requirement to do it per pixel (in certain
> hint modes, for instance)?

That's what GL_FOG_HINT controls.  GL_NICEST implies doing it per-pixel,
but implementations are allowed to ignore hints entirely.


> Drivers with table fog don't need fog calculations except during fallbacks.
> The FX driver has an example of how this can be done, though further testing
> of this is required.
> 
> Drivers with fog in the 4th component of specular color (mga, i810, r128) no
> longer need to fiddle with the pipeline to get fog coordinates, as this is now
> the standard mechanism for calculating fog at the vertices.

Is this expected to fix the problem with fog not working when using an
orthographic projection in the 3dfx driver?

I'll take care of the SecondaryColor dispatch code as soon as I get the
dispatch offsets.

Thanks!

-Brian

[Mesa3d-dev] EXT_fog_coord, EXT_secondary_color

[Keith W. <ke...@va...>]

I've implemented these two extensions.  EXT_secondary_color hasn't been hooked
into dispatch, and so hasn't been tested & isn't enabled yet.  

I've tested EXT_fog_coord with ATI's demo, after some de-windows-ing.

The treatment of fog in the software rasterzer has changed somewhat.  The
trick of merging fog colors into vertex colors during the vertex pipeline has
been removed.  This wasn't happening for any of the accelerated drivers (FX,
utah or dri), to my knowledge, as any driver that asserted it has hardware fog
would disable this stage.   We can do this inside the triangle functions if
anyone decides they want to.

I was unwilling to play with the logic for choosing line/point/triangle
functions at this point, so the fog coordinate will be interpolated whenever z
is interpolated.  This is wasteful & will probably be fixed before too long.  

Brian:  It occurs to me that calculating a fog factor at the vertices and
interpolating linearly across the triangle is less accurate than doing the fog
equation at each pixel.  Is there a requirement to do it per pixel (in certain
hint modes, for instance)?

Drivers with table fog don't need fog calculations except during fallbacks. 
The FX driver has an example of how this can be done, though further testing
of this is required.

Drivers with fog in the 4th component of specular color (mga, i810, r128) no
longer need to fiddle with the pipeline to get fog coordinates, as this is now
the standard mechanism for calculating fog at the vertices.

Keith

Re: [Mesa3d-dev] samples directory

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> Gareth Hughes wrote:
> >
> > Does anyone have a problem with changing the apps that animate in the
> > samples directory to default to double-buffered visuals?  It's a bit
> > frustrating having to specify -db each time, and I use these quite
> > regularly in my testing.
> 
> Fine by me.  The tests originally came from SGI but I've probably
> fixed bugs in all of them over the years.

Great.  I'll commit this today.

-- Gareth

Re: [Mesa3d-dev] samples directory

[Brian P. <br...@va...>]

Gareth Hughes wrote:
> 
> Does anyone have a problem with changing the apps that animate in the
> samples directory to default to double-buffered visuals?  It's a bit
> frustrating having to specify -db each time, and I use these quite
> regularly in my testing.

Fine by me.  The tests originally came from SGI but I've probably
fixed bugs in all of them over the years.

-Brian

[Mesa3d-dev] samples directory

[Gareth H. <ga...@va...>]

Does anyone have a problem with changing the apps that animate in the
samples directory to default to double-buffered visuals?  It's a bit
frustrating having to specify -db each time, and I use these quite
regularly in my testing.

-- Gareth

Re: [Mesa3d-dev] higher bit depth support

[Keith W. <ke...@va...>]

luc-eric rousseau wrote:
> 
> Hello,
> for research, I would like to modify Mesa to support 16 bit per channel
> texture, as well as a higher precision render buffers, either 16 bit or
> single-precision floating point.
> 
> The goal here is to use Mesa to render (non-interactivly) in software high
> precision 3D images made with 16 bit texture source, without loss of
> quality.  The current precision of the vertex coordinates is fine, it's the
> precision of the shading and the alpha blending that matters.  The rendered
> images are not meant for PC monitors (which are only 8 bit per channel max).
> 
> My question is: how much trouble would it be?  Of course, I've already
> looked at the source, but I would like to get an idea of how much of the
> code I would have to change, and if there are roadblocks I would hit.  I
> should also point out that i'm lazy :^)
> 

It will certainly be trouble, but a lot of people are interested in seeing it
happen.  I'm going to be doing some reorganization work in the 3.5 branch over
the next couple of weeks, and one thing I'll be doing is isolating the
software rasterizer in its own directory.  After that has been done it should
be a little clearer which code needs to be touched to acheive this goal.

Keith

Re: [Mesa3d-dev] higher bit depth support

[Allen A. <ak...@po...>]

On Wed, Oct 25, 2000 at 11:08:37PM -0400, luc-eric rousseau wrote:
|                          ... and if there are roadblocks I would hit. ...

One thing that I would expect to cause trouble is the precision with
which you'll need to represent intermediate results when interpolating
vertex attributes.  32-bit fixed point is marginal for 16-bit
interpolants.  You might need to go to 64-bit fixed or
double-precision float.  Check out the math in tritemp.h.

Allen

Re: [Mesa3d-dev] higher bit depth support

[Brian P. <br...@va...>]

luc-eric rousseau wrote:
> 
> Hello,
> for research, I would like to modify Mesa to support 16 bit per channel
> texture, as well as a higher precision render buffers, either 16 bit or
> single-precision floating point.
> 
> The goal here is to use Mesa to render (non-interactivly) in software high
> precision 3D images made with 16 bit texture source, without loss of
> quality.  The current precision of the vertex coordinates is fine, it's the
> precision of the shading and the alpha blending that matters.  The rendered
> images are not meant for PC monitors (which are only 8 bit per channel max).
> 
> My question is: how much trouble would it be?  Of course, I've already
> looked at the source, but I would like to get an idea of how much of the
> code I would have to change, and if there are roadblocks I would hit.  I
> should also point out that i'm lazy :^)

Unfortunately, it will be a lot of work.

It's something that I've had in the back of my head for a couple
years now.  If you look in src/config.h and src/types.h you'll see
a #define for CHAN_BITS and a GLchan datatype.  The idea is that
you could #define CHAN_BITS to 16 and GLchan would become a GLushort
and all the internal pixel paths would have 16 bits of precision
per color channel.

Changing all occurances of GLubyte and the magic number 255 into
GLchan and (1 << CHAN_BITS) - 1 is a step in the right direction
but I'm sure there's many more issues to fix.  It would probably
require a line-by-line audit of the entire code base to get it done
properly.

-Brian

[Mesa3d-dev] higher bit depth support

[luc-eric r. <lu...@ho...>]

Hello,
for research, I would like to modify Mesa to support 16 bit per channel 
texture, as well as a higher precision render buffers, either 16 bit or 
single-precision floating point.

The goal here is to use Mesa to render (non-interactivly) in software high 
precision 3D images made with 16 bit texture source, without loss of 
quality.  The current precision of the vertex coordinates is fine, it's the 
precision of the shading and the alpha blending that matters.  The rendered 
images are not meant for PC monitors (which are only 8 bit per channel max).

My question is: how much trouble would it be?  Of course, I've already 
looked at the source, but I would like to get an idea of how much of the 
code I would have to change, and if there are roadblocks I would hit.  I 
should also point out that i'm lazy :^)

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: [Mesa3d-dev] SGI SI GLU on Mesa website

[Marcelo E. M. <mar...@bi...>]

>> Brian Paul <br...@va...> writes:

 > I plan to replace Mesa's GLU with the SI GLU in a future release.

 Replace as in 'rm ... ; cp ...' or as in 'please use this source to
 generate a libGLU from now on'? (in other words, do you plan to include
 the SGI SI GLU source on the mesa tarball or not?)

 Thanks,

--
Marcelo

[Mesa3d-dev] AGP at user-level: useful?

[<ph...@bo...>]

Gah. My mind is just below frying level :-/

I'm stil trying to port hardware acceleration to Solaris. But my head is in
too many repositories. I can't deal with adding the Mesa repository to my
mental cache right now.

So could someone please take pity on me and answer the following question:

Is Mesa a suitable test frame I could use to test out basic user-level
AGP usage? Can it use AGP at user level?


Reason I'm asking is that the agpgart driver seems to support both
driver-to-driver access, and userland-to-driver access.
I want to get ONLY the userland-to-driver access functioning first.
I need something in userland to test it once I've written it.

But xfree+DRI is not going to be a way to test it, seeing as how I'd have
to port THAT first.

[Mesa3d-dev] SGI SI GLU on Mesa website

[Brian P. <br...@va...>]

Olivier Michel has made Linux RPMs of the SGI Sample Implementation
GLU library and I've added them to the Mesa website (on the downloads
page).

The SI GLU library implements GLU 1.3 whereas Mesa's GLU is only
version 1.2 (and incomplete).

I plan to replace Mesa's GLU with the SI GLU in a future release.

-Brian