[Mesa-dev] [Bug 29276] [r300g][regression] 0ad game no longer starts
https://bugs.freedesktop.org/show_bug.cgi?id=29276 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Fabio Pedretti fabio@libero.it 2010-08-03 00:05:20 PDT --- This was fixed with 1f1928db001527c3dcf1d78d6a5d2ef8f519327b . -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29370] New: Crash when trying to enable 3D with KMS/DRI2
https://bugs.freedesktop.org/show_bug.cgi?id=29370 Summary: Crash when trying to enable 3D with KMS/DRI2 Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: GLX AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: rea...@gmail.com KWin crashes when trying to activate OpenGL desktop effects. I do not know if bug 29181 is related; could be. I'm on Mesa git master, kernel 2.6.35 using Radeon KMS, xorg-server 1.8.2, xf86-video-ati git master, Radeon HD4870. This is the backtrace: Application: KWin (kwin), signal: Segmentation fault [KCrash Handler] #6 dri2InvalidateBuffers (dpy=value optimized out, drawable=value optimized out) at dri2_glx.c:643 #7 0x003008c5106d in dri2SwapBuffers (pdraw=value optimized out, target_msc=value optimized out, divisor=value optimized out, remainder=value optimized out) at dri2_glx.c:510 #8 0x00307f6c9dc7 in KWin::SceneOpenGL::flushBuffer (this=value optimized out, mask=value optimized out, damage=value optimized out) at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95/kwin/scene_opengl.cpp:831 #9 0x00307f6cace6 in KWin::SceneOpenGL::paint (this=value optimized out, damage=value optimized out, toplevels=value optimized out) at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95/kwin/scene_opengl.cpp:761 #10 0x00307f6b4d1f in KWin::Workspace::performCompositing (this=value optimized out) at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95/kwin/composite.cpp:454 #11 0x00307f63677d in KWin::Workspace::qt_metacall (this=value optimized out, _c=value optimized out, _id=value optimized out, _a=value optimized out) at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95_build/kwin/workspace.moc:583 #12 0x003009f7db1f in QMetaObject::activate (sender=value optimized out, m=value optimized out, local_signal_index=value optimized out, argv=value optimized out) at kernel/qobject.cpp:3272 #13 0x003009f778d9 in QObject::event (this=value optimized out, e=value optimized out) at kernel/qobject.cpp:1175 #14 0x0030133b031c in QApplicationPrivate::notify_helper (this=value optimized out, receiver=value optimized out, e=value optimized out) at kernel/qapplication.cpp:4389 #15 0x0030133b5e8d in QApplication::notify (this=value optimized out, receiver=value optimized out, e=value optimized out) at kernel/qapplication.cpp:4270 #16 0x00301463a196 in KApplication::notify (this=value optimized out, receiver=value optimized out, event=value optimized out) at /var/tmp/portage/kde-base/kdelibs-4.4.95/work/kdelibs-4.4.95/kdeui/kernel/kapplication.cpp:309 #17 0x003009f65f3b in QCoreApplication::notifyInternal (this=value optimized out, receiver=value optimized out, event=value optimized out) at kernel/qcoreapplication.cpp:732 #18 0x003009f950f2 in QCoreApplication::sendEvent (this=value optimized out) at kernel/qcoreapplication.h:215 #19 QTimerInfoList::activateTimers (this=value optimized out) at kernel/qeventdispatcher_unix.cpp:602 #20 0x003009f952bc in QEventDispatcherUNIX::processEvents (this=value optimized out, flags=value optimized out) at kernel/qeventdispatcher_unix.cpp:923 #21 0x0030134613fd in QEventDispatcherX11::processEvents (this=value optimized out, flags=value optimized out) at kernel/qeventdispatcher_x11.cpp:152 #22 0x003009f64c92 in QEventLoop::processEvents (this=value optimized out, flags=value optimized out) at kernel/qeventloop.cpp:149 #23 0x003009f65074 in QEventLoop::exec (this=value optimized out, flags=value optimized out) at kernel/qeventloop.cpp:201 #24 0x003009f690cb in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1009 #25 0x00307f652d8d in kdemain (argc=value optimized out, argv=value optimized out) at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95/kwin/main.cpp:531 #26 0x00300041ebbd in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=) at libc-start.c:226 #27 0x004006c9 in _start () -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] 7.8 patches from master
Hi all, I needed a fix to 7.8.2 which was only on master, so I scanned master for all applicable commits and attempted to cherry-pick them to 7.8: git://people.freedesktop.org/~tfogal/mesa http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8 If a commit didn't cherry-pick automagically, it was dropped; I didn't make any effort to do even simple/obvious merging. Any chance those could be pushed to the official 7.8? -tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl2: optimizing unused struct assignments
Hi,
Currently GLSL2 optimizer can't remove assignments to struct members that
are never used. After inlining, the struct is often not passed to any other
functions as a whole; and some assignments to the members might be useless.
For example, in this fragment shader assignment to s.unused could be
optimized away. I guess then whole structure (of which only s.used is left)
could be replaced with just a float temporary:
struct foo {
float used;
float unused;
};
void main() {
float f = 1.0;
foo s;
s.used = f;
s.unused = f;
gl_FragColor = vec4(s.used);
}
Right now GLSL2 optimizer optimizes the above into this (GLSL output):
struct foo {
float used;
float unused;
};
void main ()
{
foo s;
s .used = 1.00;
s .unused = 1.00;
gl_FragColor = s .used .;
}
From the code, it seems that ir_variable_refcount only tracks references to
whole variables (in this case, whole struct), and not to individual
members. Any quick ideas / pitfalls how that can be extended, before I try
to figure it out myself?
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 7.8 patches from master
On 08/02/2010 11:42 PM, tom fogal wrote: Hi all, I needed a fix to 7.8.2 which was only on master, so I scanned master for all applicable commits and attempted to cherry-pick them to 7.8: git://people.freedesktop.org/~tfogal/mesa http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8 If a commit didn't cherry-pick automagically, it was dropped; I didn't make any effort to do even simple/obvious merging. Any chance those could be pushed to the official 7.8? Axes, Henri and Macij should double-check their patches but I'm OK with the rest. Though, I think there are few more of my commits that I tagged with 7.8 candidate. I'd cherry-pick those before doing another 7.8.x release. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium bound checking patch broke r600g in weird way
On 08/02/2010 04:49 PM, keith whitwell wrote: On Mon, Aug 2, 2010 at 3:53 PM, Brian Paulbri...@vmware.com wrote: On 08/01/2010 01:55 AM, Chia-I Wu wrote: On Sat, Jul 31, 2010 at 7:10 AM, Zack Rusinza...@vmware.comwrote: On Friday 30 July 2010 17:51:21 Jakob Bornecrantz wrote: On 30 jul 2010, at 14.02, Jakob Bornecrantz wrote: On 30 jul 2010, at 13.32, Brian Paul wrote: On 07/30/2010 12:38 PM, Jerome Glisse wrote: Hi Brian, I am facing a strange segfault with r600g on top of lastest git, git bisect pointed to gallium: implement bounds checking for constant buffers My feeling is that it should only affect software pipeline but somehow r600g seem to take different path now, attached if full but i can't make much sense out of it, do you have a clue on what might went wrong ? I took a quick look but didn't find anything. Maybe try a make clean and rebuild just in case? I'm getting the same with swrastg on in 32bit VM, git clean -fdx:ed even. Me and Jerome tracked it down to the SSE code generated by the tgsi runtime. Exporting GALLIUM_NOSSE avoids the bug. I'm guessing you are either using LLVM or 64bit which doesn't have SSE codegen. I am having this warning draw/draw_vs_sse.c: In function ‘draw_create_vs_sse’: draw/draw_vs_sse.c:172: warning: assignment from incompatible pointer type It seems the prototype of vs_sse_run_linear was not updated in the commit and the function body is accessing the wrong arguments. Dave Airlie fixed this and it seems to resolve the issue (I just tesed with and without Dave's fix on 32-bit and it worked for me). We actually talked about removing the SSE code from draw. We have the interpreted paths (safe and easier to debug) and the LLVM paths (for performance) and the no one is too keen to maintain the SSE code. Unless someone would like to maintain the SSE paths if I'll have a bit of time I'm probably going to remove them next week. They'll be still in the git history if someone will ever want to bring them back but right now they tend to crash a bit (like in this case) which is more trouble than it's worth. Yeah, that sounds good. This is not the first time (#28752) the SSE path gives weird bugs. I'd prefer to keep the SSE code for now. It's sometimes useful for me when I'm debugging things to do comparisons between SSE and the TGSI interpreter. The code is working fine again. I'm sorry my change caused such a commotion. I was in a hurry on Friday and just didn't test on 32-bit. Would comparing between llvm and the interpreter work as well for you Brian? Well, when switching to LLVM, more than just the shader code is brought into play so it's not quite the same. What about keeping the SSE code but hiding it behind an option and making LLVM the default? If we want to make GALLIUM_NOSSE default to 1, that's OK. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 7.8 patches from master
On 3 August 2010 15:52, Brian Paul bri...@vmware.com wrote: Axes, Henri and Macij should double-check their patches but I'm OK with the If that's a64b14fdcfdc045e027c4d81e0add1a85e381619 and b132401075bd9c358c30211a0b364699ab6f7463, I think those should be safe enough. Note that passing -x to git cherry-pick will mention the commit something was cherry picked from in the commit log. As for other commits, 2fdff50999825f5698f1f7f88565162f39227b2f, 7ba75d11cff09642f8c3133ec39382b25adb8711 and 85af7dcd0e4d33ac85b15cb522d6949686674e27 should be safe as well, but I guess it depends on how Alex feels about those. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH-RFC] draw: Rewrite primitive decomposer
On Tue, Aug 3, 2010 at 11:41 PM, Chia-I Wu olva...@gmail.com wrote:
On Tue, Aug 3, 2010 at 9:40 PM, Zack Rusin za...@vmware.com wrote:
On Tuesday 03 August 2010 01:34:46 Chia-I Wu wrote:
On Tue, Aug 3, 2010 at 6:48 AM, Zack Rusin za...@vmware.com wrote:
On Monday 02 August 2010 12:33:50 Chia-I Wu wrote:
While studying the draw module, I noticed that multiple primitive
decomposers exist: draw_pt_vcache_tmp.h, draw_gs_tmp.h,
draw_so_emit_tmp.h, and draw_pt_decompose.h. The differences between
them are small, yet some of them support primitive modes that others
don't.
Yes, that's because they all operate on a different set of primitives and
presence of any of the others should result in an assert since it
signifies that something went seriously wrong.
draw_pt_vcache_tmp.h needs to handle primitive modes with adjacency. When
GS is not active, draw_pt_decompose.h also needs to handle them.
I'm not sure if should, if adjacency primitives are set there should always
be
a gs and if not we should set a pass-through gs should which just emits
triangles.
There is no pass-through GS right now, but it is something I'd like to look
into after this change (and some tuning work). It should be required by the
non-pipeline path. Besides, as GS may output more vertices than its input, it
may be a problem if the number of output vertices exceeds vbuf_render's limit.
I'd like to see if they can be solved altogether.
With
OpenGL, GS never sees QUADS or POLYGON; Stream output never sees those
modes with adjacency.
Great.
There is FUNC_ENTER that is used to insert arbitrary code before the
decompose loop. It is used by some decomposers to add assertions. One
way is to use it to insert assertions like
if (mode == GL_QUADS || mode == GL_POLYGON /* || ... */) {
assert(!unexpected primitve type);
return;
}
That sounds good.
As for PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY, the GS decomposer does not
seem to follow the vertex ordering of GL_TRIANGLE_STRIP_ADJACENCY. I
write that part from scratch. I am not 100% sure here as I don't have
a test case to verify. It would be great if someone can clarify.
That's very vague, what's not right? The only thing I see in the old code
is that we possibly flip the first and second adjacency vertex.
Sorry, I was not clear here. It should be easier to describe with an
example.
When there are 8 vertices, the two decomposed triangles should be
TRI_ADJ(0, 1, 2, 6, 4, 3);
TRI_ADJ(4, 0, 2, 5, 6, 7);
while the old code would emit
TRI_ADJ(0, 1, 2, 3, 4, 5);
TRI_ADJ(2, 5, 6, 3, 4, 7);
(Table 2.4 of glspec33.core.20100311.pdf)
Ah, I see, yea, that's different from D3D:
http://msdn.microsoft.com/en-us/library/bb205124(VS.85).aspx
please keep what's in there right now until we figure out the best way to
switch that decomposition based on the api. The GL semantics look pretty
messed up to me, why would 4 be a leading vertex twice? (for i=1 and i=2)
I don't think the current behavior is correct for D3D, if I understand the
diagram correctly. The difference between D3D and OpenGL seems to be only in
the provoking conventions. In the diagram, there are 14 vertices which will
generate 5 triangles
vertices adjacent verts
i=0 0,2,4 1,6,3
i=1 2,4,6 0,8,5
i=2 4,6,8 2,10,7
i=3 6,8,10 4,12,9
i=4 8,10,12 6,13,11
To have the correct winding direction, we should swap the vertices when i is
odd.
If D3D provoking convention is used, the last two vertices should be swapped
so
that the provoking (leading) vertices are 0, 2, 4, and so on respectively. As
a result of the swap, the first and the last adjacent vertices should also be
swapped. This gives
vertices adjacent verts
i=0 0,2,4 1,6,3
i=1 2,6,4 5,8,0
i=2 4,6,8 2,10,7
i=3 6,10,8 9,12,4
i=4 8,10,12 6,13,11
which is exactly the diagram in the link.
If OpenGL provoking convention is used, the first two vertices should be
swapped so that the provoking vertex are 4, 6, 8, and so on respectively. As
a
result of the swap, the first and the last adjacent vertices should also be
^^
It should be the last two. Copy-and-paste error. Sorry.
swapped. This gives
vertices adjacent verts
i=0 0,2,4 1,6,3
i=1 4,2,6 0,5,8
i=2 4,6,8 2,10,7
i=3 8,6,10 4,9,12
i=4 8,10,12 6,13,11
which is Table 2.4 in OpenGL 3.3 core profile.
--
o...@lunarg.com
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl2: optimizing unused struct assignments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aras Pranckevicius wrote:
Hi,
Currently GLSL2 optimizer can't remove assignments to struct members
that are never used. After inlining, the struct is often not passed to
any other functions as a whole; and some assignments to the members
might be useless. For example, in this fragment shader assignment to
s.unused could be optimized away. I guess then whole structure (of which
only s.used is left) could be replaced with just a float temporary:
struct foo {
float used;
float unused;
};
void main() {
float f = 1.0;
foo s;
s.used = f;
s.unused = f;
gl_FragColor = vec4(s.used);
}
Right now GLSL2 optimizer optimizes the above into this (GLSL output):
struct foo {
float used;
float unused;
};
void main ()
{
foo s;
s .used = 1.00;
s .unused = 1.00;
gl_FragColor = s .used .;
}
From the code, it seems that ir_variable_refcount only tracks references
to whole variables (in this case, whole struct), and not to individual
members. Any quick ideas / pitfalls how that can be extended, before I
try to figure it out myself?
I believe the plan is to eventually break structures and arrays that are
not variably indexed into individual variables. Your structure above
would be broken into s_used and s_unused. The existing dead code paths
would take care of s_unused. We'll need to do this break-up anyway to
do proper register assignment.
We'll have similar issue with code like:
uniform vec4 angles;
void main()
{
vec4 v;
v.x = sin(angles.x);
v.y = cos(angles.y);
v.z = tan(angles.z);
v.w = 1/tan(angles.w);
gl_Position = v.xyxy;
}
In this case v.zw is never used, and the (expensive) assignments should
be killed.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxYOXoACgkQX1gOwKyEAw+KMwCfU1z85ukV/HTvSsq3igqoRznG
xC8AnjwjTtdb1glbmhzkNgARa3aZz/VA
=Qerv
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH-RFC] draw: Rewrite primitive decomposer
On Tuesday 03 August 2010 11:41:02 Chia-I Wu wrote: On Tue, Aug 3, 2010 at 9:40 PM, Zack Rusin za...@vmware.com wrote: I'm not sure if should, if adjacency primitives are set there should always be a gs and if not we should set a pass-through gs should which just emits triangles. There is no pass-through GS right now, but it is something I'd like to look into after this change (and some tuning work). Great. It should be required by the non-pipeline path. Besides, as GS may output more vertices than its input, it may be a problem if the number of output vertices exceeds vbuf_render's limit. I'd like to see if they can be solved altogether. Sounds good. I don't think the current behavior is correct for D3D, if I understand the diagram correctly. It is for data vertices. The question is, as I mentioned in the first email, whether the two following adjacency vertices need to be swapped. I had a testcase for this stuff but I don't remember if I tested adjacency vertex placement or whether that was a typo. The difference between D3D and OpenGL seems to be only in the provoking conventions. In the diagram, there are 14 vertices which will generate 5 triangles vertices adjacent verts i=0 0,2,4 1,6,3 or 1,5,3 or 1,3,5 i=1 2,4,6 0,8,5 or 5,7,3 or 5,3,7 and so on. If you have a testcase that shows which way it is, great, lets change it (aka fix it). Otherwise I'm just not too excited about changing code that was working with the (corny) testcases it had for something without any. z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 7.8 patches from master
On Tue, Aug 3, 2010 at 10:41 AM, Henri Verbeet hverb...@gmail.com wrote: On 3 August 2010 15:52, Brian Paul bri...@vmware.com wrote: Axes, Henri and Macij should double-check their patches but I'm OK with the If that's a64b14fdcfdc045e027c4d81e0add1a85e381619 and b132401075bd9c358c30211a0b364699ab6f7463, I think those should be safe enough. Note that passing -x to git cherry-pick will mention the commit something was cherry picked from in the commit log. As for other commits, 2fdff50999825f5698f1f7f88565162f39227b2f, 7ba75d11cff09642f8c3133ec39382b25adb8711 and 85af7dcd0e4d33ac85b15cb522d6949686674e27 should be safe as well, but I guess it depends on how Alex feels about those. Most of these commit ids are invalid. Maybe local commits? Here's my rough list for 7.8: fef9b532cd1631cc53056b9eba4369d1310b88df eb4dc547885994cc7961f7996c33ff484f664964 04a148629f565f556d0b6e7465f8a19921eed7af 12172071b5f5cb7f475a20ead8a65eb12fa94737 1f7bc87391bc42eb9003020b7654e985494c6e61 1ec492a366e236569dc68f4de32e641c88cbcd63 1bf75a921bcd11dfdc389f490081d83ab536fc58 8744c36ea4f32124e91d26cab2bb76529f6eecf1 5552dffa39d1401d20df4696540f5de2e8c852ea 71646528da5355468be8b52be662d0afd49a38f1 51c438feb765cf03d1a6448295e6c62be61a5e56 2bd69080a229fb81685234a08922dffbcecdfe95 2fdff50999825f5698f1f7f88565162f39227b2f ad24ea37bb0cef7b383bb38e31466b6bb1f7fce6 72e6a1e72f21653295165320fbca6961eddc9eb3 ba03a0b5ba73bc8e79d0ffa6d1da623544716f74 0a7803cbaca13033d9ed31ef33f59efa913fbfce 646d2e9fbc41bf49075013009e9583bec4a51168 9b3bf392e1af72d29afa0804260cac4d8ffe24e1 This one needs to go in as well, but it touches some files that are not available in the 7.8 branch; however, those parts of the patch can be ignored for 7.8. d6a5f94ea4d03b05c434fcad125d1f9c50c638e8 Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 7.8 patches from master
On Tue, Aug 3, 2010 at 12:21 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Aug 3, 2010 at 10:41 AM, Henri Verbeet hverb...@gmail.com wrote: On 3 August 2010 15:52, Brian Paul bri...@vmware.com wrote: Axes, Henri and Macij should double-check their patches but I'm OK with the If that's a64b14fdcfdc045e027c4d81e0add1a85e381619 and b132401075bd9c358c30211a0b364699ab6f7463, I think those should be safe enough. Note that passing -x to git cherry-pick will mention the commit something was cherry picked from in the commit log. As for other commits, 2fdff50999825f5698f1f7f88565162f39227b2f, 7ba75d11cff09642f8c3133ec39382b25adb8711 and 85af7dcd0e4d33ac85b15cb522d6949686674e27 should be safe as well, but I guess it depends on how Alex feels about those. Most of these commit ids are invalid. Maybe local commits? Here's my rough list for 7.8: fef9b532cd1631cc53056b9eba4369d1310b88df eb4dc547885994cc7961f7996c33ff484f664964 04a148629f565f556d0b6e7465f8a19921eed7af 12172071b5f5cb7f475a20ead8a65eb12fa94737 1f7bc87391bc42eb9003020b7654e985494c6e61 1ec492a366e236569dc68f4de32e641c88cbcd63 1bf75a921bcd11dfdc389f490081d83ab536fc58 8744c36ea4f32124e91d26cab2bb76529f6eecf1 5552dffa39d1401d20df4696540f5de2e8c852ea 71646528da5355468be8b52be662d0afd49a38f1 51c438feb765cf03d1a6448295e6c62be61a5e56 2bd69080a229fb81685234a08922dffbcecdfe95 2fdff50999825f5698f1f7f88565162f39227b2f ad24ea37bb0cef7b383bb38e31466b6bb1f7fce6 72e6a1e72f21653295165320fbca6961eddc9eb3 ba03a0b5ba73bc8e79d0ffa6d1da623544716f74 0a7803cbaca13033d9ed31ef33f59efa913fbfce 646d2e9fbc41bf49075013009e9583bec4a51168 9b3bf392e1af72d29afa0804260cac4d8ffe24e1 Plus, the following which are already in your tree: a88dd2d39a0603e222aca5f5f6eb92db9c1ac77d 61122b526c06a814537cdf58bd0136c7b5085f25 cca4468100eb6a942aa128c5f27f6637b3828d61 This one needs to go in as well, but it touches some files that are not available in the 7.8 branch; however, those parts of the patch can be ignored for 7.8. d6a5f94ea4d03b05c434fcad125d1f9c50c638e8 Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 7.8 patches from master
On 3 August 2010 18:21, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Aug 3, 2010 at 10:41 AM, Henri Verbeet hverb...@gmail.com wrote: On 3 August 2010 15:52, Brian Paul bri...@vmware.com wrote: Axes, Henri and Macij should double-check their patches but I'm OK with the If that's a64b14fdcfdc045e027c4d81e0add1a85e381619 and b132401075bd9c358c30211a0b364699ab6f7463, I think those should be safe enough. Note that passing -x to git cherry-pick will mention the commit something was cherry picked from in the commit log. As for other commits, 2fdff50999825f5698f1f7f88565162f39227b2f, 7ba75d11cff09642f8c3133ec39382b25adb8711 and 85af7dcd0e4d33ac85b15cb522d6949686674e27 should be safe as well, but I guess it depends on how Alex feels about those. Most of these commit ids are invalid. Maybe local commits? a64b14fdcfdc045e027c4d81e0add1a85e381619 and b132401075bd9c358c30211a0b364699ab6f7463 are from http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8, but I did indeed mess up 7ba75d11cff09642f8c3133ec39382b25adb8711 and 85af7dcd0e4d33ac85b15cb522d6949686674e27. Should have been 1f7bc87391bc42eb9003020b7654e985494c6e61 and 1ec492a366e236569dc68f4de32e641c88cbcd63, both of which are already on your list. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH-RFC] draw: Rewrite primitive decomposer
On Wed, Aug 4, 2010 at 12:03 AM, Zack Rusin za...@vmware.com wrote: On Tuesday 03 August 2010 11:41:02 Chia-I Wu wrote: On Tue, Aug 3, 2010 at 9:40 PM, Zack Rusin za...@vmware.com wrote: I'm not sure if should, if adjacency primitives are set there should always be a gs and if not we should set a pass-through gs should which just emits triangles. There is no pass-through GS right now, but it is something I'd like to look into after this change (and some tuning work). Great. It should be required by the non-pipeline path. Besides, as GS may output more vertices than its input, it may be a problem if the number of output vertices exceeds vbuf_render's limit. I'd like to see if they can be solved altogether. Sounds good. I don't think the current behavior is correct for D3D, if I understand the diagram correctly. It is for data vertices. The question is, as I mentioned in the first email, whether the two following adjacency vertices need to be swapped. I had a testcase for this stuff but I don't remember if I tested adjacency vertex placement or whether that was a typo. The difference between D3D and OpenGL seems to be only in the provoking conventions. In the diagram, there are 14 vertices which will generate 5 triangles vertices adjacent verts i=0 0,2,4 1,6,3 or 1,5,3 or 1,3,5 i=1 2,4,6 0,8,5 or 5,7,3 or 5,3,7 I see your point. There are more than one way to interpret the diagram. Now I am curious if the diagram is all the D3D documents have for triangle strip with adjacency? and so on. If you have a testcase that shows which way it is, great, lets change it (aka fix it). Otherwise I'm just not too excited about changing code that was working with the (corny) testcases it had for something without any. Sure. Where can I find the test cases, if they are public? -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29370] Crash when trying to enable 3D with KMS/DRI2
https://bugs.freedesktop.org/show_bug.cgi?id=29370 --- Comment #1 from Niels Ole Salscheider niels_...@salscheider-online.de 2010-08-03 10:19:41 PDT --- This bug is the same I reported on the mailing list last week and it is related to bug 29181. Nevertheless, Kristian Høgsberg told me that it should not return NULL since there should always be a __GLXDRIdrawable in the hash table. dri2_glx.c, line 508ff says the following: /* Old servers don't send invalidate events */ if (!pdp-invalidateAvailable) dri2InvalidateBuffers(dpyPriv-dpy, pdraw-drawable); I am not sure if xorg-server 1.8.2 sends invalidate events which might conflict with this function call - but then pdp-invalidateAvailable should not be false... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 7.8 patches from master
Dnia wtorek 03 sierpnia 2010 o 18:23:37 Alex Deucher napisał(a): On Tue, Aug 3, 2010 at 12:21 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Aug 3, 2010 at 10:41 AM, Henri Verbeet hverb...@gmail.com wrote: On 3 August 2010 15:52, Brian Paul bri...@vmware.com wrote: Axes, Henri and Macij should double-check their patches but I'm OK with the If that's a64b14fdcfdc045e027c4d81e0add1a85e381619 and b132401075bd9c358c30211a0b364699ab6f7463, I think those should be safe enough. Note that passing -x to git cherry-pick will mention the commit something was cherry picked from in the commit log. As for other commits, 2fdff50999825f5698f1f7f88565162f39227b2f, 7ba75d11cff09642f8c3133ec39382b25adb8711 and 85af7dcd0e4d33ac85b15cb522d6949686674e27 should be safe as well, but I guess it depends on how Alex feels about those. Most of these commit ids are invalid. Maybe local commits? Here's my rough list for 7.8: fef9b532cd1631cc53056b9eba4369d1310b88df eb4dc547885994cc7961f7996c33ff484f664964 04a148629f565f556d0b6e7465f8a19921eed7af 12172071b5f5cb7f475a20ead8a65eb12fa94737 1f7bc87391bc42eb9003020b7654e985494c6e61 1ec492a366e236569dc68f4de32e641c88cbcd63 1bf75a921bcd11dfdc389f490081d83ab536fc58 8744c36ea4f32124e91d26cab2bb76529f6eecf1 5552dffa39d1401d20df4696540f5de2e8c852ea 71646528da5355468be8b52be662d0afd49a38f1 51c438feb765cf03d1a6448295e6c62be61a5e56 2bd69080a229fb81685234a08922dffbcecdfe95 2fdff50999825f5698f1f7f88565162f39227b2f ad24ea37bb0cef7b383bb38e31466b6bb1f7fce6 72e6a1e72f21653295165320fbca6961eddc9eb3 ba03a0b5ba73bc8e79d0ffa6d1da623544716f74 0a7803cbaca13033d9ed31ef33f59efa913fbfce 646d2e9fbc41bf49075013009e9583bec4a51168 9b3bf392e1af72d29afa0804260cac4d8ffe24e1 Plus, the following which are already in your tree: a88dd2d39a0603e222aca5f5f6eb92db9c1ac77d 61122b526c06a814537cdf58bd0136c7b5085f25 cca4468100eb6a942aa128c5f27f6637b3828d61 This one needs to go in as well, but it touches some files that are not available in the 7.8 branch; however, those parts of the patch can be ignored for 7.8. d6a5f94ea4d03b05c434fcad125d1f9c50c638e8 Alex Hi, Ack for all my patches on the list plus these: 452a7d5a9d339db3326f33d464dce1a879ccc533 ba196a8318af6217fece3777ea038539fea4b415 addedd091e81907837b3aa0680b242b8fdbde7ef and these two but they have to go together: a68e8a4eaadfe2a1e4999d5e378c7d9fa99dc656 1a8a230a61289392e8300901dfabd7911799cbc3 Regards, Maciej Cencora ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29370] Crash when trying to enable 3D with KMS/DRI2
https://bugs.freedesktop.org/show_bug.cgi?id=29370 --- Comment #2 from Niels Ole Salscheider niels_...@salscheider-online.de 2010-08-03 11:53:20 PDT --- What happens to pdp in dri2CreateDisplay(Display * dpy), dri2_glx.c? This function sets pdp-invalidateAvailable but pdp is neither stored in a global variable nor is it returned by the function (just pdp-base and pdp-base does not contain a pointer to pdp, does it?). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29370] Crash when trying to enable 3D with KMS/DRI2
https://bugs.freedesktop.org/show_bug.cgi?id=29370
--- Comment #3 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2010-08-03
12:11:14 PDT ---
(In reply to comment #1)
This bug is the same I reported on the mailing list last week and it is
related
to bug 29181. Nevertheless, Kristian Høgsberg told me that it should not
return
NULL since there should always be a __GLXDRIdrawable in the hash table.
dri2_glx.c, line 508ff says the following:
/* Old servers don't send invalidate events */
if (!pdp-invalidateAvailable)
dri2InvalidateBuffers(dpyPriv-dpy, pdraw-drawable);
I am not sure if xorg-server 1.8.2 sends invalidate events which might
conflict
with this function call - but then pdp-invalidateAvailable should not be
false...
1.8.2 doesn't send invalidate events, so this call is correctly taken. Even if
it were taken erroneously, it wouldn't matter or cause these symptoms. Could
also be that something goes wrong inside
dri2InvalidateBuffers(Display *dpy, XID drawable)
{
__GLXDRIdrawable *pdraw =
dri2GetGlxDrawableFromXDrawableId(dpy, drawable);
struct dri2_screen *psc = (struct dri2_screen *) pdraw-psc;
struct dri2_drawable *pdp = (struct dri2_drawable *) pdraw;
when it calls dri2GetGlxDrawableFromXDrawableId() and that one returns an
invalid result.
However i tested mesa master with both 1.8.2 (no invalidate events) and master
(invalidate events) and it worked well. Didn't test with KWin though, so i
don't know.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] 7.8, round 2.
I prepared another 7.8 branch. * Used '-x' when cherry-picking * Grabbed a few more commits mentioned during discussion * Manually applied some patches I'm hopeful that there's no commits which aren't either in the set now or mentioned below, but please correct me if I'm wrong. Again, the branch is at: git://people.freedesktop.org/~tfogal/mesa http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8 I forced an update to redo this branch. Notes on specific commits: 5d0e136eff54a34258b5adaeda4cb267831e8234 1bbf803e3bc8eeabcc2c24b89bc30a30b2445c59 uniforms.c doesn't exist on 7.8. When I tracked it back to the original file, it appeared as if these had already been applied. (?) Brian: applied in 7dbfc2565e23fec69aa8082997fef48464429cef ? Brian, could I get an Ack? 3751e6e1fc385739022d0942b46e175632ad0d4b 41f66915ab3d052e0e2ef06000d6534eb7776ec6 Refactoring meant these couldn't be picked directly. I applied them manually with commits bcfd2534d24607e26b6afc832c3a64c72994bd30 and aca3e1307d19a615829d73e74c8939eb623e677e Brian, could I get an Ack? ba03a0b5ba73bc8e79d0ffa6d1da623544716f74 The patch could not be cherry-picked because it applied to a file that was refactored after 7.8. I hand-applied the patch to the old source file in 7a1c42ee208b316db4402d98dbf7c701a23f942f. I do not have any ATI hardware and have not tested this. Maciej, could I get an Ack? 3fde89e4395d260821f4e76a0fe36c265c148a73 This requires someone with knowledge of pipe_buffers/draw elems to do the merge (i.e.: not me.) Brian did the original work here. 4fd39a8d69cade6db5c4a0295a5f5f3014110b1c Needs someone w/ state tracker / renderbuffer knowledge to merge. Marek did the original work here. e393350904a48d332d832881af9549400194608c I merged this one myself (pay careful attention to it, please). Brian, could I get an Ack? I build-tested the OSMesa and xlib cfgs on Linux and OS X, via the autoconf build system. Seems fine. What'd I miss? Thanks, -tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH-RFC] draw: Rewrite primitive decomposer
On Tuesday 03 August 2010 12:56:41 Chia-I Wu wrote:
I see your point. There are more than one way to interpret the
diagram. Now I am curious if the diagram is all the D3D documents have
for triangle strip with adjacency?
As far as the public docs go I think that's it.
and so on. If you have a testcase that shows which way it is, great,
lets change it (aka fix it). Otherwise I'm just not too excited about
changing code that was working with the (corny) testcases it had for
something without any.
Sure. Where can I find the test cases, if they are public?
I've tested with a few proprietary demos/apps, but since I've implemented gs
in Mesa as well we can use that. You can put the attached files in
demos/src/glsl and compile it there. I never tested triangle strips with
adjacency in mesa but it seems to be at least rendering something (the
adjacency vertices are definitely flipped). Try glDrawArrays with different
values, e.g.
1) glDrawArrays(GL_TRIANGLE_STRIP_ADJACENCY_ARB, 0, 6);
2) glDrawArrays(GL_TRIANGLE_STRIP_ADJACENCY_ARB, 2, 6);
3) glDrawArrays(GL_TRIANGLE_STRIP_ADJACENCY_ARB, 4, 6);
4) glDrawArrays(GL_TRIANGLE_STRIP_ADJACENCY_ARB, 0, 8);
5) glDrawArrays(GL_TRIANGLE_STRIP_ADJACENCY_ARB, 2, 8);
6) glDrawArrays(GL_TRIANGLE_STRIP_ADJACENCY_ARB, 0, 10);
It'd be awesome if we had a piglit test for it, but right now anything that
with some manual testing looks like whatever proprietary NVIDIA/AMD drivers do
would be fine.
z
#include assert.h
#include string.h
#include stdio.h
#include stdlib.h
#include math.h
#define GL_GLEXT_PROTOTYPES
#include GL/glew.h
#include GL/glut.h
#include GL/glext.h
#include shaderutil.h
static const char *filename = tri-adj.geom;
static GLuint fragShader;
static GLuint vertShader;
static GLuint geoShader;
static GLuint program;
#define QUIT
struct Vertex
{
float position[4];
float color[4];
};
const struct Vertex vTri[10] = {
{ { -1.0f, -0.33f, 0.5f, 1.0f },//0
{ 1.0f, 0.0f, 0.0f, 1.0f } },
{ { -1.0f, 0.33f, 0.5f, 1.0f },//1
{ 0.0f, 1.0f, 0.0f, 1.0f } },
{ { -0.5f, 0.33f, 0.5f, 1.0f },//2
{ 0.0f, 0.0f, 1.0f, 1.0f } },
{ { -0.5f, -1.0f, 0.5f, 1.0f },//3
{ 1.0f, 1.0f, 0.0f, 1.0f } },
{ { 0.0f, -0.33f, 0.5f, 1.0f },//4
{ 0.0f, 0.0f, 0.0f, 1.0f } },
{ { 0.0f, 1.0f, 0.5f, 1.0f },//5
{ 0.5f, 0.5f, 0.0f, 1.0f } },
{ { 0.5f, 0.33f, 0.5f, 1.0f },//6
{ 0.0f, 1.0f, 0.0f, 1.0f } },
{ { 0.5f, -1.0f, 0.5f, 1.0f },//7
{ 1.0f, 0.0f, 1.0f, 1.0f } },
{ { 1.0f, -0.33f, 0.5f, 1.0f },//8
{ 1.0f, 1.0f, 0.0f, 1.0f } },
{ { 1.0f, 0.33f, 0.5f, 1.0f },//9
{ 1.0f, 0.0f, 1.0f, 1.0f } }
};
static void usage( char *name )
{
fprintf(stderr, usage: %s\n, name);
fprintf(stderr, \n );
}
static void load_and_compile_shader(GLuint shader, const char *text)
{
GLint stat;
glShaderSource(shader, 1, (const GLchar **) text, NULL);
glCompileShader(shader);
glGetShaderiv(shader, GL_COMPILE_STATUS, stat);
if (!stat) {
GLchar log[1000];
GLsizei len;
glGetShaderInfoLog(shader, 1000, len, log);
fprintf(stderr, tri-adj: problem compiling shader:\n%s\n, log);
exit(1);
}
}
static void read_shader(GLuint shader, const char *filename)
{
const int max = 100*1000;
int n;
char *buffer = (char*) malloc(max);
FILE *f = fopen(filename, r);
if (!f) {
fprintf(stderr, tri-adj: Unable to open shader file %s\n, filename);
exit(1);
}
n = fread(buffer, 1, max, f);
printf(tri-adj: read %d bytes from shader file %s\n, n, filename);
if (n 0) {
buffer[n] = 0;
load_and_compile_shader(shader, buffer);
}
fclose(f);
free(buffer);
}
static void check_link(GLuint prog)
{
GLint stat;
glGetProgramiv(prog, GL_LINK_STATUS, stat);
if (!stat) {
GLchar log[1000];
GLsizei len;
glGetProgramInfoLog(prog, 1000, len, log);
fprintf(stderr, Linker error:\n%s\n, log);
}
}
static void init(void)
{
static const char *fragShaderText =
void main() {\n
gl_FragColor = gl_Color;\n
}\n;
static const char *vertShaderText =
void main() {\n
gl_FrontColor = gl_Color;\n
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n
}\n;
static const char *geoShaderText =
#version 120\n
#extension GL_ARB_geometry_shader4 : enable\n
void main()\n
{\n
for(int i = 0; i gl_VerticesIn; ++i)\n
{\n
gl_FrontColor = gl_FrontColorIn[i];\n
gl_Position = gl_PositionIn[i];\n
EmitVertex();\n
}\n
}\n;
if (!ShadersSupported())
exit(1);
fragShader = glCreateShader(GL_FRAGMENT_SHADER);
load_and_compile_shader(fragShader, fragShaderText);
vertShader = glCreateShader(GL_VERTEX_SHADER);
load_and_compile_shader(vertShader, vertShaderText);
geoShader =
[Mesa-dev] [Bug 28658] [Gallium/DRI] Occasional Compiz Crashes
https://bugs.freedesktop.org/show_bug.cgi?id=28658 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Marek Olšák mar...@gmail.com 2010-08-03 15:18:32 PDT --- I've fixed a crash in st/dri. If you still experience any crashes, please reopen. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 7.8, round 2.
On 08/03/2010 01:32 PM, tom fogal wrote: I prepared another 7.8 branch. * Used '-x' when cherry-picking * Grabbed a few more commits mentioned during discussion * Manually applied some patches I'm hopeful that there's no commits which aren't either in the set now or mentioned below, but please correct me if I'm wrong. Again, the branch is at: git://people.freedesktop.org/~tfogal/mesa http://cgit.freedesktop.org/~tfogal/mesa/log/?h=7.8 I forced an update to redo this branch. Notes on specific commits: 5d0e136eff54a34258b5adaeda4cb267831e8234 1bbf803e3bc8eeabcc2c24b89bc30a30b2445c59 uniforms.c doesn't exist on 7.8. When I tracked it back to the original file, it appeared as if these had already been applied. (?) Brian: applied in 7dbfc2565e23fec69aa8082997fef48464429cef ? Brian, could I get an Ack? Yes, that change was already on the 7.8 branch. Acked-by: Brian Paul bri...@vmware.com 3751e6e1fc385739022d0942b46e175632ad0d4b 41f66915ab3d052e0e2ef06000d6534eb7776ec6 Refactoring meant these couldn't be picked directly. I applied them manually with commits bcfd2534d24607e26b6afc832c3a64c72994bd30 and aca3e1307d19a615829d73e74c8939eb623e677e Brian, could I get an Ack? Acked-by: Brian Paul bri...@vmware.com ba03a0b5ba73bc8e79d0ffa6d1da623544716f74 The patch could not be cherry-picked because it applied to a file that was refactored after 7.8. I hand-applied the patch to the old source file in 7a1c42ee208b316db4402d98dbf7c701a23f942f. I do not have any ATI hardware and have not tested this. Maciej, could I get an Ack? 3fde89e4395d260821f4e76a0fe36c265c148a73 This requires someone with knowledge of pipe_buffers/draw elems to do the merge (i.e.: not me.) Brian did the original work here. I don't have time right now to back-port that one to the 7.8 branch. The issue it fixes really doesn't happen much in practice anyway. 4fd39a8d69cade6db5c4a0295a5f5f3014110b1c Needs someone w/ state tracker / renderbuffer knowledge to merge. Marek did the original work here. e393350904a48d332d832881af9549400194608c I merged this one myself (pay careful attention to it, please). Brian, could I get an Ack? Acked-by: Brian Paul bri...@vmware.com I build-tested the OSMesa and xlib cfgs on Linux and OS X, via the autoconf build system. Seems fine. What'd I miss? Looks OK. Did you grab all the commits tagged with candidate for the 7.8 branch? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29370] Crash when trying to enable 3D with KMS/DRI2
https://bugs.freedesktop.org/show_bug.cgi?id=29370 --- Comment #4 from Nikos Chantziaras rea...@gmail.com 2010-08-03 20:53:42 PDT --- One thing I'd like to point out is that KDE with compositing is totally unusable right now at current Git master because UMS doesn't work either. KMS crashes due to the present bug, and UMS crashes because of bug 28181. So if a developer could install KDE4 and try to reproduce, that would be really awesome. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29393] R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Component|Drivers/DRI/R600|GLX AssignedTo|dri-de...@lists.freedesktop |mesa-...@lists.freedesktop. |.org|org CC||nbow...@draconx.ca --- Comment #4 from Alex Deucher ag...@yahoo.com 2010-08-03 21:21:23 PDT --- This looks like a glx bug rather than a driver bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
