JONATHAN DINERSTEIN wrote:
> For the best benefit for everybody, I think moving Mesa development to OpenGL
> is a good idea.
Impossible for licensing reasons if the XFree86 integration
effort is to continue along a similar path.
To reiterate: Mesa needs to have a XFree-style license to be
able t
Keith Whitwell wrote:
> Here's one - it's not immediately obvious if it is relevent, but it's not in
> our license now.
>
> > 3. No License For Hardware Implementations. The licenses granted in
> >Section 2.1 are not applicable to implementation in Hardware of the
> >algorithms embodied i
Stephen J Baker wrote:
> I was wondering about whether we should consider
> dropping GLUT from the next major Mesa distribution
> (3.4 I guess) and replacing it with 'freeglut'
FWIW I think that this is a good idea, though I
can't say whether freeglut is mature enough for the
3.4 timescale.
--Ad
Doug Rabson wrote:
> Phong shading can still have mach banding. To get rid of this, just enable
> dithering.
I think that you confuse banding and mach banding. Dithering
won't help with the latter.
--Adam
___
Mesa-dev maillist - [EMAIL PROTECTED]
Brian Paul wrote:
> I think we're in need of a bug database. I'm seeing a lot of bug
> reports but little follow-up on them. A database would help a lot.
> I'll see what I can have VA Linux systems set up for us.
>
> If anyone has comments on good/bad bug databases, post them here.
> I'm just
Theodore Jump wrote:
> PS: I don't see a 'docs' directory when I do a "cvs update" - am I missing
> something simple here?
'cvs update' doesn't create new files, it just gets latest
revisions of existing ones. You probably want to run
'cvs checkout'.
--Adam
___
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
Theodore Jump wrote:
> Yeah, known problem. The only way around that I can think of would be to ship
> the .obj file for that specific entity. Second choice would be your suggestion
> of the "NASM ready" file, along with NASM. Oh, question, I haven't looked
> recently but how large is NASM, how mu
