Tom Flynn wrote:
Hi there,
Background:
I'm currently running an application on a machine which has no graphics
and setting my display to another machine that has an NVidia card in it
(and has the nvidia closed-source drivers). The application makes
several calls to glDrawArrays(). One
Jeremy C. Reed wrote:
I don't know if this is related to original mesa or not. (I haven't
tested the MesaLib 6.4 by itself yet.)
I received the following failure when building latest X.org from CVS.
This is on NetBSD/i386 2.0.2 with GCC 3.3.3. It has the same error seven
times when
Evgeny Kotsuba wrote:
Hi,
Is here any life, or or all life lives now on some wiki/irc channel ?
There's many discussions on this list. I never use IRC.
Is there any person who makes code for windows (not only bugzilla's
witers) ?
Karl Schultz has been doing the Windows maintenance.
martin wrote:
Thnx for enable.c hint :) Seems a rather long list of items in that
swtich to dig through ...
I have some very newbish questions in my pocket, better i lay them out
before i write one single line of code at all.
a) does mesa software rendering try to use the memory of the
Michael Frumin wrote:
On 1/17/06, *Brian Paul* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Michael Frumin wrote:
I am attempting to capture 3D geometries from OpenGL applications for
Have you looked at OpenGL's feedback feature? It lets you capture
OpenGL
and flattening.
will maybe pursue the re-use of Mesa vertex program processing.
thanks,
mike
On 1/17/06, *Brian Paul* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Michael Frumin wrote:
On 1/17/06, *Brian Paul* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL
Adam Jackson wrote:
CVSROOT:/cvs/mesa
Module name:Mesa
Repository: Mesa/src/mesa/main/
Changes by: [EMAIL PROTECTED] 06/01/19 10:00:38
Log message:
Avoid a crash when the user has enabled glVertex{,Attrib}Pointer but hasn't
filled in a valid pointer for that
Roland Scheidegger wrote:
Donnie Berkholz wrote:
I recently updated Mesa from 6.4.1 to CVS HEAD, and discovered that the
UT2003 demo [1] didn't work anymore. With some help from aet, I finally
got some useful information out of it that suggests TNL as the likely
culprit:
(gdb) bt
#0
Roland Scheidegger wrote:
Keith Whitwell wrote:
You should only be able to get into that stacktrace if you have set
MESA_EXPERIMENTAL in the environment. Is that true? What happens if
you unset it?
No this happens (for me) when MESA_EXPERIMENTAL is not set too, which is
weird and the
Donnie Berkholz wrote:
The Doom3 demo [1] crashes in single-player mode (multi-player isn't
available in the demo) when it's about to start the first level.
The backtrace:
#0 0xb5d0ed26 in attrib_8_2 (v=0x9f6d39c8) at
t_vtx_generic.c:107
#2 0xb5d100fd in _tnl_VertexAttrib2fvNV (index=8,
Donnie Berkholz wrote:
Brian Paul wrote:
Try applying the attached patch for t_vtx_generic.c It's just some
assertions to try to narrow down the problem.
Didn't get any assertion failures out of that.
But it still crashes, right?
Could you possibly use gdb to inspect some
Dave Airlie wrote:
Hi Brian,
I've just picked up your changes to move to EGL 1.2 but it looks
like you didn't checkin the include/GLES directory which is missing
EGLenum and some defines...
Done. Just be aware that there's no official EGL 1.2 header file from
Khronos yet so things
David Reveman wrote:
Hey,
here's the latest version of the texture from pixmap spec that Xgl will
be supporting. It's not fully implemented in Xgl yet, just so much of it
that you can get an indirect rendering compositing manager running using
it.
I've also attached a temporary glxproto.h
David,
I've checked in your patches to the Mesa tree. You should probably
get CVS-write access, if you don't already.
-Brian
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download
Bernardo Innocenti wrote:
Brian Paul wrote:
I've checked in your patches to the Mesa tree.
The bit from glxproto.h-texture-from-pixmap-1.patch has not
been applied to xorg/proto/GL/glxproto.h.
Mesa doesn't build without it.
Someone else with CVS-write for X.org will have to check
Adam Jackson wrote:
On Monday 06 February 2006 07:58, David Reveman wrote:
Hey,
here's the latest version of the texture from pixmap spec that Xgl will
be supporting. It's not fully implemented in Xgl yet, just so much of it
that you can get an indirect rendering compositing manager running
Jacob (=Jouk) Jansen wrote:
Hi all,
I try to commit a file to the CVS. Everything goes fine until the end, but...
after editing the update message cvs stops without sendig the file and
without any error message. Has someone changed something on the server-side?
Not that I know of. I just did
Johnson, Charles F wrote:
I've been trying to a copy of the Mesa tree that has the Rotation and 945GM
support that Alan H. checked in and it looks to me like the CVS tip does not
currently build. I get:
make[3]: Entering directory `/root/mesa/Mesa/src/glx/x11'
gcc -c -I. -I../../../include
Michał Król wrote:
Mesa uses its own replacement functions for C library functions.
I need to use the following missing functions:
float asin (float);float atan (float); Should I use the clib
functions directly, or there is someone who
takes care of it and who assures compatibility
Jürg Billeter wrote:
Hi
The attached patch corrects a type mismatch on systems where unsigned
int and size_t differ, i.e. on 64-bit systems. This fixes compiz for me
on my x86_64 system. The patch should probably be applied to both, HEAD
and mesa_6_4_branch.
Fixed in CVS. Thanks.
-Brian
Peter wrote:
I think that someone in the Dev list maybe able to help me with this.
For some background, we are working on creating a backend compiler for
the ARB_vertex_program languague used in Mesa. We have an IR defined,
and we are currently working on the code generation to x86/SSE.
Jerome Glisse wrote:
Hi Brian,
Maybe you would like to push the two following fix in 6.4
branch. This are a bug fixe and a typo fixe in mesa/main/texenvprogram.c :
http://sourceforge.net/mailarchive/forum.php?thread_id=9554801forum_id=33172
Randall Hand wrote:
(long time user, first time poster... Hope I don't get anyone too
ruffled up :) )
I'm working on an older CompaqSC45 here and having some issues compiling
Mesa3d on it. After some digging, I found that the int64_t wasn't
being defined in include/GL/glxext.h. I modified
Karl,
The Windows driver is looking pretty decent now.
The framebuffer/renderbuffer code should be working correctly now but
I'll run an idea past you to consider.
Since the framebufffer object overhaul in Mesa, it's now possible for
a driver to let core Mesa totally manage the front/back
Vishwanath T. K. wrote:
Hi All,
Can anyone one tell me the difference between mesa_6_4_2 and
mesa_6_4_branch cvs trees.
The docs/VERSIONS file will list the highlights.
I want to update mesa-6.4.2 from cvs for getting XGL working on my
system. I have had a look and the version.h of both
I think the arbitrary-length bitset type is overkill. We really just
need a 64-bit bitfield for the foreseeable future, right?
These macros in bitset.h are pretty heavy if all the bitsets are
just 64 bits or less.
#define BITSET_COPY(x, y) _mesa_memcpy( (x), (y), sizeof (x) )
#define
Michał Król wrote:
On 06/04/06, Brian Paul [EMAIL PROTECTED] wrote:
I think the arbitrary-length bitset type is overkill. We really just
need a 64-bit bitfield for the foreseeable future, right?
These macros in bitset.h are pretty heavy if all the bitsets are
just 64 bits or less
Ewald Snel wrote:
Hi,
Here are two patches for the R300 DRI driver. One adds conventional fog
support to the R300 driver, the other fixes a problem with rectangular fp16
textures.
The fog patch is not based on actual register values of the fglrx driver, but
rather by trial and error
David Reveman wrote:
Patch for mesa with a set of updates for EXT_tfp. Includes necessary
FBConfig support, adds attrib_list to BindTexImage and fixes
CreateDrawable so that glXCreatePixmap works.
Xgl and compiz requires this patch.
Can I commit this to head?
In general, it looks OK to me.
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Reveman wrote:
Patch for mesa with a set of updates for EXT_tfp. Includes necessary
FBConfig support, adds attrib_list to BindTexImage and fixes
CreateDrawable so that glXCreatePixmap works.
Xgl and compiz requires this
Jaakko Hyvätti wrote:
Hi all,
I wonder if anyone has any thoughts about this? Is my solution, to define
a new glBlendFunc for software renderer, the only one for this problem or
are there less invasive solutions?
Any thoughts on if this extension would be acceptable to Mesa code? :-)
Jaakko
hsjeon wrote:
- Original Message -
From: hsjeon [EMAIL PROTECTED]
To: Brian Paul [EMAIL PROTECTED]
Cc: mesa3d-dev@lists.sourceforge.net
Sent: Monday, May 15, 2006 2:16 PM
Subject: Re: [Mesa3d-dev] Q:How can I replace mesa with licenced OpenGL ?
- Original Message -
From
Philipp Klaus Krause wrote:
I'm using Mesa 6.4.1 software rendering (DRI doesn't work with i915 in
current Debian unstable).
Somehow GL_INDEX_OFFSET doesn't work for me.
I have
glPixelTransferi(GL_INDEX_OFFSET, . );
followed by calls to
glDrawPixels()
in my program, but it just matter which
Philipp Klaus Krause wrote:
Brian Paul wrote:
It seems my OpenGL is somehow broken since the last xorg upgrade (from
Debian unstable)
trying to run with -ci gives:
freeglut (./a.out): ERROR: Internal error Visual with necessary
capabilities not found in function fgOpenWindow
X Error
Thomas Sondergaard wrote:
Can I compile mesa for software rendering with support for indirect
rendering as well?
Can you be more specific?
Are you just looking for a libGL.so library that can send/receive GLX
protocol?
Or are you looking for the libGLcore.so and libglx.so modules that are
Jesse Allen wrote:
A recent change to arbprogparse.c on Apr 28 is causing references to vertex
attrib zero to crash. I'm not entirely sure on how it is supposed to be
handled now, but my guess from trial and error is found below. Someone please
take a look.
Changes:
Be more strict on the
Philipp Klaus Krause wrote:
Brian Paul wrote:
Philipp Klaus Krause wrote:
What's the current state of shaders in Mesa?
The GL_ARB_vertex/fragment_shader extensions are supported.
I see that src/mesa/shader/slang directory growing since a long time.
Is there something useable? If yes, how do
Philipp Klaus Krause wrote:
What's the current state of GL_ARB_vertex_blend in Mesa?
It seems it's not implemented, extension_helper.h seems to provide some
facilities for drivers though.
I see no need to implement that extension since the same thing can be
accomplished with a vertex program.
Dave Airlie wrote:
Just a quick question, i am wondering if anyone thought about moving
mesa to git ?
For the DRM I've contemplated it, I've just got a bit backed up with other
things, but I'd like to move it in the next while at some point
I'd personally like to see Mesa in git,
Hanno Böck wrote:
i686-pc-linux-gnu-gcc -I../../../include/GL -I../../../include -I.. -I../main
-I../math -I../glapi -I../tnl -Wall -Wmissing-prototypes -std=c99 -ffast-math
-O2 -march=pentium-m -fomit-frame-pointer -pipe -fno-strict-aliasing -fPIC
-m32 -DGLX_USE_TLS -D_POSIX_SOURCE
Matthias Hopf wrote:
On Jun 23, 06 19:59:58 +0100, Keith Whitwell wrote:
The egg on our face is that, AFAIK, Mesa based drivers are the *only*
drivers that don't support this functionality. That app developers
expect it to be there isn't surprising.
I guess I was the one who introduced the
Martijn van Oosterhout wrote:
I've been trying to track down a bug in the r128 driver causing lots
of the following messages in the kernel logs:
r128_cce_depth called without lock held
The problem appears (to me anyway) to be in
Mesa-6.4.2/src/mesa/drivers/dri/r128/r128_span.c. There are
Ilias Karakyritsis wrote:
Dear mesa3d-developers,
I have also post this mail to the users list .Sorry if this is not right
but i am really want your help.
This is my first mail in this list as a new member of the mesa family.
I have a really big problem and i hope my discussion with
Roland Scheidegger wrote:
Brian Paul wrote:
Matthias Hopf wrote:
On Jun 23, 06 19:59:58 +0100, Keith Whitwell wrote:
The egg on our face is that, AFAIK, Mesa based drivers are the *only*
drivers that don't support this functionality. That app developers
expect it to be there isn't
Martijn van Oosterhout wrote:
Here are some basic patches for bugs in the r128 driver. They don't by
themselves fix my problem, but they contribute.
I checked in your fix, with minor changes:
1. put if statement's code on the next line (for the sake of
debugging/breakpoints).
2. Use 'else
Jerome Glisse wrote:
Just wanted to add, even if i am sure most people here also
follow xorg list :). Xorg are thinking to move to real git organisation.
If i understand well, the git official repo would be accessible to developer
and each developer would have is git repo. Thus to push
Martijn van Oosterhout wrote:
The first is just clamps x2/y2 as previously discussed. It just hasn't
been committed yet.
The second is more complicated. I've noticed that occasionally the
output view is offset in the Y direction from where the actual window
is. With some poking around I've
Martijn van Oosterhout wrote:
Attached is a patch I've worked up for enabling antialising on lines
and triangles for the r128. To my eye it looks like antialiasing, but
not of particularly high quality.
I'll check in your patch in a bit.
The r128 also offers something
called supersampling
Hanno Böck wrote:
What are the plans for a new mesa-release out of the current cvs? Any date
set
yet?
There've been a lot of changes that would be worth an update.
We probably should wrap up 6.5.1 pretty soon.
However, I think there's a fair number of open bugs in the bug
database that
Jerome Glisse wrote:
On 7/11/06, Brian Paul [EMAIL PROTECTED] wrote:
Hanno Böck wrote:
What are the plans for a new mesa-release out of the current cvs?
Any date set
yet?
There've been a lot of changes that would be worth an update.
We probably should wrap up 6.5.1 pretty soon
Hanno Böck wrote:
Am Mittwoch, 12. Juli 2006 21:46 schrieb Brian Paul:
I might redo this in a different way. I think I'll change LIB_DIR to
be either 'lib' or 'lib64' instead of $(TOP)/lib or $(TOP)/lib64.
Then, in the Makefiles, replace occurances of $(LIB_DIR) with
$(TOP)/$(LIB_DIR
Hanno Böck wrote:
Hi,
To make correct installation on 64 bit machines possible, I've introduced a
new var INSTALL_LIB_DIR and set it to $(INSTALL_DIR)/lib64 on amd64 (should
probably be done on other archs, too).
Attached patch, please apply.
I might redo this in a different way. I
Hanno Böck wrote:
In various dri-drivers, DO_DEBUG is defined to 1.
Shouldn't this be defaulted off and only enabled via -DDO_DEBUG on CFLAGS?
(suggested Patch attached)
diff -Naur
Hanno Böck wrote:
mesa-commit seems to be dead since a few days.
Sending mail directly to [EMAIL PROTECTED] works, so it
looks like it's the CVS check-in trigger that's not working. I'll
have to bring it up with the freedesktop.org guys.
I can remember this is not the first time this
Michel wrote:
Hmm. Basically, whatever libGL's soname actually is, libGL itself (and
by extension this code) should know and thus be able to dlopen the
correct soname. I don't really like the idea of dlopening libGL.so
because it may pick up the wrong one with libGL.so.1 vs.
libGL.so.2,
Sean D'Epagnier wrote:
I have found out why alphablending and readpixels did not work. When the
renderbuffer was created, the fields for width, height, and bits for rgba
components were never filled out in the struct gl_renderbuffer Base
component.
I have tested this on demos that use
Michal Krol wrote:
CVSROOT: /cvs/mesa
Module name: Mesa
Repository: Mesa/include/GL/
Changes by: [EMAIL PROTECTED] 06/08/01 17:56:27
Log message:
Fix GL_MESA_shader_debug for glut.h.
You should be using GLuint instead of unsigned int.
-Brian
Michał Król wrote:
On 01/08/06, Brian Paul [EMAIL PROTECTED] wrote:
Michal Krol wrote:
CVSROOT: /cvs/mesa
Module name: Mesa
Repository: Mesa/include/GL/
Changes by: [EMAIL PROTECTED] 06/08/01 17:56:27
Log message:
Fix GL_MESA_shader_debug for glut.h.
You should be using GLuint
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
Normally when an application calls glXGetProcAddress a dummy stub is
created. In the current implementation, a dispatch offset is not
assigned at this time. The existing code expects that the driver
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
Add new attribute called static_dispatch to the function element. This
boolean attribute, which defaults to true, determines whether or not a
static dispatch function is available in libGL for
I'd like to release 6.5.1 by the end of the month.
Please don't check in any risky code changes in the mean time.
Developers should take a look at the list of open bugs to see what can
be fixed. Most seem to be bugs in various DRI drivers.
See
Download from http://mesa3d.sourceforge.net/beta/
Just downloading and compiling on a variety of platforms to make sure
no files are missing would be good feedback.
-Brian
-
Using Tomcat but need to do more? Need to
Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
I've checked in a test for mesa_vp-Base.Parameters == NULL. That
should fix it.
Thanks, but is there a reason why Base.Parameters is NULL in the first place?
I scanned through
the rest of the file and saw that there were
Sean D'Epagnier wrote:
Brian Paul wrote:
Download from http://mesa3d.sourceforge.net/beta/
Just downloading and compiling on a variety of platforms to make sure
no files are missing would be good feedback.
the src/glut/mini directory is missing from the glut tarball, glut/fbdev
depends
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
I'd also like to mark functions in the following extensions this way for
the 6.5.1 release:
GL_EXT_framebuffer_object
Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
It may be that the GL_PROGRAM_UNDER_NATIVE_LIMITS_ARB query is
happening before glProgramStringARB() has been called.
Fixed in CVS.
So the final step would be to make wine call glProgramStringARB() before
glGetProgramivARB
Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
In OpenGL terms, there's nothing illegal about calling
glGetProgramivARB() before glProgramStringARB().
I have no idea what Wine is trying to do, but it was definitely a bug
in Mesa.
Well in that case, I am confused. No-one has
Roland Scheidegger wrote:
Brian Paul wrote:
I just added src/mesa/shader/programopt.c to CVS. It had been sitting
in my working tree for a while.
The _mesa_append_modelview_code() function modifies a vertex program
with the instructions needed to implement the position invariant
option
Michał Król wrote:
On 23/08/06, Brian Paul [EMAIL PROTECTED] wrote:
Download from http://mesa3d.sourceforge.net/beta/
Just downloading and compiling on a variety of platforms to make sure
no files are missing would be good feedback.
Link fails under Windows
Second release candiate with bug fixes since Aug 23:
http://mesa3d.sourceforge.net/beta/
Planning to release 6.5.1 (final) on Thursday.
-Brian
-
Using Tomcat but need to do more? Need to support web services, security?
William A. Hoffman wrote:
Hi, we have found an issue with mesa 6.5 and CVS mesa.
It seems that creating a context, then deleting it,
then creating a new one causes a crash.
Here is a simple VTK example:
vtkRenderWindow ren
ren Render
ren Delete
vtkRenderWindow ren
ren Render
ren
Hanno Böck wrote:
Hi,
When I try to run compiz on xorg-server with latest mesa-cvs, it crashes for
me (radeon 9200). This doesn't happen on 6.5.1-rc1, so it's a regression to
the first rc.
I'll try to figure out which cvs-change caused this, I'll probably give you
further info within
Shawn Starr wrote:
The Fedora people have been hanging on to a patch for Mesa since 6.4.1 for
the r300,
I am currently using this patch without issue (for all the latest compiz
stuff). Is there a reason this isn't in 6.5.x yet?
I don't recall seeing anything about this before.
It seems
Roland Scheidegger wrote:
Kristian Høgsberg wrote:
On 9/5/06, Roland Scheidegger [EMAIL PROTECTED] wrote:
Shawn Starr wrote:
The Fedora people have been hanging on to a patch for Mesa since
6.4.1 for the r300, I am currently using this patch without issue
(for all the latest compiz
Are there any outstanding Mesa bugs that need to be fixed before the 6.5.1
release? If not, I'll soon make a final release candidate and plan on
releasing by the end of the week.
-Brian
-
Using Tomcat but need to do
Roland Scheidegger wrote:
Brian Paul wrote:
I've looked at that and indeed, chances that we actually hit a fast
memcopy path when using rgba is about as big as hell freezing, at
least on little endian. Even after modifying texstore_rgba (see
patch), it'll just never happen. Everyone
Martijn van Oosterhout wrote:
On 9/12/06, Brian Paul [EMAIL PROTECTED] wrote:
Are there any outstanding Mesa bugs that need to be fixed before the
6.5.1
release? If not, I'll soon make a final release candidate and plan on
releasing by the end of the week.
Well, other than
I've uploaded the 3rd release candidate to http://www.mesa3d.org/beta/
Planning to release 6.5.1. tomorrow unless something pops up.
-Brian
-
Using Tomcat but need to do more? Need to support web services, security?
Get
Michal Krol wrote:
On 14/09/06, Brian Paul [EMAIL PROTECTED] wrote:
I've uploaded the 3rd release candidate to http://www.mesa3d.org/beta/
Planning to release 6.5.1. tomorrow unless something pops up.
It's Windows and VC6 again.
Configuration: mesa - Win32 Debug
Jacob (=Jouk) Jansen wrote:
Hi all,
Today I changed the Default visual of my X-server to DirectColor visual. All
is
fine except that all objects drawn by Mesa get weird colours.
I suspect that DirectColor-visuals is not working properly in Mesa.
Would it be easy to fix?
With DirectColor
Jacob (=Jouk) Jansen wrote:
[EMAIL PROTECTED] wrote on 20-SEP-2006 17:16:47.82
Jacob (=Jouk) Jansen wrote:
Hi all,
Today I changed the Default visual of my X-server to DirectColor visual. All
is
fine except that all objects drawn by Mesa get weird colours.
I suspect that
Jerome Glisse wrote:
On 9/21/06, Brian Paul [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
Hi,
Roland pointed me to this yesterday (src/mesa/main/glheader.h):
/*
* Either define MESA_BIG_ENDIAN or MESA_LITTLE_ENDIAN.
* Do not use them unless absolutely necessary!
* Try to use
Michel Dänzer wrote:
On Fri, 2006-09-22 at 11:14 +0100, Keith Whitwell wrote:
Maybe enable for the paths that are well understood and tested, but
where it is still behaving contrary to expectations, leave it disabled.
I'd say it is behaving as expected in the software mesa cases and
Keith Whitwell wrote:
Brian Paul wrote:
Michel Dänzer wrote:
Keith wrote:
I think from Brian's description of the meaning of the
texture format struct naming, a driver that wanted a
different component order in a packed field would have
to specify a different texformat struct - ie
Jacob (=Jouk) Jansen wrote:
[EMAIL PROTECTED] wrote on 21-SEP-2006 17:16:31.19
Jacob (=Jouk) Jansen wrote:
[EMAIL PROTECTED] wrote on 20-SEP-2006 17:16:47.82
Jacob (=Jouk) Jansen wrote:
Hi all,
Today I changed the Default visual of my X-server to DirectColor visual.
All
is
fine
Jacob (=Jouk) Jansen wrote:
[EMAIL PROTECTED] wrote on 27-SEP-2006 16:02:31.84
Is the GLUT window created with a TrueColor visual?
It just running i.e. the gears program from progs/demo
Does this program set the visual to TrueColor?
When GLUT creates a window it uses glXChooseVisual().
Li Ming wrote:
Hi, all,
Could someone explain a bit in details the
implementation of the TexSubImage function?
I'm especially interested in the hardware path.
That varies a bit from one DRI driver to the next. Are you interested
in a particular DRI driver, or drivers in general?
How
[EMAIL PROTECTED] wrote:
What exactly does the dispatch table do. I understand that it is a
function pointer table, however, I do not fully understand what the pros
and cons of using it is. I see that Haiku's implementation now uses
it. I am trying to evaluate it to see if it would
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is now the right time to move Mesa over to get? Please? :)
I'm probably going to start a long-running branch soon, and that's a
much less painful experience with GIT than with CVS. I'm sure it would
also make life easier
Michal Krol wrote:
On 06/10/06, David Cole [EMAIL PROTECTED] wrote:
First post to mesa lists... hopefully this is the right place for this
question:
The ability to icorporate custom GLSL shaders was recently added to VTK.
However, our tests of this fail when VTK is linked using mesa apparently
Andreas Stenglein wrote:
Hello,
here is some build fix for tdfx_tex.c
I don't know if it is right and/or if it works.
It's correct. Thanks.
-Brian
-
Using Tomcat but need to do more? Need to support web services,
Roland Scheidegger wrote:
Jerome Glisse wrote:
According to fragment program extension, TEX, TXP, ... should
give you the right A value (Ap depending on which texture unit
you are using).
That's not how I read that. TEX,TXP,... refer to texture sampling
only, there is no thing as previous
Roland Scheidegger wrote:
Brian Paul wrote:
Well, if my theory is sound, then the glean pixelFormats test is wrong.
I don't think the test is wrong as-is. It's just that GL_COMBINE mode
exercises things in a different way. A better way, in fact.
I'll clean up your patch, Roland, and check
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
I spent some time this weekend trying to further clean-up the buffer
resize code.
Thanks for digging into this.
In order to do 1, each driver must be updated. Basically, before a
GLframebuffer
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
I've added #ifdef/#else/#endif in _mesa_make_current() to show what
code should be removed, and to check that the caller does what's expected.
I think those ASSERTs may be incorrect. When
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
Brian Paul wrote:
In order to do 1, each driver must be updated. Basically, before a
GLframebuffer is bound for the first time, it must be initialized.
Specifically
Thierry Reding wrote:
Hi,
I am wondering whether it is possible to make libOSMesa run with a DRI/GLX
enabled libGL. The reason I ask is that currently Debian ships libOSMesa in a
package which only provides the software rasterizer libGL while the package
providing the DRI/GLX libGL doesn't
Benno Schulenberg wrote:
Brian Paul wrote:
I just applied the patch from your previous email,
Any chance that the same patch gets applied to the 6.4 branch? Or
has that branch died? It is nevertheless the only branch that works
reliably on a unichrome, and there have been several
Keith Whitwell wrote:
Brian Paul wrote:
CVSROOT: /cvs/mesa
Module name: Mesa
Repository: Mesa/src/mesa/tnl/
Changes by: [EMAIL PROTECTED] 06/10/18 17:36:57
Log message:
Fix a dangerous use of ASSERT in an else-clause not enclosed in braces.
We've been lucky if this hasn't
make install uses two tools to install files: $(INSTALL) and
$(COPY_LIBS). $INSTALL is 'install' but $COPY_LIBS is cp -f -d (on
linux anyway).
We need COPY_LIBS because 'install' doesn't preserve symbolic links.
Unfortunately, not all versions of 'cp' support the -d option either.
Kind
1 - 100 of 1059 matches
Mail list logo
