[Mesa-dev] [Bug 30234] [swrast] Mesa xdemo manywin aborted
https://bugs.freedesktop.org/show_bug.cgi?id=30234 Gordon Jin changed: What|Removed |Added Summary|Mesa xdemo manywin aborted |[swrast] Mesa xdemo manywin ||aborted Priority|high|medium -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] classic driver cleanup: ChooseTexFormat
On Sun, Sep 26, 2010 at 5:36 AM, Brian Paul wrote: > On Fri, Sep 24, 2010 at 6:08 PM, Eric Anholt wrote: >> One of the uglier bits of the classic drivers, in my opinion, is the >> ChooseTexFormat hook. Most drivers are trying to get to a similar set >> of formats, and using similar fallbacks for unavailable formats. >> Worse, they need to cleverly choose formats based on the incoming >> type/format to avoid having to munge the data on the way in if >> possible, and everyone needs to work those out. So, rather than >> having each driver have these smarts, move it to the core. >> >> There are still some rough edges. There are not enough fallbacks yet >> to cover everything (see i810 for example), so drivers with a more >> restricted set of supported formats may need to add more lines to >> _mesa_choose_tex_format. Also, the endianness-dependent choice of >> formats in texmem.c and radeon's texturing isn't merged -- I knew I'd >> mess it up somehow if I did it on my own, so I'm leaving radeon for >> someone with big-endian to finish off. >> >> Any complaints, or should I go ahead and merge this? > > In general this is a good clean-up. A couple comments. > > I see that you're merging the various format selections that the > drivers do back into core Mesa one driver at a time. I guess that > would eventually cover all cases but there'll still be quite a few > holes. For example, if a driver requests a GL_LUMINANCE internal > format but the driver has no native luminance texture formats, any > RGBA format will do as a fallback. So after trying MESA_FORMAT_L8, > MESA_FORMAT_AL88, _AL88_REV etc., the various MESA_FORMAT_RGBA > permutations should be tried. > > If you take a look at the st/mesa state tracker, a helper function > such as default_rgba_format() would help to fill in the holes. Also > note how the Z/stencil formats are handled there. > > Next, I think it's still worthwhile to keep using the user's > format/type info to help choose texture formats to try to hit the fast > paths in texstore.c for texture copying. > > Lastly, I'd like to see ctx->texture_format_supported renamed > ctx->TextureFormatSupported to follow existing naming conventions. > Another area we had problems with in classic radeon, is picking formats for texture that can't be rendered to, though they do hit texture fast paths. So when something like clutter wants to render to a texture later, it gets an incomplete FBO state (or due to bugs in radeon, we just misrender), and it has no real way to avoid this happening. I think reducing the number of texture formats the driver can pick might help, but could also create speed regressions in streaming texture apps perhaps. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] r600g: fix occlusion querying in the new design
On Sat, Sep 25, 2010 at 10:11 AM, Bas Nieuwenhuizen wrote: > These patches fix piglit test occlusion-query-discard in the new design of > r600g. > > The evergreen code is only compile tested as I don't have one. > > Bas Nieuwenhuizen (3): > r600g: set ENABLE_KILL in the shader state in the new design > r600g: introduce query state in new design > r600g: set ENABLE_KILL on evergreen too > Thanks for your patchset, however idea for query is to implement this specific bits into the winsys part. If i can't find time to do that today i will push your patches. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] classic driver cleanup: ChooseTexFormat
On Fri, Sep 24, 2010 at 6:08 PM, Eric Anholt wrote: > One of the uglier bits of the classic drivers, in my opinion, is the > ChooseTexFormat hook. Most drivers are trying to get to a similar set > of formats, and using similar fallbacks for unavailable formats. > Worse, they need to cleverly choose formats based on the incoming > type/format to avoid having to munge the data on the way in if > possible, and everyone needs to work those out. So, rather than > having each driver have these smarts, move it to the core. > > There are still some rough edges. There are not enough fallbacks yet > to cover everything (see i810 for example), so drivers with a more > restricted set of supported formats may need to add more lines to > _mesa_choose_tex_format. Also, the endianness-dependent choice of > formats in texmem.c and radeon's texturing isn't merged -- I knew I'd > mess it up somehow if I did it on my own, so I'm leaving radeon for > someone with big-endian to finish off. > > Any complaints, or should I go ahead and merge this? In general this is a good clean-up. A couple comments. I see that you're merging the various format selections that the drivers do back into core Mesa one driver at a time. I guess that would eventually cover all cases but there'll still be quite a few holes. For example, if a driver requests a GL_LUMINANCE internal format but the driver has no native luminance texture formats, any RGBA format will do as a fallback. So after trying MESA_FORMAT_L8, MESA_FORMAT_AL88, _AL88_REV etc., the various MESA_FORMAT_RGBA permutations should be tried. If you take a look at the st/mesa state tracker, a helper function such as default_rgba_format() would help to fill in the holes. Also note how the Z/stencil formats are handled there. Next, I think it's still worthwhile to keep using the user's format/type info to help choose texture formats to try to hit the fast paths in texstore.c for texture copying. Lastly, I'd like to see ctx->texture_format_supported renamed ctx->TextureFormatSupported to follow existing naming conventions. Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] classic driver cleanup: ChooseTexFormat
On Sat, Sep 25, 2010 at 6:31 AM, Jerome Glisse wrote: > On Fri, Sep 24, 2010 at 8:08 PM, Eric Anholt wrote: >> One of the uglier bits of the classic drivers, in my opinion, is the >> ChooseTexFormat hook. Most drivers are trying to get to a similar set >> of formats, and using similar fallbacks for unavailable formats. >> Worse, they need to cleverly choose formats based on the incoming >> type/format to avoid having to munge the data on the way in if >> possible, and everyone needs to work those out. So, rather than >> having each driver have these smarts, move it to the core. >> >> There are still some rough edges. There are not enough fallbacks yet >> to cover everything (see i810 for example), so drivers with a more >> restricted set of supported formats may need to add more lines to >> _mesa_choose_tex_format. Also, the endianness-dependent choice of >> formats in texmem.c and radeon's texturing isn't merged -- I knew I'd >> mess it up somehow if I did it on my own, so I'm leaving radeon for >> someone with big-endian to finish off. >> >> Any complaints, or should I go ahead and merge this? > > Do we care about all those old GPU ? r128, sis .. ? To me it seems > like we pretend they work but my feeling is that no one use them. > I think only radeon, nouveau & intel classic driver are still in use. > For the others i wouldn't mind stop pretending supporting them and > removing them from the tree. I'll support tdfx, mga, and (when I can get the damn thing POSTing) r128. I have an sis VGA-USB thingy as well, but that'll take some hacking and probably can't do 3D, so whatever. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Current tinderbox regression (mesa, radeon)
Hi, > On Sat, Sep 25, 2010 at 2:37 PM, Chris Ball wrote: >> http://tinderbox.x.org/builds/2010-09-24-0001/logs/libGL/#build > looks like libdrm isn't installed properly, I don't see > LIBDRM_RADEON being picked up. > > though previously we didn't build this code by default, maybe it > should be conditional on libdrm Sorry, forgot to mention that this is on sparc64. libdrm configure says: configure: WARNING: Disabling libdrm_intel. It depends on atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package. configure: WARNING: Disabling libdrm_radeon. It depends on atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package. So, perhaps this code should not only be conditional on a libdrm install, but on the existence of libdrm_radeon inside that install? - Chris. -- Chris Ball One Laptop Per Child ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cflags mess with llvm builds
On Fri, Sep 24, 2010 at 11:36 PM, Xavier Chantry wrote: > On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri wrote: >> Yes, that used to happen for me too. >> >> Just edit llvm-config to remove the offending text and ideally file a >> bug on the LLVM bug tracker. >> > > looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220 > thanks :) > The first answer is very negative and reports the bug as invalid. http://llvm.org/bugs/show_bug.cgi?id=8220#c1 The only suggestion is that custom flags could be appended. Another problem is indeed that mesa puts these llvm flags at the end, and the custom user CFLAGS first. irc discussion on oftc #llvm : 18:16 shining^ >> hopefully someone will look at http://llvm.org/bugs/show_bug.cgi?id=8220 , it should be easy to fix 18:16 gccbot >> tools bug #8220: llvm-config prints unnecessary cflags Product: tools, Component: llvm-config, Severity: normal, Assigned to: unassignedbugs, Status: NEW 18:20 @ aKor >> shining^: the PR looks invalid to me. 18:20 @ aKor >> shining^: all the printed tools are also required for projects 18:21 @ aKor >> e.g. sometimes O3 is lowered to O2 to workaround compiler miscompilation 18:21 @ aKor >> if you want to override the settings, you should just append the necessary stuff to the end of cflags / cxxflags 18:54 shining^ >> aKor: why are they required for projects ? 18:56 @ aKor >> shining^: because in the projects decent amount of LLVM code is compiled and used. This is mostly the code coming from the headers. 18:57 shining^ >> I dont think the purpose of that tool is to workaround compiler bugs. its just to provide the minimum set of flags required to build llvm code. maybe there isnt actually any ? 18:58 @ aKor >> well, if -O2 is *required* to workaround compiler bugs, then it's surely should be included into minimal set of options 18:58 @ aKor >> (as opposed to -O3) 18:59 shining^ >> otherwise we need both a minimum set of flags and an optimal set , working around bugs and all 18:59 shining^ >> why -O2 or -O3 ? maybe I dont want any 19:00 @ aKor >> ok, then just override it 19:00 @ aKor >> -O2 -O0 will yield -O0 19:00 shining^ >> well, its indeed very problematic in mesa, since these flags are appended last :P 19:01 @ aKor >> then the problem is in mesa's build system :) 19:01 shining^ >> so my CFLAGS=-O0 settings didnt work at all. I suppose I will go back to mesa people then .. 19:01 shining^ >> which is where I reported the problem in the first place, of course 19:01 @ aKor >> in the list in PR only -fomit-frame-pointer -fPIC are redundant 19:02 ddunbar_ >> shining^: fwiw, I agree with you the -O doesn't belong there 19:02 ddunbar_ >> or we should have two sets 19:02 @ aKor >> ddunbar_: it depends on the platform and compiler used 19:02 shining^ >> well -fomit-frame-pointer annoyed me too, I specifically build with no-omit-frame-pointer so I can get useful profiles 19:04 ddunbar_ >> aKor: I agree with the principle that it there should be a way to just get the required flags 19:05 @ aKor >> one should just define "required", e.g. "required to just build" or "required to build usable binaries". The latter seems should include more flags :) 19:05 ddunbar_ >> not that many 19:05 ddunbar_ >> I think the -D_GNU belong, and -frtti perhaps, but not much more 19:07 @ aKor >> ddunbar_: rtti settings should always be required, otherwise link will fail 19:07 ddunbar_ >> which is why I mentioned it :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] r600g: set ENABLE_KILL on evergreen too
--- src/gallium/drivers/r600/evergreen_state.c |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/r600/evergreen_state.c b/src/gallium/drivers/r600/evergreen_state.c index 5026f21..d77129b 100644 --- a/src/gallium/drivers/r600/evergreen_state.c +++ b/src/gallium/drivers/r600/evergreen_state.c @@ -1511,7 +1511,7 @@ void evergreen_pipe_shader_ps(struct pipe_context *ctx, struct r600_pipe_shader struct r600_pipe_context *rctx = (struct r600_pipe_context *)ctx; struct r600_pipe_state *rstate = &shader->rstate; struct r600_shader *rshader = &shader->shader; - unsigned i, tmp, exports_ps, num_cout, spi_ps_in_control_0, spi_input_z; + unsigned i, tmp, exports_ps, num_cout, spi_ps_in_control_0, spi_input_z,db_shader_control; boolean have_pos = FALSE, have_face = FALSE; /* clear previous register */ @@ -1582,6 +1582,13 @@ void evergreen_pipe_shader_ps(struct pipe_context *ctx, struct r600_pipe_shader S_0286E0_PERSP_CENTROID_ENA(1) | S_0286E0_LINEAR_CENTROID_ENA(1), 0x, NULL); + + db_shader_control = 0; + if (rshader->uses_kill) + db_shader_control |= S_02880C_KILL_ENABLE(1); + + /* only set some bits here, the other bits are set in the dsa state */ + r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT, R_02880C_DB_SHADER_CONTROL, db_shader_control, 0x0041, NULL); } void evergreen_pipe_shader_vs(struct pipe_context *ctx, struct r600_pipe_shader *shader) -- 1.7.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] r600g: introduce query state in new design
created a new state to set some bits which are needed for queries.
---
src/gallium/drivers/r600/evergreen_state.c | 19 -
src/gallium/drivers/r600/evergreend.h |2 +-
src/gallium/drivers/r600/r600_pipe.h |4 +++
src/gallium/drivers/r600/r600_state2.c | 39 +--
4 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index c54b78a..5026f21 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -213,7 +213,7 @@ static void *evergreen_create_dsa_state(struct pipe_context
*ctx,
db_render_override = S_02800C_FORCE_HIZ_ENABLE(V_02800C_FORCE_DISABLE) |
S_02800C_FORCE_HIS_ENABLE0(V_02800C_FORCE_DISABLE) |
S_02800C_FORCE_HIS_ENABLE1(V_02800C_FORCE_DISABLE);
- /* TODO db_render_override depends on query */
+
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_028028_DB_STENCIL_CLEAR, 0x, 0x, NULL);
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_02802C_DB_DEPTH_CLEAR, 0x3F80, 0x, NULL);
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_028410_SX_ALPHA_TEST_CONTROL, alpha_test_control, 0x, NULL);
@@ -226,9 +226,15 @@ static void *evergreen_create_dsa_state(struct
pipe_context *ctx,
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_028438_SX_ALPHA_REF, alpha_ref, 0x, NULL);
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_0286DC_SPI_FOG_CNTL, 0x, 0x, NULL);
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_028800_DB_DEPTH_CONTROL, db_depth_control, 0x, NULL);
+
+ /* masked bits are set by the shader state */
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_02880C_DB_SHADER_CONTROL, db_shader_control, 0xFFBE, NULL);
+
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_028000_DB_RENDER_CONTROL, db_render_control, 0x, NULL);
- r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_02800C_DB_RENDER_OVERRIDE, db_render_override, 0x, NULL);
+
+ /* masked bits are set by the query state */
+ r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_02800C_DB_RENDER_OVERRIDE, db_render_override, 0xFDFF, NULL);
+
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_028AC0_DB_SRESULTS_COMPARE_STATE0, 0x0, 0x, NULL);
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_028AC4_DB_SRESULTS_COMPARE_STATE1, 0x0, 0x, NULL);
r600_pipe_state_add_reg(rstate, EVERGREEN_GROUP_CONTEXT,
R_028AC8_DB_PRELOAD_CONTROL, 0x0, 0x, NULL);
@@ -1624,3 +1630,12 @@ void evergreen_pipe_shader_vs(struct pipe_context *ctx,
struct r600_pipe_shader
R_0288A4_SQ_PGM_START_FS,
0x, 0x, shader->bo);
}
+
+void evergreen_init_query_states(struct r600_pipe_context *rctx)
+{
+ r600_pipe_state_add_reg(&rctx->query_state_enabled,
EVERGREEN_GROUP_CONTEXT, R_028004_DB_COUNT_CONTROL,
S_028004_PERFECT_ZPASS_COUNTS(1), 0x, NULL);
+ r600_pipe_state_add_reg(&rctx->query_state_enabled,
EVERGREEN_GROUP_CONTEXT, R_02800C_DB_RENDER_OVERRIDE,
S_02800C_NOOP_CULL_DISABLE(1), 0x0200, NULL);
+
+ r600_pipe_state_add_reg(&rctx->query_state_enabled,
EVERGREEN_GROUP_CONTEXT, R_028004_DB_COUNT_CONTROL, 0, 0x, NULL);
+ r600_pipe_state_add_reg(&rctx->query_state_disabled,
EVERGREEN_GROUP_CONTEXT, R_02800C_DB_RENDER_OVERRIDE, 0, 0x0200, NULL);
+}
diff --git a/src/gallium/drivers/r600/evergreend.h
b/src/gallium/drivers/r600/evergreend.h
index 0a0a91e..5b47ed4 100644
--- a/src/gallium/drivers/r600/evergreend.h
+++ b/src/gallium/drivers/r600/evergreend.h
@@ -1411,7 +1411,7 @@
#define S_028000_STENCIL_COMPRESS_DISABLE(x) (((x) & 0x1) << 5)
#define S_028000_DEPTH_COMPRESS_DISABLE(x) (((x) & 0x1) << 6)
#define R_028004_DB_COUNT_CONTROL0x00028004
-#define S_028004_ZPASS_INCREMENT_DISABLE(((x) & 0x1) << 0)
+#define S_028004_ZPASS_INCREMENT_DISABLE(x)(((x) & 0x1) << 0)
#define S_028004_PERFECT_ZPASS_COUNTS(x)(((x) & 0x1) << 1)
#define R_028008_DB_DEPTH_VIEW 0x00028008
#define R_02800C_DB_RENDER_OVERRIDE 0x0002800C
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 19cfbcc..ee91469 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -43,6 +43,7 @@ enum r600_pipe_state_id {
R600_PIPE_STATE_CONSTANT,
R600_PIPE_STATE_SAMPLER,
R600_PIPE_STATE_RESOURCE,
+ R600_PIPE_STATE_QUERY,
R600_PIPE_NSTATES
};
@@ -95,6 +96,9 @@ struct r600_pipe_cont
[Mesa-dev] [PATCH 1/3] r600g: set ENABLE_KILL in the shader state in the new design
--- src/gallium/drivers/r600/r600_state2.c |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/r600/r600_state2.c b/src/gallium/drivers/r600/r600_state2.c index 40038f0..c375c54 100644 --- a/src/gallium/drivers/r600/r600_state2.c +++ b/src/gallium/drivers/r600/r600_state2.c @@ -109,7 +109,7 @@ static void r600_pipe_shader_ps(struct pipe_context *ctx, struct r600_pipe_shade struct r600_pipe_context *rctx = (struct r600_pipe_context *)ctx; struct r600_pipe_state *rstate = &shader->rstate; struct r600_shader *rshader = &shader->shader; - unsigned i, tmp, exports_ps, num_cout, spi_ps_in_control_0, spi_input_z; + unsigned i, tmp, exports_ps, num_cout, spi_ps_in_control_0, spi_input_z,db_shader_control; boolean have_pos = FALSE, have_face = FALSE; /* clear previous register */ @@ -173,6 +173,13 @@ static void r600_pipe_shader_ps(struct pipe_context *ctx, struct r600_pipe_shade r600_pipe_state_add_reg(rstate, R600_GROUP_CONTEXT, R_0288CC_SQ_PGM_CF_OFFSET_PS, 0x, 0x, NULL); + + db_shader_control = 0; + if (rshader->uses_kill) + db_shader_control |= S_02880C_KILL_ENABLE(1); + + /* only set some bits here, the other bits are set in the dsa state */ + r600_pipe_state_add_reg(rstate, R600_GROUP_CONTEXT, R_02880C_DB_SHADER_CONTROL, db_shader_control, 0x0041, NULL); } static int r600_pipe_shader(struct pipe_context *ctx, struct r600_pipe_shader *shader) -- 1.7.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] r600g: fix occlusion querying in the new design
These patches fix piglit test occlusion-query-discard in the new design of r600g. The evergreen code is only compile tested as I don't have one. Bas Nieuwenhuizen (3): r600g: set ENABLE_KILL in the shader state in the new design r600g: introduce query state in new design r600g: set ENABLE_KILL on evergreen too ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] classic driver cleanup: ChooseTexFormat
On Fri, Sep 24, 2010 at 8:08 PM, Eric Anholt wrote: > One of the uglier bits of the classic drivers, in my opinion, is the > ChooseTexFormat hook. Most drivers are trying to get to a similar set > of formats, and using similar fallbacks for unavailable formats. > Worse, they need to cleverly choose formats based on the incoming > type/format to avoid having to munge the data on the way in if > possible, and everyone needs to work those out. So, rather than > having each driver have these smarts, move it to the core. > > There are still some rough edges. There are not enough fallbacks yet > to cover everything (see i810 for example), so drivers with a more > restricted set of supported formats may need to add more lines to > _mesa_choose_tex_format. Also, the endianness-dependent choice of > formats in texmem.c and radeon's texturing isn't merged -- I knew I'd > mess it up somehow if I did it on my own, so I'm leaving radeon for > someone with big-endian to finish off. > > Any complaints, or should I go ahead and merge this? Do we care about all those old GPU ? r128, sis .. ? To me it seems like we pretend they work but my feeling is that no one use them. I think only radeon, nouveau & intel classic driver are still in use. For the others i wouldn't mind stop pretending supporting them and removing them from the tree. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30124] Mesa 7.9 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=30124 Bug 30124 depends on bug 30234, which changed state. Bug 30234 Summary: Mesa xdemo manywin aborted https://bugs.freedesktop.org/show_bug.cgi?id=30234 What|Old Value |New Value Resolution|FIXED | Status|RESOLVED|REOPENED -- 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 30234] Mesa xdemo manywin aborted
https://bugs.freedesktop.org/show_bug.cgi?id=30234 wang,jinjin changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #9 from wang,jinjin 2010-09-25 01:06:23 PDT --- With (master)441344ba7ed2a1d162ee33ac4bac4bf645188ceb , Mesa xdemo manywin using i965 can not abort, but using swrast, it also aborted. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Current tinderbox regression (mesa, radeon)
On Sat, Sep 25, 2010 at 2:37 PM, Chris Ball wrote: > http://tinderbox.x.org/builds/2010-09-24-0001/logs/libGL/#build looks like libdrm isn't installed properly, I don't see LIBDRM_RADEON being picked up. though previously we didn't build this code by default, maybe it should be conditional on libdrm Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
