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 in the
Does the XMesaBufferList ever get reset to NULL when the last context
is destroyed?
I'm seeing lockups in XSync() inside of XMesaGarbageCollect() after
creating, then destroying, then trying to create again... the first
time through, XMesaBufferList is NULL, I would assume this would be
true the
Michael Vance wrote:
Does the XMesaBufferList ever get reset to NULL when the last context
is destroyed?
I'm seeing lockups in XSync() inside of XMesaGarbageCollect() after
creating, then destroying, then trying to create again... the first
time through, XMesaBufferList is NULL, I would
On Thu, Jan 27, 2000 at 11:17:47AM -0700, Brian Paul wrote:
Yes, XMesaBufferList should be set to NULL when the last XMesaBuffer
is removed from the list.
Hm, free_xmesa_buffer() is never called after the
glXDestroyContext(). It seems that because I delete my window and
display after the
Michael Vance wrote:
Another odd thing is that the XSync() is on the flip side of an #ifdef
Xfree86Server guard--and I'm using the XFree servers for 3Dfx.
So you're using XFree 3.9 with DRI? I haven't examined how the
X/Mesa garbage collection mechanism works in there.
On Thu, Jan 27,
On Thu, Jan 27, 2000 at 11:49:45AM -0700, Brian Paul wrote:
So you're using XFree 3.9 with DRI? I haven't examined how the
X/Mesa garbage collection mechanism works in there.
No, sorry, I misunderstood the meaning of the define. I'm using the
3.3.5 stuff.
Have you looked at
Michael Vance wrote:
On Thu, Jan 27, 2000 at 11:49:45AM -0700, Brian Paul wrote:
Have you looked at glXReleaseBuffersMESA(Display, GLXDrawable)?
If you call this function after destroying your window, Mesa
will free the internal XMesaBuffer associated with the drawable.
No, I have
Hi,
Just tried to checkout the 3.3 version, but a
cvs checkout -r mesa_3_3_dev Mesa
gives me a
cvs [server aborted]: no such tag mesa_3_3_dev
What's wrong ?
cheers thanks,
emanuel
___
Mesa-dev maillist - [EMAIL PROTECTED]
On Thu, Jan 27, 2000 at 12:19:48PM -0700, Brian Paul wrote:
So, you're all set now?
Yep. Offhand, do you know if similar problems exist with other glX
implementations?
And since Mesa can't know when X Drawables and Visuals are destroyed,
it doesn't know when to free the private associated
Michael Vance wrote:
On Thu, Jan 27, 2000 at 12:19:48PM -0700, Brian Paul wrote:
So, you're all set now?
Yep. Offhand, do you know if similar problems exist with other glX
implementations?
A real implementation of GLX shouldn't have any such problems.
-Brian
Hi Brian, hi everybody,
I cleaned up the 3dnow stuff and removed some workarounds. We have now the
following problem: the routines
gl_3dnow_transform_points3_general_raw
gl_3dnow_transform_points4_general_raw
gl_3dnow_transform_points3_3d_raw
gl_3dnow_transform_points4_3d_raw
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 to
On Wed, 26 Jan 2000, mitch wrote:
I think that the good parts of Opengl should be merged to the bad parts
of mesa. Also, is there anyway to squeeze some more speed out of mesa?
It seems that mesa is a good 8 to 10 FPS slower than Opengl with most
apps and is much slower for low resolutions.
On Thu, 27 Jan 2000, Jacob (=Jouk) Jansen wrote:
[EMAIL PROTECTED] wrote on 26-JAN-2000 18:40:01.60
Stephen J Baker wrote:
On Wed, 26 Jan 2000, Adam D. Moss wrote:
Stephen J Baker wrote:
I was wondering about whether we should consider
dropping GLUT from the next major Mesa
Stephen J Baker wrote:
On Thu, 27 Jan 2000, Jacob (=Jouk) Jansen wrote:
Agreed. I think it would be best to include both (or pointers only) in the
Mesa-distribution so that application builders can choose. Remember that
(free)glut is only a tool-kit to make programming with OpenGL
[EMAIL PROTECTED] wrote
Hmm.. they claim that Mark has dropped glut. But I got a mail from Mark only
3 weeks ago saying that he is working on version 3.8.
Well, that's interesting news. But considering GLUT 3.7 was released
on May 7th 1998 and not one word on the subject has appeared from
On Thu, Jan 27, 2000 at 08:58:30AM -0700, Brian Paul wrote:
At some point in the future, I might further split up the Mesa
distro: main lib, GLU lib, glut, and demos.
As the maintainer of the Debian .debs, I am all for this.
If split, could you have them use their own directory instead of
Stephen J Baker wrote:
Also, unless you say *which* other OpenGL and on which platform,
(and for which specific resolutions) there is zero information content.
dont forget the compiler issue..
gcc and friends are made for portability
visual c/c++ 5.0 is only made for wintel and it spills
Hi everybody,
has anybody of you build Mesa with Visual C for glide ? And compared this
with 3dfx' OpenGL driver ?
- Holger
On Thu, 27 Jan 2000, ralf willenbacher wrote:
Stephen J Baker wrote:
Also, unless you say *which* other OpenGL and on which platform,
(and for which
Holger Waechtler [EMAIL PROTECTED] writes
Hi everybody,
has anybody of you build Mesa with Visual C for glide ? And compared this
with 3dfx' OpenGL driver ?
Mesa 3.1 / 3.2 for 3dfx / Windows support? Yes.
My results with a recent 3.2 build are:
1) Mesa 3.2 is generally a little slower than
20 matches
Mail list logo
