--- On Fri, 9/10/09, Robert Noland wrote:
> You can't include GPL code into an MIT project without
> poluting the license.
Ah. So that means Mesa would need the GLIBC copyright holder's explicit
permission ... That would be Uli Drepper, presumably.
Cheers,
Chris
-
--- On Thu, 8/10/09, Brian Paul wrote:
> I think that we could just bracket the call to
> _slang_compile() with the set/restore-locale calls.
I'd hate to make an obvious suggestion, but... can't you just copy strtod()
code (without the locale support) from GLIBC? My basic research suggests that
--- On Thu, 8/10/09, Brian Paul wrote:
> I think that we could just bracket the call to
> _slang_compile() with the set/restore-locale calls.
Is that wise? Does multi-threaded behaviour matter here? I think the locale is
global.
"The strtod() and atof() functions can be used safely in multithre
--- On Thu, 8/10/09, tom fogal wrote:
> What about
>
> char *lang = getenv("LANG");
> setenv("LANG", "POSIX", 1);
> strtod(...);
> setenv("LANG", lang, 1);
>
> i.e. push / pop the LANG value?
The neater way to implement that solution would be to use
char *oldLocale = setlocale(LC_NUMER
--- On Mon, 16/3/09, Ian Romanick wrote:
> I'd bet a shiny nickel that WoW only uses when
> ARB_fragment_program and ARB_fragment_shader are not available. :)
Possible, although:
a) $ strings /opt/wine/World\ of\ Warcraft/WoW.exe | grep ARB_fragment
GL_ARB_fragment_program
(No ARB_fragment_sha
--- On Mon, 16/3/09, Roland Scheidegger wrote:
> I think though outside of trying to run d3d apps in one way or another
> there's very few apps out there which would use this extension (I don't
> know of any but maybe they exist - I wasn't able to find some sample code
> using this outside of ati
--- On Mon, 16/3/09, Roland Scheidegger wrote:
> you forgot to mention the R200 - not that it makes much
> difference, and I wouldn't know exactly how to implement this on these
> chips, though it probably wouldn't be too difficult.
What about R300+ too? Yes, this hardware might theoretically of
Hmm... Is that so?
$ strings /opt/wine/World\ of\ Warcraft/WoW.exe | grep ATI_env
GL_ATI_envmap_bumpmap
I'm not going to complain.
Cheers,
Chris
--- On Fri, 13/3/09, Ian Romanick wrote:
> May I ask why? I thought we were trying to remove old crap
> that no applications use.
-
You may say that, but I don't believe it. You only need to be bitten *once* by
an inexplicable crash that vanishes after a total rebuild before you find
yourself typing "make realclean; make linux-dri-x86" quite often...
Cheers,
Chris
--- On Fri, 28/11/08, Brian Paul <[EMAIL PROTECTED]> wrote:
--- On Sun, 21/9/08, Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Chris -- go ahead & commit. I'll dig into it shortly.
I'd love to, but I don't have access. Can someone else do it, please?
Thanks,
Chris
-
This SF.N
X86 compilation is currently broken, and this quick patch fixes it.
Cheers,
Chris
diff --git a/src/mesa/x86/common_x86_asm.S b/src/mesa/x86/common_x86_asm.S
index ef3cc9e..ea4047a 100644
--- a/src/mesa/x86/common_x86_asm.S
+++ b/src/mesa/x86/common_x86_asm.S
@@ -40,6 +40,7 @@
*/
#include "ma
Whoops.
Cheers,
Chris
diff --git a/src/glx/x11/Makefile b/src/glx/x11/Makefile
index 8d4a23f..2bcf94e 100644
--- a/src/glx/x11/Makefile
+++ b/src/glx/x11/Makefile
@@ -50,7 +50,7 @@ OBJECTS = $(SOURCES:.c=.o) $(MESA_GLAPI_OBJECTS)
INCLUDES = -I. \
-I$(TOP)/include \
-I$(TOP)/include/G
Hi,
I've tried raising this issue with the Wine developers as bug #15297, but
they're stonewalling. Basically, trying to launch WoW with the R300 Mesa
drivers is producing one of the following 3 results, seemingly at random:
a) Wine fails at start-up (most common result):
X Error of failed requ
Hi,
I have just noticed that glxgears flickers very badly after I enable desktop
effects with my SetTexOffset patch. On the other hand, enabling desktop effects
*without* the SetTexOffset patch corrupts/blurs all the icons on my gnome
panel. So the patch obviously still has at least one small p
Hi,
This patch is a straightforward duplication of the R200 SetTexOffset code,
except that there is no big-endian tx_table[] array. I have tested this on
Fedora 9 and it seems to work OK:
(II) AIGLX: Screen 0 is not DRI2 capable
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open res
Hi,
WoW has been crashing at start-up with "invalid drawables" (OpenGL mode) for
ages, but suddenly it's started working again. However, I am still seeing
texturing errors in certain locations that look like random blotches dancing
all over the place. This is actually an improvement: before WoW
Hi,
Since R300 now supports GL_ARB_shadow I thought I'd try running the shadowtex
program. When I start the program, all I see is a black window. However, I can
then cycle through the various comparison modes to get the following results:
GL_LESS: blank
GL_GEQUAL: coloured shapes
GL_GREATER: co
This is what valgrind now says about glxgears. The "jump depends on
uninitialised values" one
looks most worrying:
==3765== Memcheck, a memory error detector.
==3765== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==3765== Using LibVEX rev 1732, a library for dynamic binary tran
--- Brian Paul <[EMAIL PROTECTED]> wrote:
> Chris, can you grab the latest code and retest?
That's a lot happier :-). Only these two errors now:
==7265== Syscall param ioctl(generic) points to uninitialised byte(s)
==7265==at 0x4277AC29: ioctl (in /lib/libc-2.7.so)
==7265==by 0x421FC54: r
Hi,
I think there's a problem with Mesa git. This was with a clean rebuild:
*** glibc detected *** glxgears: double free or corruption (!prev): 0x08444bc0
***
=== Backtrace: =
/lib/libc.so.6[0x42718ac1]
/lib/libc.so.6(cfree+0x90)[0x4271c0f0]
/usr/X11R6/lib/modules/dri/r300_dri.so(_me
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> Chris could you enable pixelShaders (SET pixelShaders "1") and try out
> the patch from the parent mail?
I have the following options set:
SET pixelShaders "1"
SET M2UsePixelShaders "1"
SET M2UseShaders "0"
and I *think* that the patch makes things
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> Have a look at http://wiki.winehq.org/Wine_and_Valgrind. But I assume
> the slowdown will make Wow unplayable.
Hi,
Thanks for that. "Unplayable" doesn't even begin to describe how slow it is - I
don't even manage
to login, and the DSOUND subsystem
--- Brian Paul <[EMAIL PROTECTED]> wrote:
> If the crash is happening in a variety of places, my guess is a memory
> corruption error somewhere. Is it possible to run with valgrind?
I could try with valgrind, but I've never tried using valgrind with a Wine
process before. Is
there anything spec
--- Brian Paul <[EMAIL PROTECTED]> wrote:
> I'm guessing we're dereferencing a null/invalid pointer here. What are
> the values of unpack and unpack->BufferObj?
>
> It's funny a crash would happen there since the same pointers are
> dereferenced just before this in the call to
> _mesa_validate
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> Never seen anything like this. Do you have s3tc enabled? Just saw
> Brian's email.
Yes, I enable s3tc because WoW really doesn't cope well here without it. (And
it used to cope
better *with* it, too.)
Cheers,
Chris
Hi,
WoW has become extremely unstable with Mesa-git on my Radeon 9550 (Linux
2.6.25, xf86-video-ati
also from git). Are you seeing anything like this, please? (*cough* WoW works
fine with fglrx...)
Cheers,
Chris
Unhandled exception: page fault on read access to 0x0003 in 32-bit code
(0x7d
Hi,
Has the header file dri2proto.h not been checked in? Or is it just not part of
Mesa?
Cheers,
Chris
__
Sent from Yahoo! Mail.
A Smarter Inbox http://uk.docs.yahoo.com/nowyoucan.html
-
--- Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
> Wine is passing it to GLX in the call to glXMakeCurrent(). It's just
> an X ID, so 0x71 could certainly be a valid value...
What seems to be happening is that Wine calls glxDestroyContext(), and then we
have the following
call-stack:
driDestroy
--- Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
> Wine is passing it to GLX in the call to glXMakeCurrent(). It's just
> an X ID, so 0x71 could certainly be a valid value... does wine use
> glXCreateWindow()?
Well, RootWindow() followed by glxCreateContext():
286 Window win = RootWindow(gd
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> No problem here. But I think I've seen this error before. Perhaps it's
> an drm/mesa setup issue.
Here is the useful part of the backtrace, when a drawable 0x71 first appears.
The crash itself
doesn't happen until the context is destroyed again (I t
Hi,
I have been getting this error from WoW when it exits for the last few weeks,
coinciding with a
large libGL restructuring:
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 146 (XFree86-DRI)
Minor opcode of failed reques
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> Wow depends on weight=(1,0,0,0) or vertex.weight=vertex.generic1 in its
> vertex shaders.
Hi,
Just to be pedantic, what kind of mis-rendering does this patch fix?
Cheers,
Chris
__
Sen
Hi,
I have noticed that I am getting warnings like these in some OpenGL games:
*WARN_ONCE*
File r300_texstate.c function r300SetTexImages line 301
DXT 3/5 suffers from multitexturing problems!
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> I just tested my flag Problem with stock Ubuntu 7.10, and it shows exact
> the same (wrong) behavior like all other combinations I tested (sw and
> hw rendering). The only possible explanation: We have different Wow
> versions.
> Mine: 2.3.3 (7799)
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> What about this one (this time tested)
>
> !!ARBvp1.0
> ATTRIB v1 = vertex.normal;
> ATTRIB v2 = vertex.position;
> END
Yes, this one locked my GPU up. I'm guessing that my WoW installation doesn't
call this program.
(Much?)
Cheers,
Chris
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> !ARBvp1.0
> ATTRIB v18 = vertex.normal;
> MOV result.position, vertex.position;
> END
>
> lock up my r300 (but not Chris Rankins?).
This vertex program gives me a black triangle on a grey background, and no GPU
lockup.
$ ./vp-tris ~/attrib18.txt
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> For me it blows completely wrong
> Here's a screen shot: http://oribi.org/linux/mesa/wow_flag.png
> It's even wrong with software renderer (7.0 and git), so I doubt its mesa.
> What version of wine are you using?
Yes, your banner is fluttering severa
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> Chris, does the flag on the bottom-right corner off the startscreen also
> behave strange?
That flag is a ragged banner blowing in the wind here. Isn't that what you see?
Cheers,
Chris
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> No problem with multiple windows here. I run wow in windowed mode
> without winedesktop you too? I can't test flame/cloud because currently
> i have no wow account, but it sounds like a vertex/fragment shader bug.
> Chris, does the flag on the bottom
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> Thanks for pushing, but it doesn't solve my problem :(
> Idiotic, but valid wow-shaders like
>
> !ARBvp1.0
> ATTRIB v18 = vertex.normal;
> MOV result.position, vertex.position;
> END
>
> lock up my r300 (but not Chris Rankins?). I could also handle i
--- Jerome Glisse <[EMAIL PROTECTED]> wrote:
> I have commited a slightly different version of your patch when
> we update only when there is no error.
And OpenGL mode in WoW is suddenly a lot less "funky" too :-).
Cheers,
Chris
___
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> Markus Amsler just posted a fix.
Yes, that worked.
Cheers,
Chris
___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
--
Hi,
Something added to git tonight has turned menu boxes in World or Warcraft bight
pink :-)! (I'd
provide a screenshot, but trying to run WoW while sharing the screen with
another application
always locks up the GPU.) I have at least been able to rule out the cache-flush
change to
r300_emit.c,
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > @@ -765,7 +765,7 @@ static void driDestroyScreen(__DRIscreen *screen)
> >
> > if (psp->dri2.enabled) {
> > drmBOUnmap(psp->fd, &psp->dri2.sareaBO);
> > - drmBOUnreference(psp->fd, &psp->dri2.sareaBO);
> > + d
--- Markus Amsler <[EMAIL PROTECTED]> wrote:
> WoW in opengl mode hangs the r300 GPU due to an uncommon vertex program.
> It defines an attibute (ATTRIB v18 = vertex.normal;) which is never used
> in the vertex program. This unused attrib goes into InputsRead. r300
> code doesn't handle this ca
Hi,
The current mesa git is breaking for me and falling back to indirect rendering.
(I am using the
r300 driver.) The following patch gets it working again for me:
diff --git a/src/mesa/drivers/dri/common/dri_util.c b/src/mesa/drivers/dri/commo
index 0175158..23befac 100644
--- a/src/mesa/driver
Hi,
I tried playing World of Warcraft with a Radeon 9550 card (r300) instead of my
rv280, and it seems
to be having a few problems with git Mesa. These are the two warnings it gave
me:
*WARN_ONCE*
File r300_vertprog.c function r300
--- Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Arg, eventually I'll send this mail correctly (last one was rejected
> since my @intel.com address isn't a subscriber).
>
> How does this one look?
Well, it compiles and doesn't crash... ;-)
Cheers,
Chris
__
Hi,
It occurs to me that the one thing that GarbageCollectDRIDrawables() doesn't do
is delete hash
items that have been collected. I've created a "quick fix" that destroys the
hash and then
recreates it, and this stops Warcraft crashing when it tries to exit. (I
suppose a better fix
would be so
Hi,
A NULL pointer is killing OpenGL for my Radeon 9200; here's a quick fix.
Cheers,
Chris
diff --git a/src/mesa/drivers/dri/r200/r200_context.c
b/src/mesa/drivers/dri/r200/r200_context.c
index 2b18889..6d2392d 100644
--- a/src/mesa/drivers/dri/r200/r200_context.c
+++ b/src/mesa/drivers/dri/r20
Hi,
I have noticed that Wine/World of Warcraft is now crashing in OpenGL mode with
Mesa git, and I am
trying to trace the problem. Mesa seems to be having trouble in
GarbageCollectDRIDrawables().
Basically, the garbage collector finds something in the hash table, calls the
object's
pdraw->driDr
Hi,
Recently, World of Warcraft has been crashing for me in OpenGL mode with an
X-protocol error.
Basically, an attempt to create a GLX context was returning an error from a
previous attempt to
destroy one. The following patch fixes the problem for me:
Cheers,
Chris
diff --git a/src/glx/x11/gl
--- Jerome Glisse <[EMAIL PROTECTED]> wrote:
> > X Error of failed request: BadValue (integer parameter out of range for
> > operation)
> > Major opcode of failed request: 146 (XFree86-DRI)
> > Minor opcode of failed request: 8 ()
> > Value in failed request: 0x341
> > Serial numbe
--- Jerome Glisse <[EMAIL PROTECTED]> wrote:
> This might be related to lastest dri interface change.
Wine is failing with the error:
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 146 (XFree86-DRI)
Minor opcode of failed
--- Jerome Glisse <[EMAIL PROTECTED]> wrote:
> This might be related to lastest dri interface change. Can you try if
> recompiling xserver (from git)
> against mesa git works with lastest libGL and r200 dri driver.
The problem with that is that not only is this my main box (which means that I
ne
Hi,
The latest git Mesa is now giving me this error when trying to run Warcraft
under Wine. Switching
back to an earlier libGL.so.1.2 and r200_dri.so combination fixes the problem.
I have tried
recompiling Wine from scratch as well, to no avail.
X Error of failed request: BadValue (integer par
--- Chris Rankin <[EMAIL PROTECTED]> wrote:
> The two errors I am now getting from the r200's InitDriver are:
>
> radeonCreateScreen: drmMap failed for GART texture area
> libGL warning: 3D driver returned no fbconfigs.
> libGL error: InitDriver failed
> libGL error:
The two errors I am now getting from the r200's InitDriver are:
radeonCreateScreen: drmMap failed for GART texture area
libGL warning: 3D driver returned no fbconfigs.
libGL error: InitDriver failed
libGL error: reverting to (slow) indirect rendering
and
libGL error: drmMap of framebuffer failed
Hi,
I have just updated my Mesa installation to the latest from git, and suddenly
Wine is having
trouble. (Even winecfg is complaining!) Basically, drmMap is failing during the
R200's InitDriver,
and this is causing Wine to switch to indirect rendering. However, bizarrely,
glxinfo still says
th
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> shouldn't:
> - if ( !t || t->base.totalSize == 0 )
> + if ( !t || t->base.totalSize == 0 | t->image_override )
> be
> + if ( !t || t->base.totalSize == 0 || t->image_override )
Ouch, yes. Fixed now, thanks.
> You'll need a fairly recent (post 1.
OK, here it is - the final version. Now given that I am running Fedora 7 at the
moment, exactly
what will I need to update in order to test it?
Are there any "official" Xorg packages that I will need to grab and compile, or
is everything
still unreleased from git repositories?
Cheers,
Chris
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > diff --git a/src/mesa/drivers/dri/r200/r200_texmem.c
> > b/src/mesa/drivers/dri/r200/r200_texmem.c
> > index d926313..a5687a5 100644
> > --- a/src/mesa/drivers/dri/r200/r200_texmem.c
> > +++ b/src/mesa/drivers/dri/r200/r200_texmem.c
> > @@ -490,11
Hi,
Here's revision number two of my accelerated TFP patch for the R200. It
compiles and doesn't do
"nasty things" to Fedora 7, so the SetTexOffset function hasn't been executed
but everything else
seems OK...
Cheers,
Chris
___
Hi,
I've just dug this patch up from my hard drive; it is trying to add accelerated
TFP support to the
R200 driver. I am only running this patch with the Xorg 1.3 server at the
moment and so while I'm
sure it hasn't broken anything, I suspect that it's not actually doing anything
;-). Could som
On Mon, 2007-06-18 at 20:57 +0100, Chris Rankin wrote:
>
> Could someone help me translate these texture format constants into something
> R200-compatible,
> please?
>
> R300_EASY_TX_FORMAT(X, Y, Z, W, W8Z8Y8X8)
> R300_EASY_TX_FORMAT(X, Y, Z, ONE, W8Z8Y8X8)
> R300_EAS
Hi,
Is the stex3d demo supposed to work correctly with a radeon R100 video card?
And what is it
supposed to look like when it does work? Surely not like this (animated...)?
Cheers,
Chris
___
Yahoo! Answers - Got a question? Someone
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > The GLXFBConfig error (AIGLX off, indirect rendering) *is* happening in
> > git-mesa, BTW, because
> > that is what compiz is linked against.
>
> That hardly matters with indirect rendering.
My point is that compiz is falling over in the git libGL
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> Possibly, but more likely the old 3D driver.
Actually, that would be both the r200_dri and radeon_dri 3D drivers, since 2
machines are
affected.
> > In which case, turning AIGLX off should result in more than a blank
> > white screen. Correct?
>
>
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> So yes, compiz isn't actually using the 3D driver from Mesa git.
I see. But in that case, my X server is standard FC6 its Mesa 6.5.1 R200
support... unless the
git-Mesa version of libGL.so.1.2 that compiz is compiled against is affecting
things?
BT
Hi,
I have two machines running FC5 but with XOrg packages from FC6. One machine
has a Radeon 9200 and
the other has Radeon 7000 video cards, and both are using the git Mesa drivers.
However, I cannot
get compiz running on either of these machines:
- If I enable AIGLX and run compiz with indire
--- Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Not likely, these are classic symptoms of a gpu lockup (including the
> full lockup when trying to kill the dri client), and I doubt it's due to
> miscompilation. More likely an ordinary driver bug (and if somehow
> wine/WoW really do such odd t
--- Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> You may have a point but I fail to see why it would make any difference
> since the return value is never used currently anyway. Maybe you just
> got lucky.
Hmm, it was a very repeatable event - I don't think I'm *that* lucky. However,
maybe "
--- Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> > Also, I have managed to enable GL_ATI_fragment_shader by increasing
> > the number of texture units to 6
> Unless you're using a old driver version, 6 is the default since quite
> some time (5 months) so you don't have to do anything.
Heh, Fed
--- Brian Paul <[EMAIL PROTECTED]> wrote:
> For the GL_PROGRAM_UNDER_NATIVE_LIMITS_ARB query?
>
> I guess it should return GL_TRUE if there's no actual program.
>
> The attached patch should fix that.
> > Index: r200_vertprog.c
> ==
Hi,
I have just tried to run the Mesa demo apps "pointblast" and "spriteblast",
with the following
results:
$ ./pointblast
libGL warning: 3D driver claims to not support visual 0x4b
Mesa: CPU vendor: GenuineIntel
Mesa: CPU name: Intel(R) Xeon(TM) CPU 2.66GHz
Mesa: MMX cpu detec
BTW, this is what glxinfo says about my display. Notice the confusion about
visual 0x4b.
$ glxinfo
name of display: :0.0
libGL warning: 3D driver claims to not support visual 0x4b
Mesa: CPU vendor: GenuineIntel
Mesa: CPU name: Intel(R) Xeon(TM) CPU 2.66GHz
Mesa: MMX cpu detected
--- 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 called the
r20
--- 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()?
Cheers,
Chris
Chris Rankin wrote:
> I'm trying to find where the Parameters pointer is initialised.
--- Brian Paul <[EMAIL PROTECTED]> wrote:
> That normally happens when the program string is parsed/compiled.
>
> It may be that the GL_PROGRAM_UNDER_NATIVE_LIMITS_ARB query
--- Brian Paul <[EMAIL PROTECTED]> wrote:
> If the problem is deeper, I'll need a stack trace at least. Or
> someone with an r200 card will have to reproduce the problem and look
> into it.
Hmm, a large anvil has just dropped on my head... ;-).
Anyway, a slightly more precise description of wh
--- 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 several other places that a
Hi,
I found this issue in the Mesa 6.5.1-CVS20060818 code (courtesy of FC6):
In the r200_translate_vertex_program() function, in
src/mesa/drivers/dri/r200/r200_vertprog.c,
there are the following lines (about line 545):
...
vp->pos_end = 0;
mesa_vp->Base.NumNativeInstructions = 0;
mesa
82 matches
Mail list logo
