Menu
▾
▴
mesa3d-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(10) |
Apr
(28) |
May
(41) |
Jun
(91) |
Jul
(63) |
Aug
(45) |
Sep
(37) |
Oct
(80) |
Nov
(91) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(48) |
Feb
(121) |
Mar
(126) |
Apr
(16) |
May
(85) |
Jun
(84) |
Jul
(115) |
Aug
(71) |
Sep
(27) |
Oct
(33) |
Nov
(15) |
Dec
(71) |
| 2002 |
Jan
(73) |
Feb
(34) |
Mar
(39) |
Apr
(135) |
May
(59) |
Jun
(116) |
Jul
(93) |
Aug
(40) |
Sep
(50) |
Oct
(87) |
Nov
(90) |
Dec
(32) |
| 2003 |
Jan
(181) |
Feb
(101) |
Mar
(231) |
Apr
(240) |
May
(148) |
Jun
(228) |
Jul
(156) |
Aug
(49) |
Sep
(173) |
Oct
(169) |
Nov
(137) |
Dec
(163) |
| 2004 |
Jan
(243) |
Feb
(141) |
Mar
(183) |
Apr
(364) |
May
(369) |
Jun
(251) |
Jul
(194) |
Aug
(140) |
Sep
(154) |
Oct
(167) |
Nov
(86) |
Dec
(109) |
| 2005 |
Jan
(176) |
Feb
(140) |
Mar
(112) |
Apr
(158) |
May
(140) |
Jun
(201) |
Jul
(123) |
Aug
(196) |
Sep
(143) |
Oct
(165) |
Nov
(158) |
Dec
(79) |
| 2006 |
Jan
(90) |
Feb
(156) |
Mar
(125) |
Apr
(146) |
May
(169) |
Jun
(146) |
Jul
(150) |
Aug
(176) |
Sep
(156) |
Oct
(237) |
Nov
(179) |
Dec
(140) |
| 2007 |
Jan
(144) |
Feb
(116) |
Mar
(261) |
Apr
(279) |
May
(222) |
Jun
(103) |
Jul
(237) |
Aug
(191) |
Sep
(113) |
Oct
(129) |
Nov
(141) |
Dec
(165) |
| 2008 |
Jan
(152) |
Feb
(195) |
Mar
(242) |
Apr
(146) |
May
(151) |
Jun
(172) |
Jul
(123) |
Aug
(195) |
Sep
(195) |
Oct
(138) |
Nov
(183) |
Dec
(125) |
| 2009 |
Jan
(268) |
Feb
(281) |
Mar
(295) |
Apr
(293) |
May
(273) |
Jun
(265) |
Jul
(406) |
Aug
(679) |
Sep
(434) |
Oct
(357) |
Nov
(306) |
Dec
(478) |
| 2010 |
Jan
(856) |
Feb
(668) |
Mar
(927) |
Apr
(269) |
May
(12) |
Jun
(13) |
Jul
(6) |
Aug
(8) |
Sep
(23) |
Oct
(4) |
Nov
(8) |
Dec
(11) |
| 2011 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: tom f. <tf...@al...> - 2010-03-10 00:33:44
|
George Sapountzis <gsa...@gm...> writes: > On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick <id...@fr...> wrote: > > George Sapountzis wrote: > > > >> When using libGL from mesa 7.7 and swrast_dri.so from getproc-test, > >> the extension string does contain GL_MESA_test_extension but the test > >> segfaults. > > > > There are a few places where this could break. > > > > - The generated dispatch stub function is wrong. > > - The dispatch offset used by the driver is wrong. > > - The dispatch remapping used by the driver is wrong. > > It turned out that there were two bugs in glapi. One with using > non-exec memory and the other with using an un-relocated function > template for entry-point generation. I put fixes at: > > http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-debug Some comments: e38a234.. shouldn't get merged as-is, right? I mean, there must be some sort of mesa_debug macro or similar, so that debug messages are configurable. ditto for d0b35e9. d6c973c is a strange patch; the additions to GLAPI_SOURCES seem unrelated to the patch itself. 977d5d: it seems like there should be some other way to disable this. I've been trying to make time to have these XMLs be exhaustive in their coverage of GL and GLX extensions, for example, which is good for other reasons. Most importantly: have you tested with mangled symbols (compile w/ USE_MGL_NAMESPACE defined)? It looks like the functions added in 682971c need #ifdef MANGLE cases. A few months back, I noticed some cases of doing function lookup without considering mangled symbols, but couldn't reproduce it in my setup. I think it had to do with loading the symbols from a DRI driver. It might have even been fine, i.e. a higher level scrubbed out the mangling. I guess I'm saying that if you tested mangling && it still works, great, `done' in my book :) Cheers, -tom |
|
From: George S. <gsa...@gm...> - 2010-03-10 00:29:49
|
On Wed, Mar 10, 2010 at 2:18 AM, George Sapountzis <gsa...@gm...> wrote: > > I also tested with libGL pretending to not know fbo extensions, the > fbo* demos and tests render correctly. I get a warning about an > invalid enum in RenderbufferStorageMultisample(target) but i don't > know where it comes from and it does not affect rendering. ignore the warning, it's due to a forgotten debugging call to the first dynamic function assuming it's the test extension, which is not the case with fbo. |
|
From: George S. <gsa...@gm...> - 2010-03-10 00:19:00
|
On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick <id...@fr...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > George Sapountzis wrote: > >> I made a small test to test code genration for dynamic extensions in >> http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test >> >> When using libGL + swrast_dri.so from getproc-test, the dynamic >> extensions code is not exercised and the test passes. >> >> When using libGL from mesa 7.7 and swrast_dri.so from getproc-test, >> the extension string does contain GL_MESA_test_extension but the test >> segfaults. > > There are a few places where this could break. > > - The generated dispatch stub function is wrong. > - The dispatch offset used by the driver is wrong. > - The dispatch remapping used by the driver is wrong. > It turned out that there were two bugs in glapi. One with using non-exec memory and the other with using an un-relocated function template for entry-point generation. I put fixes at: http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-debug I also tested with libGL pretending to not know fbo extensions, the fbo* demos and tests render correctly. I get a warning about an invalid enum in RenderbufferStorageMultisample(target) but i don't know where it comes from and it does not affect rendering. Since we are already generating static dispatch stubs for all known extensions, I guess we can add a few more static stubs and use them, instead of generating on-the-fly. I put an example about this in the getproc-debug branch, but I don't know if it's a good idea. regards, George. |
|
From: Brian P. <br...@vm...> - 2010-03-09 23:19:34
|
Maciej Cencora wrote: > Hi, > > following 3 piglit tests are failing on r300 because they're trying to use > GL_ARB_texture_non_power_of_two without checking if this extension is > available: > > fbo-blit > fbo-nodepth-test > fbo-nostencil-test > > I'm not sure what solution is preferable, 1) change the teximage sizes to be > POT, 2) require ARB_texture_npot. > I've tried first solution for fbo-blit but it segfaults, trying to execute > function at null address, so it would require some more investigation. We should use POT texture sizes so that the test always does _something_. Where's the crash? -Brian |
|
From: Brian P. <br...@vm...> - 2010-03-09 22:11:51
|
Keith Whitwell wrote: > I haven't seen any of these for a while now... Anyone have any ideas? I haven't seen them either. I don't know what's going on, but Tollef Fog Heen (an FD.org admin) created new mesa lists on fd.o yesterday (though Michel and I haven't move the subscriber lists yet). Perhaps something broke from that? Tollef? -Brian |
|
From: Maciej C. <m.c...@gm...> - 2010-03-09 22:09:34
|
Hi, following 3 piglit tests are failing on r300 because they're trying to use GL_ARB_texture_non_power_of_two without checking if this extension is available: fbo-blit fbo-nodepth-test fbo-nostencil-test I'm not sure what solution is preferable, 1) change the teximage sizes to be POT, 2) require ARB_texture_npot. I've tried first solution for fbo-blit but it segfaults, trying to execute function at null address, so it would require some more investigation. Regards, Maciej |
|
From: Keith W. <ke...@vm...> - 2010-03-09 20:47:50
|
On Tue, 2010-03-09 at 12:43 -0800, Dave Airlie wrote: > On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell <ke...@vm...> wrote: > > On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: > >> On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell <ke...@vm...> wrote: > >> > This leaves r300g as the only remaining user of > >> > pipe_winsys/u_simple_screen - which means we can rename that code > >> > r300_winsys and pull it into that driver... > >> > >> Dave had some code that "fixes" this, I think. I more or less agreed > >> to stay out of it, but I might take a look if killing u_simple_screen > >> is a priority. > > > > It's just a cleanup at this point, no urgency. > > I'll try and merge the easy bits of my branch to get drop u_simple_screen > first. > > then worry about the cached mgr stuff. Sure, whenever it's convenient. Keith |
|
From: Keith W. <ke...@vm...> - 2010-03-09 20:47:06
|
This has reached a point where I could think about merging it. There is plenty more cleanup to do, but the branch makes some big strides and introduces a couple of concepts that I've wanted for a long time. In particular the idea of a designated "targets" subtree which has code for explicitly constructing driver stacks. Secondly the ability to inject layers into (at least) the software stacks has been greatly improved, and I'd like to see us build on that for hardware drivers as well. There is probably still some bugfix to come, but if you're interested in the software rasterizers, please check out this branch and let me know how much I've broken things... Keith |
|
From: Dave A. <ai...@gm...> - 2010-03-09 20:43:50
|
On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell <ke...@vm...> wrote: > On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: >> On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell <ke...@vm...> wrote: >> > This leaves r300g as the only remaining user of >> > pipe_winsys/u_simple_screen - which means we can rename that code >> > r300_winsys and pull it into that driver... >> >> Dave had some code that "fixes" this, I think. I more or less agreed >> to stay out of it, but I might take a look if killing u_simple_screen >> is a priority. > > It's just a cleanup at this point, no urgency. I'll try and merge the easy bits of my branch to get drop u_simple_screen first. then worry about the cached mgr stuff. Dave. |
|
From: Keith W. <ke...@vm...> - 2010-03-09 19:49:25
|
I haven't seen any of these for a while now... Anyone have any ideas? Keith |
|
From: <ran...@gm...> - 2010-03-09 17:01:36
|
Playing with lines, some trivial/*-unfilled-* demos works, tri-unfilled-smooth renders wrong (as one big smooth tri, not as small smooth tre inside unfilled one). Also, clipping is wrong, as show by tri-unfilled-clip. This is more playground, hwen i'll have 6 or 8 optimized polygon rendering functions, it will be much less fun to code all those fixups in driver, so, t_dd_tritmp.h calling ..... |
|
From: Keith W. <ke...@vm...> - 2010-03-09 16:31:30
|
On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: > On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell <ke...@vm...> wrote: > > This leaves r300g as the only remaining user of > > pipe_winsys/u_simple_screen - which means we can rename that code > > r300_winsys and pull it into that driver... > > Dave had some code that "fixes" this, I think. I more or less agreed > to stay out of it, but I might take a look if killing u_simple_screen > is a priority. It's just a cleanup at this point, no urgency. Keith |
|
From: Corbin S. <mos...@gm...> - 2010-03-09 16:21:21
|
On Tue, Mar 9, 2010 at 6:37 AM, José Fonseca <jfo...@vm...> wrote: > On Mon, 2010-03-08 at 15:28 -0800, Brian Paul wrote: >> 1. Rename pipe_sampler_state:min_mip_filter to mip_filter. >> >> I don't know that the "min" part of that field refers to. >> >> >> 2. Remove PIPE_MAX_TEXTURE_LEVELS from p_state.h >> >> This token isn't used anywhere in the gallium interface anymore, nor >> the state trackers. I've already removed the use of this token in the >> gallium drivers (use per-driver #defines instead). There's still some >> use in the blitter code though. > > This looks fine. > >> 3. BTW, none of these #defines are used in the gallium interface >> header files: >> PIPE_MAX_CONSTANT_BUFFERS >> PIPE_MAX_ATTRIBS >> PIPE_MAX_SAMPLERS >> PIPE_MAX_VERTEX_SAMPLERS >> >> They are used in the utility code and drivers though. Should we >> define these in the gallium interface if they're not used by the >> interface itself? > > PIPE_MAX_SAMPLERS / PIPE_MAX_VERTEX_SAMPLERS are the maximum argument > set_fragment_sampler_textures/set_vertex_sampler_textures. These are > indeed unnecessary given that there are corresponding caps queries. So > state trackers should use arrays big enough to represent the API limits, > and pipe drivers should use arrays big enough to represent the hardware > limits, and both should agree on what's passed via the caps. > > Ditto for PIPE_MAX_CONSTANT_BUFFERS. > > I'm not sure about PIPE_MAX_ATTRIBS though. Can't find a caps for it. Since the drivers need to know those limits, can we doc them? I've been looking them up in the headers when I need to see their values, and I know I'm not the only one. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <Mos...@gm...> |
|
From: Corbin S. <mos...@gm...> - 2010-03-09 16:19:29
|
On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell <ke...@vm...> wrote: > This leaves r300g as the only remaining user of > pipe_winsys/u_simple_screen - which means we can rename that code > r300_winsys and pull it into that driver... Dave had some code that "fixes" this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <Mos...@gm...> |
|
From: Brian P. <br...@vm...> - 2010-03-09 15:16:13
|
Brian Paul wrote: > Keith Whitwell wrote: >> This is getting close to ready to merge, so please take a look if you're >> interested in the software rasterizers. >> >> Heads up that I've had to do some work on the cell driver in the >> gallium-sw-api-2 branch to migrate it to the new shared sw_winsys >> implementation. Unfortunately I don't have the cell SDK installed, so I >> can't even compile-test the changes. >> >> Hopefully someone out there who cares about cell can take a look, but I >> don't want to hold up merging this branch if nobody jumps on it. > > My PS3 is still going- I'll look into it. OK, it compiles but it doesn't run at all. The SPUs immediately crash because of invalid commands in the batch buffers. I suspect there's other breakage in texture handing and displaying of display targets. I don't have time to fix this so I guess cell will stay broken for a while. -Brian |
|
From: Keith W. <ke...@vm...> - 2010-03-09 15:03:54
|
On Tue, 2010-03-09 at 06:36 -0800, Brian Paul wrote: > Keith Whitwell wrote: > > This is getting close to ready to merge, so please take a look if you're > > interested in the software rasterizers. > > > > Heads up that I've had to do some work on the cell driver in the > > gallium-sw-api-2 branch to migrate it to the new shared sw_winsys > > implementation. Unfortunately I don't have the cell SDK installed, so I > > can't even compile-test the changes. > > > > Hopefully someone out there who cares about cell can take a look, but I > > don't want to hold up merging this branch if nobody jumps on it. > > My PS3 is still going- I'll look into it. Thanks Brian. Hopefully it's clear what's going on - it's just a port of the equivalent code from llvmpipe, plus a change to do the display-target untwiddling inside the driver rather than in the winsys. Keith |
|
From: José F. <jfo...@vm...> - 2010-03-09 14:37:59
|
On Mon, 2010-03-08 at 15:28 -0800, Brian Paul wrote: > 1. Rename pipe_sampler_state:min_mip_filter to mip_filter. > > I don't know that the "min" part of that field refers to. > > > 2. Remove PIPE_MAX_TEXTURE_LEVELS from p_state.h > > This token isn't used anywhere in the gallium interface anymore, nor > the state trackers. I've already removed the use of this token in the > gallium drivers (use per-driver #defines instead). There's still some > use in the blitter code though. This looks fine. > 3. BTW, none of these #defines are used in the gallium interface > header files: > PIPE_MAX_CONSTANT_BUFFERS > PIPE_MAX_ATTRIBS > PIPE_MAX_SAMPLERS > PIPE_MAX_VERTEX_SAMPLERS > > They are used in the utility code and drivers though. Should we > define these in the gallium interface if they're not used by the > interface itself? PIPE_MAX_SAMPLERS / PIPE_MAX_VERTEX_SAMPLERS are the maximum argument set_fragment_sampler_textures/set_vertex_sampler_textures. These are indeed unnecessary given that there are corresponding caps queries. So state trackers should use arrays big enough to represent the API limits, and pipe drivers should use arrays big enough to represent the hardware limits, and both should agree on what's passed via the caps. Ditto for PIPE_MAX_CONSTANT_BUFFERS. I'm not sure about PIPE_MAX_ATTRIBS though. Can't find a caps for it. Jose |
|
From: Brian P. <br...@vm...> - 2010-03-09 14:36:57
|
Keith Whitwell wrote: > This is getting close to ready to merge, so please take a look if you're > interested in the software rasterizers. > > Heads up that I've had to do some work on the cell driver in the > gallium-sw-api-2 branch to migrate it to the new shared sw_winsys > implementation. Unfortunately I don't have the cell SDK installed, so I > can't even compile-test the changes. > > Hopefully someone out there who cares about cell can take a look, but I > don't want to hold up merging this branch if nobody jumps on it. My PS3 is still going- I'll look into it. -Brian |
|
From: Keith W. <ke...@vm...> - 2010-03-09 14:08:38
|
This is getting close to ready to merge, so please take a look if you're interested in the software rasterizers. Heads up that I've had to do some work on the cell driver in the gallium-sw-api-2 branch to migrate it to the new shared sw_winsys implementation. Unfortunately I don't have the cell SDK installed, so I can't even compile-test the changes. Hopefully someone out there who cares about cell can take a look, but I don't want to hold up merging this branch if nobody jumps on it. This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Keith |
|
From: Luca B. <luc...@gm...> - 2010-03-09 13:42:12
|
> We can do this optimisation with busy as well. As long as you add > things to the busy list at the end, and stop testing after the first > busy call. At least for a single linear GPU context, which is all > I expect this code will ever be handling. Wouldn't this just end up reinventing the fenced bufmgr? Basically cached needs a list of all destroyed buffers (ideally in destruction order, so it can do the stopping optimization when expiring buffers), while the busy mechanism needs a list of all used buffers (destroyed or not) in usage order. So it seems it would need two lists, and essentially result in something that replicates fenced inside cached. BTW, right now I think all drivers use a single GPU context in userspace. Even Nouveau multiplexes Gallium contexts on a single channel (this is probably broken though). |
|
From: Dave A. <ai...@gm...> - 2010-03-09 06:32:06
|
On Tue, Mar 9, 2010 at 11:30 AM, Luca Barbieri <luc...@gm...> wrote: >> The fencing solution isn't near as efficent from what I can see, as it >> is designed around fences not buffer busy, I'll see if I can give it a try, >> but I suspect it look and smell like a hack. > > The problem I see is that while fenced is guaranteed to make at most > one fence_signalled query for a busy buffer per allocation, cached > could potentially query the busy status of _all_ destroyed buffers for > every allocation. > > The reason of this is that fenced orders the buffers in fence order > and stops at the first busy one, only handing them to the lower layer > (e.g. cached) once they are no longer busy. > > If kernel calls are used instead of userspace fencing, the problem > probably gets worse. > > So IMHO it should be much more efficient to use fenced over cached > (perhaps with slab between them too). > We can do this optimisation with busy as well. As long as you add things to the busy list at the end, and stop testing after the first busy call. At least for a single linear GPU context, which is all I expect this code will ever be handling. Dave. |
|
From: Eric A. <er...@an...> - 2010-03-09 05:46:01
|
On Mon, 08 Mar 2010 14:50:45 -0800, Ian Romanick <id...@fr...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eric Anholt wrote: > > Module: Mesa > > Branch: master > > Commit: 7cbc4c07ee85782d5da3e2db3c4e072ca498ff07 > > URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=7cbc4c07ee85782d5da3e2db3c4e072ca498ff07 > > > > Author: Eric Anholt <er...@an...> > > Date: Thu Mar 4 15:33:21 2010 -0800 > > > > intel: Remove the unused s8 spans code. Not hit during no_rast piglit. > > > > Shaves 5.5k off of the driver. > > Do any of the piglit tests actually try using stencil without depth? > It's an uncommon case, and it seems like it's the only way to hit this path. You mean as an FBO setup? That would be flagged as unsupported. |
|
From: Marek O. <ma...@gm...> - 2010-03-09 04:58:17
|
Also I've fixed GL_RGBA in master so now only GL_BGRA remains unresolved... On Tue, Mar 9, 2010 at 1:29 AM, Tom <to...@ri...> wrote: > Hi people, > > With the r300g driver (git ~today) drawing tris with color pointer like so: > > glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(struct vtx_data), blah); > > Seems to invert the RGBA -> ABGR. > > This short program shows the bug. It should display a yellow tri, and > instead on r300g it shows a blue tri. > > http://tom.noflag.org.uk/misc/r300g_color_bug.c > > Not sure if you want user bug reports of this kind yet, but anyway... > > -- > Tom > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-dev mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > |
|
From: Marek O. <ma...@gm...> - 2010-03-09 04:28:05
|
Yes, this is a known issue. The problem is that GL_RGBA and GL_BGRA map to PIPE_FORMAT_R8G8B8A8 (RGBA) and PIPE_FORMAT_A8R8G8B8 (ARGB), respectively, which is wrong. The attached patch fixes it for r300g but breaks other drivers which depend on Draw (softpipe, llvmpipe). The reason is that Draw seems to interpret A8R8G8B8 as BGRA, clearly hiding the bug. The possibilites are: - implement the same hack in r300g - fix Draw (I'd prefer this one) I hope I'll find some time this week to resolve this issue if no one else do it. -Marek On Tue, Mar 9, 2010 at 1:29 AM, Tom <to...@ri...> wrote: > Hi people, > > With the r300g driver (git ~today) drawing tris with color pointer like so: > > glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(struct vtx_data), blah); > > Seems to invert the RGBA -> ABGR. > > This short program shows the bug. It should display a yellow tri, and > instead on r300g it shows a blue tri. > > http://tom.noflag.org.uk/misc/r300g_color_bug.c > > Not sure if you want user bug reports of this kind yet, but anyway... > > -- > Tom > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-dev mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > |
|
From: <ran...@gm...> - 2010-03-09 04:07:52
|
This time it renders progs/demos/bounce and progs/samples/sphere correctly. |
102 messages has been excluded from this view by a project administrator.
