Re: [Mesa3d-dev] [PATCH 0/20] Establish feature convensions
On Tue, Sep 22, 2009 at 09:28:22PM -0600, Brian Paul wrote: > I'm still reviewing your patches (but it's getting late and I need to > stop for the day). I think some of what you've done is good, but > other parts I'm not convinced we need. Here's some assorted comments. Thanks for the reviewing. I will reply inline. > > Subject: [PATCH 02/20] mesa/main: Make FEATURE_pixel_transfer follow > > feature conventions. > > As shown in mfeatures.h, this allows users of pixel.h to work without > > knowing if the feature is available. It also renames > > FEATURE_pixel_transfer to FEATURE_pixel. > Please don't rename this to FEATURE_pixel. I want to keep a strong > distinction between "pixel transfer" and "pixel store" functions. > > Subject: [PATCH 14/20] mesa/main: Make FEATURE_evaluators follow feature > > conventions. > > As shown in mfeatures.h, this allows users of eval.h to work without > > knowing if the feature is available. It also renames FEATURE_evaluators > > to FEATURE_eval. > Again, I'd prefer that you not rename FEATURE_evaluators. IIRC, I > named the file eval.c because back in the 8.3 days evaluators.c would > have been too long. They are renamed to keep in sync with their init functions, not the file names. That is, their init functions are named _mesa_init_pixel and _mesa_init_eval respectively. Should I also rename the init functions while undo the renames? > Note that if you use _mesa_init_colortable_dispatch() to plug > in all the colortable functions into the dispatch table, I think > that all the _mesa_ColorTable* functions can be made static. That > would be a nice improvement. Will do. > In many other cases, the only other calls to the _mesa_FooBar() state- > setters is from the glPopAttrib() code. Maybe that could be changed > somehow to allow more static functions. I think I will make _mesa_FooBar functions that are not used globally static first. They should include most of functions. Other than glPopAttrib, some of the remaining ones are used in meta.c. > > I wanted to make #if's more a one-time effort. The #if's are either in > > convolve.h, or in every location, say, > > _mesa_adjust_image_for_convolution is called. This includes in st, > > meta, and drivers. It becomes horrible soon. > The _mesa_adjust_image_for_convolution() function could easily be > made a no-op function so we don't have to #ifdef it everywhere. > That's an easy one to fix. That is one of the goals this patch tries to do :) > -- > Patches 0017/0018/0019/0020: > I think I'd prefer to keep the texformat code as-is for now. Hmm. To make intel dri driver compile with the compressed texformats disabled, I have to add like 10 #if/#endif pairs to leave out only a tiny fraction of the code. What do you think if I still make disabled texformats become no-op, but remove all other changes from the patches? > > does the current feature use ifdefs in the C code to avoid calling > > entrypoints if the feature isn't enabled? vs having null C functions in > > the header files? > If a function isn't plugged into the dispatch table, that slot in > the dispatch table will point to the default/nop dispatch function. > We won't try to jump through a NULL function pointer. Talking about dispatching, for those entry points that are disabled by a feature, they will be generic_nop, the default value. If the entry points are also found in GLvertexformat, they will be NULL, and will never to be installed into the dispatch table. If some driver functions in dd_function_table are needed to implement the feature, they will be NULL too. This is minor. But it might not be obvious on first sight of the patches. > > The first isn't generally a good idea as code doesn't get built when > > the feature is off, so people editing around the feature can forget to > > fix things inside the ifdefs, the second approach is a lot sounder > > generally. > Normally all featueres are on. If you're adding a new feature and > forget to provide and plug in an API function, you'll quickly know about > it regardless of which method is used (presuming you test your code). > > There is also one new macro for driver writers. Right now, driver > > functions are initialized by > > > > driver->Blah1 = implBlah1; > > driver->Blah2 = implBlah2; > > > > The patch series encourages drivers to switch to > > > > _MESA_INIT_BLAH_FUNCTIONS(driver, impl); > I guess I'm not too enthusiastic about this change in particular. > It's a clunky macro and the current method is much simpler. It > also implies changing all the drivers. Nobody has ever had a problem > with this in the past so I think it's a non-issue. It is sort of a helper macro/replacement for the existing st_init_blah_functions or intelInitBlahFunctions. I do not intend to convert existing drivers to use them. But I would like to see them used when new features are added. I think the awareness of something is a feature fr
Re: [Mesa3d-dev] RFC: Proposed mesa_7_5_branch and mesa_7_6_branch freeze for release
On Tue, 2009-09-22 at 13:46 -0700, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I would like to open XDC by shipping Mesa 7.5.2 and 7.6. In order to > make that happen, I propose the following: > > - - Freeze both branches at 12:01AM PDT 9/25 (this upcoming Friday). > > - - I will tag both trees at that time. One will get mesa_7_5_2_rc1, and > the other will get mesa_7_6_rc1. > > - - Once those tags appear, please test whatever drivers *you* care about > on whatever platforms *you* care about. > > - - Report any new regressions to bugzilla. If you find something that > you believe is an absolute show stopper, mark it as such. We'll discuss > whether we want to block the releases for it. > > For 7.6, I want to set the bar for blocking the release very, very high. > At least one distro really wants to use 7.6, and their freeze is > perilously soon. IMO, pretty much only build failures or "7.6 make my > computer catch on fire, but 7.5.1 does not" are blockers. > > I had intended to post this RFC quite some time ago, but life issues > outside of $JOB have distracted me for the last few weeks. The time has > just slipped by. Aside from the absurdly compressed schedule, this > seems to be what most other projects do, and I think Mesa should to. > We've partially done this in the past, but our process could use a > little more, well, process. :) I like the idea of better defining what our releases mean and how we get there, and doing this freeze now seems pragmatic. However, next time round, a bit more time in the schedule would probably be appreciated, so that people can schedule time for testing and/or fixing the bugs that testing identify. If I understand things correctly, this is (or should be) the last 7.5.x release, and that branch will more or less go to sleep after this? Keith -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] flushing vertices in radeon swtcl
>
> Hey all,
>
> So in mesa for swtcl cases we emit vertices to DMA, and set a driver
> internal dma.flush hook, we also set
> ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES;
>
> The driver has its FlushVertices pointed at the vbo_exec_FlushVertices
> call.
>
> I'm not sure when this ever worked but I assume it did at one stage in
> r100 driver since I haven't really changed this code flow, I'm
> contemplating doing something like the below but maybe someone can
> say when this all got broken.
any insights? Keith?
Dave.
>
> Dave.
>
> diff --git a/src/mesa/drivers/dri/radeon/radeon_context.c
> b/src/mesa/drivers/dri/radeon/radeon_context.c
> index 8f4485a..d103ac5 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_context.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_context.c
> @@ -204,6 +204,14 @@ static void r100_init_vtbl(radeonContextPtr radeon)
> radeon->vtbl.emit_query_finish = r100_emit_query_finish;
> }
>
> +static void radeon_flush_vertices(GLcontext *ctx, GLuint flags)
> +{
> + r100ContextPtr rmesa = R100_CONTEXT(ctx);
> + if (rmesa->radeon.dma.flush)
> + rmesa->radeon.dma.flush(ctx);
> + vbo_exec_FlushVertices(ctx, flags);
> +}
> +
> /* Create the device specific context.
> */
> GLboolean
> @@ -329,6 +337,7 @@ r100CreateContext( const __GLcontextModes *glVisual,
> _swsetup_CreateContext( ctx );
> _ae_create_context( ctx );
>
> + ctx->Driver.FlushVertices = radeon_flush_vertices;
> /* Install the customized pipeline:
> */
> _tnl_destroy_pipeline( ctx );
>
>
>
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/20] Establish feature convensions
On Wed, Sep 23, 2009 at 04:04:19PM +0800, Chia-I Wu wrote: > > If you agree with this feedback, would you mind re-spinning the first > > few patches? I'd rather focus on getting a few things (like maybe > > colortable and convolution) sorted out as examples before we spend too > > much time on the rest. > I will be working on it. Hopefully in time for today. This is a subset of the patch series that was discussed. In this subset, * _mesa_FooBar is made static whenever possible * FEATURE_pixel_transfer is not renamed to FEATURE_pixel * Change to FEATURE_convolve is simplified not to remove existing #if's * Change to FEATURE_texture_fxt1 is simplified not to remove existing #if's There are also some changes that are not available from this subset. I will try to highlight them here * FEATURE_beginend Disabling this feature disables the use of GLvertexformat, api_noop.c, and api_loopback.c completely. They are not needed in OpenGL ES. * Merge of FEATURE_ARB_occlusion_query and FEATURE_EXT_timer_query This keeps features at per-file granularity. * _MESA_INIT__VTXFMT Similar to the macro for driver functions. They are defined by FEATURE_arrayelt, FEATURE_eval, and FEATURE_dlist. -- Regards, olv >From 8350b4979aecb384dd6912d092744a88b3c267e8 Mon Sep 17 00:00:00 2001 From: Chia-I Wu Date: Mon, 7 Sep 2009 17:51:33 +0800 Subject: [PATCH 1/6] mesa/main: Add comments to mfeatures.h. The comments document the conventions that a feature may follow. --- src/mesa/main/mfeatures.h | 32 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/mfeatures.h b/src/mesa/main/mfeatures.h index e23cdb1..6318934 100644 --- a/src/mesa/main/mfeatures.h +++ b/src/mesa/main/mfeatures.h @@ -36,6 +36,38 @@ #define _HAVE_FULL_GL 1 #endif +/* assert that a feature is disabled and should never be used */ +#define ASSERT_NO_FEATURE() ASSERT(0) + +/** + * A feature can be anything. But most of them share certain characteristics. + * + * When a feature defines driver entries, they can be initialized by + * _MESA_INIT__FUNCTIONS + * + * When a feature defines vtxfmt entries, they can be initialized and + * installed by + * _MESA_INIT__VTXFMT + * _mesa_install__vtxfmt + * + * When a feature defines dispatch entries, they are initialized by + * _mesa_init__dispatch + * + * When a feature has states, they are initialized and freed by + * _mesa_init_ + * _mesa_free__data + * + * Except for states, the others compile to no-op when a feature is disabled. + * + * The GLAPIENTRYs and helper functions defined by a feature should also + * compile to no-op when it is disabled. But to save typings and to catch + * bugs, some of them may be unavailable, or compile to ASSERT_NO_FEATURE() + * when the feature is disabled. + * + * A feature following the conventions may be used without knowing if it is + * enabled or not. + */ + #define FEATURE_accum _HAVE_FULL_GL #define FEATURE_attrib_stack _HAVE_FULL_GL #define FEATURE_colortable _HAVE_FULL_GL -- 1.6.2.4 >From dd341f4d74419b631965a1f55dabb2e86cb28403 Mon Sep 17 00:00:00 2001 From: Chia-I Wu Date: Mon, 7 Sep 2009 16:59:27 +0800 Subject: [PATCH 2/6] mesa/main: Make FEATURE_pixel_transfer follow feature conventions. As shown in mfeatures.h, this allows users of pixel.h to work without knowing if the feature is available. --- src/mesa/main/api_exec.c | 16 ++ src/mesa/main/pixel.c| 40 ++ src/mesa/main/pixel.h| 47 - src/mesa/main/state.c|4 --- 4 files changed, 51 insertions(+), 56 deletions(-) diff --git a/src/mesa/main/api_exec.c b/src/mesa/main/api_exec.c index 02550ae..39941a1 100644 --- a/src/mesa/main/api_exec.c +++ b/src/mesa/main/api_exec.c @@ -93,9 +93,7 @@ #include "macros.h" #include "matrix.h" #include "multisample.h" -#if FEATURE_pixel_transfer #include "pixel.h" -#endif #include "pixelstore.h" #include "points.h" #include "polygon.h" @@ -284,17 +282,9 @@ _mesa_init_exec_table(struct _glapi_table *exec) SET_MapGrid2f(exec, _mesa_MapGrid2f); #endif SET_MultMatrixd(exec, _mesa_MultMatrixd); -#if FEATURE_pixel_transfer - SET_GetPixelMapfv(exec, _mesa_GetPixelMapfv); - SET_GetPixelMapuiv(exec, _mesa_GetPixelMapuiv); - SET_GetPixelMapusv(exec, _mesa_GetPixelMapusv); - SET_PixelMapfv(exec, _mesa_PixelMapfv); - SET_PixelMapuiv(exec, _mesa_PixelMapuiv); - SET_PixelMapusv(exec, _mesa_PixelMapusv); - SET_PixelTransferf(exec, _mesa_PixelTransferf); - SET_PixelTransferi(exec, _mesa_PixelTransferi); - SET_PixelZoom(exec, _mesa_PixelZoom); -#endif + + _mesa_init_pixel_dispatch(exec); + SET_PixelStoref(exec, _mesa_PixelStoref); SET_PointSize(exec, _mesa_PointSize); SET_PolygonMode(exec, _mesa_PolygonMode); diff --git a/src/mesa/main/pixel.c b/src/mesa/main/pixel.c index fcef6df..3820ebd 100644 --- a/src/mesa/main/pixel.c +++ b/src/mesa/main/p
Re: [Mesa3d-dev] flushing vertices in radeon swtcl
On Wed, 2009-09-23 at 01:41 -0700, Dave Airlie wrote:
> >
> > Hey all,
> >
> > So in mesa for swtcl cases we emit vertices to DMA, and set a driver
> > internal dma.flush hook, we also set
> > ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES;
> >
> > The driver has its FlushVertices pointed at the vbo_exec_FlushVertices
> > call.
> >
> > I'm not sure when this ever worked but I assume it did at one stage in
> > r100 driver since I haven't really changed this code flow, I'm
> > contemplating doing something like the below but maybe someone can
> > say when this all got broken.
>
> any insights? Keith?
Hmm, it would seem like you'd need this if:
a) you have a hw vertex buffer that you're incrementally extending as
new vertices arrive
b) you are delaying emitting the draw packet until you know how many
vertices you put in that buffer, and
c) you don't have any other mechanism to ensure that draw packet doesn't
attempt to span hw statechanges.
IE. if you're optimistically trying to combine incoming primitives into
single draw packets, and don't have code to flush that in response to
state-changes, then this patch makes sense.
If the above doesn't describe your situation, I don't think you want
this.
However, even if it does, note that you'd be better off trying to figure
out when a *real* hardware statechange is about to happen before tying
off the old draw packet, as Driver.FlushVertices is going to get called
on every putative mesa statechange, many of which won't result in
hardware statechanges.
In fact, thinking about it, if you flush on every call to this function,
you basically defeat the optimization it seems you're trying to
implement, because the incoming vertices you're trying to combine will
almost always have a mesa statechange between them -- there's no other
reason mesa would break them up, and Mesa already tries to combine
incoming application draws that aren't separated by statechanges.
So if you do this, really you'd be just as well served with an eager
emit of the draw packet & forget about trying to be lazy.
Keith
> Dave.
>
> >
> > Dave.
> >
> > diff --git a/src/mesa/drivers/dri/radeon/radeon_context.c
> > b/src/mesa/drivers/dri/radeon/radeon_context.c
> > index 8f4485a..d103ac5 100644
> > --- a/src/mesa/drivers/dri/radeon/radeon_context.c
> > +++ b/src/mesa/drivers/dri/radeon/radeon_context.c
> > @@ -204,6 +204,14 @@ static void r100_init_vtbl(radeonContextPtr radeon)
> > radeon->vtbl.emit_query_finish = r100_emit_query_finish;
> > }
> >
> > +static void radeon_flush_vertices(GLcontext *ctx, GLuint flags)
> > +{
> > + r100ContextPtr rmesa = R100_CONTEXT(ctx);
> > + if (rmesa->radeon.dma.flush)
> > + rmesa->radeon.dma.flush(ctx);
> > + vbo_exec_FlushVertices(ctx, flags);
> > +}
> > +
> > /* Create the device specific context.
> > */
> > GLboolean
> > @@ -329,6 +337,7 @@ r100CreateContext( const __GLcontextModes *glVisual,
> > _swsetup_CreateContext( ctx );
> > _ae_create_context( ctx );
> >
> > + ctx->Driver.FlushVertices = radeon_flush_vertices;
> > /* Install the customized pipeline:
> > */
> > _tnl_destroy_pipeline( ctx );
> >
> >
> >
> > --
> > Come build with us! The BlackBerry® Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9-12, 2009. Register now!
> > http://p.sf.net/sfu/devconf
> > ___
> > Mesa3d-dev mailing list
> > Mesa3d-dev@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> >
> >
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] flushing vertices in radeon swtcl
> > > So in mesa for swtcl cases we emit vertices to DMA, and set a driver > > > internal dma.flush hook, we also set > > > ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; > > > > > > The driver has its FlushVertices pointed at the vbo_exec_FlushVertices > > > call. > > > > > > I'm not sure when this ever worked but I assume it did at one stage in > > > r100 driver since I haven't really changed this code flow, I'm > > > contemplating doing something like the below but maybe someone can > > > say when this all got broken. > > > > any insights? Keith? > > Hmm, it would seem like you'd need this if: > > a) you have a hw vertex buffer that you're incrementally extending as > new vertices arrive > b) you are delaying emitting the draw packet until you know how many > vertices you put in that buffer, and > c) you don't have any other mechanism to ensure that draw packet doesn't > attempt to span hw statechanges. You wrote the original ;-), its the r100 swtcl code. I've just been pushing it around the place since, but yes, a, b, c all seem to be true. > IE. if you're optimistically trying to combine incoming primitives into > single draw packets, and don't have code to flush that in response to > state-changes, then this patch makes sense. > > If the above doesn't describe your situation, I don't think you want > this. > > However, even if it does, note that you'd be better off trying to figure > out when a *real* hardware statechange is about to happen before tying > off the old draw packet, as Driver.FlushVertices is going to get called > on every putative mesa statechange, many of which won't result in > hardware statechanges. > > In fact, thinking about it, if you flush on every call to this function, > you basically defeat the optimization it seems you're trying to > implement, because the incoming vertices you're trying to combine will > almost always have a mesa statechange between them -- there's no other > reason mesa would break them up, and Mesa already tries to combine > incoming application draws that aren't separated by statechanges. > > So if you do this, really you'd be just as well served with an eager > emit of the draw packet & forget about trying to be lazy. That probably makes more sense then, I should push the draw packet at a better place, what happens at the moment, is I get a state change without getting the flush, and emit a bunch of texture state that doesn't match the vertices I've already stuck in the vertex buffer, with the new kernel checker it detects the illegal state. Dave. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] flushing vertices in radeon swtcl
On Wed, 2009-09-23 at 02:23 -0700, Dave Airlie wrote: > > > > So in mesa for swtcl cases we emit vertices to DMA, and set a driver > > > > internal dma.flush hook, we also set > > > > ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; > > > > > > > > The driver has its FlushVertices pointed at the vbo_exec_FlushVertices > > > > call. > > > > > > > > I'm not sure when this ever worked but I assume it did at one stage in > > > > r100 driver since I haven't really changed this code flow, I'm > > > > contemplating doing something like the below but maybe someone can > > > > say when this all got broken. > > > > > > any insights? Keith? > > > > Hmm, it would seem like you'd need this if: > > > > a) you have a hw vertex buffer that you're incrementally extending as > > new vertices arrive > > b) you are delaying emitting the draw packet until you know how many > > vertices you put in that buffer, and > > c) you don't have any other mechanism to ensure that draw packet doesn't > > attempt to span hw statechanges. > > You wrote the original ;-), its the r100 swtcl code. Understood -- saying 'you' above & below is just shorthand, not trying to assign ownership, responsibility and/or blame... > I've just been pushing it around the place since, but yes, a, b, c all > seem to be true. > > > IE. if you're optimistically trying to combine incoming primitives into > > single draw packets, and don't have code to flush that in response to > > state-changes, then this patch makes sense. > > > > If the above doesn't describe your situation, I don't think you want > > this. > > > > However, even if it does, note that you'd be better off trying to figure > > out when a *real* hardware statechange is about to happen before tying > > off the old draw packet, as Driver.FlushVertices is going to get called > > on every putative mesa statechange, many of which won't result in > > hardware statechanges. > > > > In fact, thinking about it, if you flush on every call to this function, > > you basically defeat the optimization it seems you're trying to > > implement, because the incoming vertices you're trying to combine will > > almost always have a mesa statechange between them -- there's no other > > reason mesa would break them up, and Mesa already tries to combine > > incoming application draws that aren't separated by statechanges. > > > > So if you do this, really you'd be just as well served with an eager > > emit of the draw packet & forget about trying to be lazy. > > That probably makes more sense then, I should push the draw packet at > a better place, what happens at the moment, is I get a state change > without getting the flush, and emit a bunch of texture state that doesn't > match the vertices I've already stuck in the vertex buffer, with the new > kernel checker it detects the illegal state. Exactly. Either emit the draw straight away or delay it until just before you emit the next statechange (or command buffer flush). I'd probably just make my life easier & emit it straight away. Keith -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] radeon: Be more resilient to texture image (un)mapping imbalance.
On Mon, 2009-09-21 at 16:46 +0200, mic...@daenzer.net wrote:
> From: Michel Dänzer
>
> Since commit 6f9dbe773953b024075910b3bec11ebc96c2e8e0 ('mesa: use new
> _mesa_meta_CopyTex[Sub]Image() functions'), I was seeing crashes when using
> the
> compiz magnifier plugin, apparently because the code in radeon_texture.c ends
> up unmapping a texture BO more times than it was mapped. There may be a better
> fix for that particular problem, [...]
Actually the patch turned out not to fix the compiz magnifier plugin
problem completely. The patch below does, does it look good?
* Make sure the texture has a valid format in copy_tex_image().
* Move up the _mesa_update_state() call in _swrast_ReadPixels(),
so the driver doesn't map the wrong textures.
* Make the radeon texture (un)mapping code cope with textures
which don't have a miptree associated with them yet.
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 2175678..991a3db 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -55,6 +55,7 @@
#include "main/stencil.h"
#include "main/texobj.h"
#include "main/texenv.h"
+#include "main/texformat.h"
#include "main/teximage.h"
#include "main/texparam.h"
#include "main/texstate.h"
@@ -2172,6 +2173,12 @@ copy_tex_image(GLcontext *ctx, GLuint dims, GLenum
target, GLint level,
return;
}
+ if (texImage->TexFormat == &_mesa_null_texformat)
+ texImage->TexFormat = ctx->Driver.ChooseTextureFormat(ctx,
+ internalFormat,
+ format,
+ type);
+
_mesa_unlock_texture(ctx, texObj); /* need to unlock first */
/*
diff --git a/src/mesa/drivers/dri/radeon/radeon_texture.c
b/src/mesa/drivers/dri/radeon/radeon_texture.c
index 049284e..7b7392b 100644
--- a/src/mesa/drivers/dri/radeon/radeon_texture.c
+++ b/src/mesa/drivers/dri/radeon/radeon_texture.c
@@ -101,7 +101,12 @@ void radeonFreeTexImageData(GLcontext *ctx, struct
gl_texture_image *timage)
/* Set Data pointer and additional data for mapped texture image */
static void teximage_set_map_data(radeon_texture_image *image)
{
- radeon_mipmap_level *lvl = &image->mt->levels[image->mtlevel];
+ radeon_mipmap_level *lvl;
+
+ if (!image->mt)
+ return;
+
+ lvl = &image->mt->levels[image->mtlevel];
image->base.Data = image->mt->bo->ptr +
lvl->faces[image->mtface].offset;
image->base.RowStride = lvl->rowstride / image->mt->bpp;
@@ -969,7 +974,7 @@ int radeon_validate_texture_miptree(GLcontext * ctx, struct
gl_texture_object *t
radeon_texture_image *image =
get_radeon_texture_image(texObj->Image[face][level]);
if (RADEON_DEBUG & RADEON_TEXTURE)
fprintf(stderr, " face %i, level %i... %p vs %p
", face, level, t->mt, image->mt);
- if (t->mt == image->mt) {
+ if (t->mt == image->mt || (!image->mt &&
!image->base.Data)) {
if (RADEON_DEBUG & RADEON_TEXTURE)
fprintf(stderr, "OK\n");
diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
index 48b9408..a1aeb2e 100644
--- a/src/mesa/swrast/s_readpix.c
+++ b/src/mesa/swrast/s_readpix.c
@@ -555,15 +555,15 @@ _swrast_ReadPixels( GLcontext *ctx,
SWcontext *swrast = SWRAST_CONTEXT(ctx);
struct gl_pixelstore_attrib clippedPacking = *packing;
+ if (ctx->NewState)
+ _mesa_update_state(ctx);
+
/* Need to do swrast_render_start() before clipping or anything else
* since this is where a driver may grab the hw lock and get an updated
* window size.
*/
swrast_render_start(ctx);
- if (ctx->NewState)
- _mesa_update_state(ctx);
-
if (swrast->NewState)
_swrast_validate_derived( ctx );
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] r600: add support for cube textures
Needs quite a few extra instructions, please test/review if I got them all right. Andre 0001-r600-add-support-for-CUBE-textures-also-TXP.patch Description: Binary data -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] radeon: Be more resilient to texture image (un)mapping imbalance.
Michel Dänzer wrote:
> On Mon, 2009-09-21 at 16:46 +0200, mic...@daenzer.net wrote:
>> From: Michel Dänzer
>>
>> Since commit 6f9dbe773953b024075910b3bec11ebc96c2e8e0 ('mesa: use new
>> _mesa_meta_CopyTex[Sub]Image() functions'), I was seeing crashes when using
>> the
>> compiz magnifier plugin, apparently because the code in radeon_texture.c ends
>> up unmapping a texture BO more times than it was mapped. There may be a
>> better
>> fix for that particular problem, [...]
>
> Actually the patch turned out not to fix the compiz magnifier plugin
> problem completely. The patch below does, does it look good?
>
> * Make sure the texture has a valid format in copy_tex_image().
> * Move up the _mesa_update_state() call in _swrast_ReadPixels(),
> so the driver doesn't map the wrong textures.
> * Make the radeon texture (un)mapping code cope with textures
> which don't have a miptree associated with them yet.
Looks good to me. Thanks, Michel.
-Brian
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: Proposed mesa_7_5_branch and mesa_7_6_branch freeze for release
Keith Whitwell wrote: > On Tue, 2009-09-22 at 13:46 -0700, Ian Romanick wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I would like to open XDC by shipping Mesa 7.5.2 and 7.6. In order to >> make that happen, I propose the following: >> >> - - Freeze both branches at 12:01AM PDT 9/25 (this upcoming Friday). >> >> - - I will tag both trees at that time. One will get mesa_7_5_2_rc1, and >> the other will get mesa_7_6_rc1. >> >> - - Once those tags appear, please test whatever drivers *you* care about >> on whatever platforms *you* care about. >> >> - - Report any new regressions to bugzilla. If you find something that >> you believe is an absolute show stopper, mark it as such. We'll discuss >> whether we want to block the releases for it. >> >> For 7.6, I want to set the bar for blocking the release very, very high. >> At least one distro really wants to use 7.6, and their freeze is >> perilously soon. IMO, pretty much only build failures or "7.6 make my >> computer catch on fire, but 7.5.1 does not" are blockers. >> >> I had intended to post this RFC quite some time ago, but life issues >> outside of $JOB have distracted me for the last few weeks. The time has >> just slipped by. Aside from the absurdly compressed schedule, this >> seems to be what most other projects do, and I think Mesa should to. >> We've partially done this in the past, but our process could use a >> little more, well, process. :) > > I like the idea of better defining what our releases mean and how we get > there, and doing this freeze now seems pragmatic. > > However, next time round, a bit more time in the schedule would probably > be appreciated, so that people can schedule time for testing and/or > fixing the bugs that testing identify. > > If I understand things correctly, this is (or should be) the last 7.5.x > release, and that branch will more or less go to sleep after this? That's my hope. -Brian -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] is anybody writing dri2 client stuff
Hi All, The dri1 client files in mesa/src/driclient provide some useful interfaces, I want to know is there a need to provide similar interfaces for dri2 client? Cooper -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): st/xorg: Fix two leeks
On Tue, Sep 22, 2009 at 11:28 AM, Zack Rusin wrote: > On Tuesday 22 September 2009 14:10:34 Jakob Bornecrantz wrote: >> diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c >> b/src/gallium/state_trackers/xorg/xorg_composite.c index 66ca4cb..ed649a9 >> 100644 >> --- a/src/gallium/state_trackers/xorg/xorg_composite.c >> +++ b/src/gallium/state_trackers/xorg/xorg_composite.c >> @@ -359,6 +359,9 @@ bind_framebuffer_state(struct exa_context *exa, struct >> exa_pixmap_priv *pDst) state.zsbuf = 0; >> >> cso_set_framebuffer(exa->cso, &state); >> + >> + /* we do fire and forget for the framebuffer, this is the forget part >> */ + pipe_surface_reference(&surface, NULL); >> } >> > > This doesn't follow what we do in gallium state trackers. It should be done in > xorg_exa_common_done called from ExaDone. Or in other words when we're really > done with the surface. Right, I'll fix that. I have to admit that I was lazy I couldn't be bother to figgure where to dereference it properly and it worked for the i915g driver. Cheers Jakob. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] is anybody writing dri2 client stuff
On Wed, Sep 23, 2009 at 9:40 AM, Cooper Yuan wrote: > Hi All, > > The dri1 client files in mesa/src/driclient provide some useful interfaces, > I want to know is there a need to provide similar interfaces for dri2 > client? It would be nice if this code was in it's own lib since Mesa isn't the only DRI client these days. For XvMC I copied the DRI1 code to src/driclient to avoid linking with half of Mesa. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Merged softpipe-opt
This branch lifts the performance of softpipe to roughly the same ballpark as where the Mesa software rasterizer has been, though perhaps not for the super-simple stuff like gears. The real performance work now is in Jose's llvmpipe, into which this branch fed a bunch of code and ideas, but which is now clearly moving beyond this early work. Softpipe remains a good place to try out new code, without having to deal too much with the issues of runtime code generation, etc, and I will probably continue doing some experimental work here as time allows. Thanks to Brian and Vinson for finding and fixing many bugs introduced on this branch. Keith -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24093] can't render stuff using webgl on intel
http://bugs.freedesktop.org/show_bug.cgi?id=24093 Ian Romanick changed: What|Removed |Added AssignedTo|i...@freedesktop.org |mesa3d- ||d...@lists.sourceforge.net Component|Drivers/DRI/i965|Mesa core --- Comment #4 from Ian Romanick 2009-09-23 11:41:02 PST --- OSMesa has nothing to do with any hardware driver. It's an entirely software implementation. I'm pretty sure it supports those GLX extensions, so I'm not sure what the problem is. I'm re-assigning to mesa3d-dev because this is pretty much the limit of my OSMesa knowledge. Sorry. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: Proposed mesa_7_5_branch and mesa_7_6_branch freeze for release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Whitwell wrote: > On Tue, 2009-09-22 at 13:46 -0700, Ian Romanick wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I would like to open XDC by shipping Mesa 7.5.2 and 7.6. In order to >> make that happen, I propose the following: >> >> - - Freeze both branches at 12:01AM PDT 9/25 (this upcoming Friday). >> >> - - I will tag both trees at that time. One will get mesa_7_5_2_rc1, and >> the other will get mesa_7_6_rc1. >> >> - - Once those tags appear, please test whatever drivers *you* care about >> on whatever platforms *you* care about. >> >> - - Report any new regressions to bugzilla. If you find something that >> you believe is an absolute show stopper, mark it as such. We'll discuss >> whether we want to block the releases for it. >> >> For 7.6, I want to set the bar for blocking the release very, very high. >> At least one distro really wants to use 7.6, and their freeze is >> perilously soon. IMO, pretty much only build failures or "7.6 make my >> computer catch on fire, but 7.5.1 does not" are blockers. >> >> I had intended to post this RFC quite some time ago, but life issues >> outside of $JOB have distracted me for the last few weeks. The time has >> just slipped by. Aside from the absurdly compressed schedule, this >> seems to be what most other projects do, and I think Mesa should to. >> We've partially done this in the past, but our process could use a >> little more, well, process. :) > > I like the idea of better defining what our releases mean and how we get > there, and doing this freeze now seems pragmatic. To be perfectly honest, I'm being a bit selfish. :) I want my QA to start their testing with the code that will hopefully be the release. Since they are in China, they have a big holiday starting October 1st. That gives them a hard limit on when they can start (and finish) testing. I was pretty sure that if I reminded people that we were intending to release at XDC there would be a pile of commits over the weekend. > However, next time round, a bit more time in the schedule would probably > be appreciated, so that people can schedule time for testing and/or > fixing the bugs that testing identify. Absolutely! In the next releases (both 7.6.1 and 7.7), I'm hoping we'll have some discussion about when the release candidates and freezes will happen. I had intended to have those discussions for this release. However, my wife broke her leg at the start of August, and in the process of taking care of her, the weeks just flew by. My brain still thinks it's August, not the last week of September. > If I understand things correctly, this is (or should be) the last 7.5.x > release, and that branch will more or less go to sleep after this? That's the intention. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq6bO8ACgkQX1gOwKyEAw/VGgCgh3BopVH92nloNiaZf80gswFZ Iy8AmgKqKITFkDlTiifQO3Fj9QJqLq9Q =jf4F -END PGP SIGNATURE- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] r600: add support for cube textures
On Wed, Sep 23, 2009 at 7:37 AM, Andre Maasikas wrote: > Needs quite a few extra instructions, please test/review > if I got them all right. > Looks good thanks! Alex -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: Proposed mesa_7_5_branch and mesa_7_6_branch freeze for release
Am Tuesday 22 September 2009 22:46:59 schrieb Ian Romanick: > I would like to open XDC by shipping Mesa 7.5.2 and 7.6. In order to > make that happen, I propose the following: > > - Freeze both branches at 12:01AM PDT 9/25 (this upcoming Friday). > > - I will tag both trees at that time. One will get mesa_7_5_2_rc1, and > the other will get mesa_7_6_rc1. > > - Once those tags appear, please test whatever drivers *you* care about > on whatever platforms *you* care about. > > - Report any new regressions to bugzilla. If you find something that > you believe is an absolute show stopper, mark it as such. We'll discuss > whether we want to block the releases for it. > > For 7.6, I want to set the bar for blocking the release very, very high. > At least one distro really wants to use 7.6, and their freeze is > perilously soon. IMO, pretty much only build failures or "7.6 make my > computer catch on fire, but 7.5.1 does not" are blockers. > > I had intended to post this RFC quite some time ago, but life issues > outside of $JOB have distracted me for the last few weeks. The time has > just slipped by. Aside from the absurdly compressed schedule, this > seems to be what most other projects do, and I think Mesa should to. > We've partially done this in the past, but our process could use a > little more, well, process. :) > > Opinions? What does freezing the trees mean, exactly? Only commit fixes for show-stopper bugs? I'm a bit unhappy about the extremely short time between rc1 and release; if I understand you correctly, you want to release 7.6 for XDC next week, so that gives only three days or so between the two. I've only got on the "test mesa_7_6_branch" bandwagon a short while ago, and I won't be available this weekend. I realize that the branch has existed for a longer time, so it's my own fault. In the future, perhaps it would be nice to have an rc1 pretty soon after the branch is created, as a kind of wake-up call to get testing for lazy people like myself. On the other hand, I believe the r300 driver is actually in rather good shape, so I'm not too worried. There are definitely some bugs that I would like to have seen fixed before 7.6, but I don't think they really qualify as show- stoppers. cu, Nicolai -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: Proposed mesa_7_5_branch and mesa_7_6_branch freeze for release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicolai Hähnle wrote: > Am Tuesday 22 September 2009 22:46:59 schrieb Ian Romanick: >> I would like to open XDC by shipping Mesa 7.5.2 and 7.6. In order to >> make that happen, I propose the following: >> >> - Freeze both branches at 12:01AM PDT 9/25 (this upcoming Friday). >> >> - I will tag both trees at that time. One will get mesa_7_5_2_rc1, and >> the other will get mesa_7_6_rc1. >> >> - Once those tags appear, please test whatever drivers *you* care about >> on whatever platforms *you* care about. >> >> - Report any new regressions to bugzilla. If you find something that >> you believe is an absolute show stopper, mark it as such. We'll discuss >> whether we want to block the releases for it. >> >> For 7.6, I want to set the bar for blocking the release very, very high. >> At least one distro really wants to use 7.6, and their freeze is >> perilously soon. IMO, pretty much only build failures or "7.6 make my >> computer catch on fire, but 7.5.1 does not" are blockers. >> >> I had intended to post this RFC quite some time ago, but life issues >> outside of $JOB have distracted me for the last few weeks. The time has >> just slipped by. Aside from the absurdly compressed schedule, this >> seems to be what most other projects do, and I think Mesa should to. >> We've partially done this in the past, but our process could use a >> little more, well, process. :) >> >> Opinions? > > What does freezing the trees mean, exactly? Only commit fixes for > show-stopper > bugs? That's the idea. > I'm a bit unhappy about the extremely short time between rc1 and release; if > I > understand you correctly, you want to release 7.6 for XDC next week, so that > gives only three days or so between the two. I've only got on the "test > mesa_7_6_branch" bandwagon a short while ago, and I won't be available this > weekend. I realize that the branch has existed for a longer time, so it's my > own fault. No, you and Keith are 100% correct. This is rubbish, and it's my fault for falling asleep at the wheel. That's also why the subject is "proposed". > In the future, perhaps it would be nice to have an rc1 pretty soon after the > branch is created, as a kind of wake-up call to get testing for lazy people > like myself. It seems like the right answer is to decide on a schedule when the branch is created. That may include an RC really soon, or it may not. I think we can cross that bridge when we come to it. I completely agree that collectively deciding on the release schedule in advance is the right thing. > On the other hand, I believe the r300 driver is actually in rather good > shape, > so I'm not too worried. There are definitely some bugs that I would like to > have seen fixed before 7.6, but I don't think they really qualify as show- > stoppers. It seems like there has a lot of good stabilization work on the drivers that people care about. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq6vVgACgkQX1gOwKyEAw9e3wCfdrJjgIrzsRRCKWHN4mutNtk2 xDQAn1ygJBHKMeaaF9f7f9bfzqyI0V5J =f0ix -END PGP SIGNATURE- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
