[Mesa3d-dev] [Bug 24365] New: [7.6] glxinfo: main/context.c:640: check_context_limits: Assertion failed
http://bugs.freedesktop.org/show_bug.cgi?id=24365 Summary: [7.6] glxinfo: main/context.c:640: check_context_limits: Assertion failed Product: Mesa Version: unspecified Platform: Other URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550011 OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: brice.gog...@ens-lyon.org A user with a R423 and mesa 7.6 reports: Simply running glxinfo produces following: deepf...@betelheise:~$ glxinfo name of display: :0.0 glxinfo: main/context.c:640: check_context_limits: Assertion `ctx->Const.MaxTextureCoordUnits <= ctx->Const.MaxTextureImageUnits' failed. Aborted -- 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(R) 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/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/4] Speed up _glapi_add_dispatch.
On Tue, Oct 06, 2009 at 12:16:26PM -0600, tom fogal wrote:
> > Also, MANGLE was not and is not supported here on non-x86 platforms
> > because of glprocs.h.
> Hrm? I might have recently broken our AIX support, then..
I must have been thinking something else. It should not. Sorry for the
confusion.
> > > > -entry[i]->parameter_signature = str_dup(real_sig);
> > > > -fill_in_entrypoint_offset(entry[i]->dispatch_stub, offset);
> > > > -entry[i]->dispatch_offset = offset;
> > > > + if (entry[i] == NULL) {
> > > > +entry[i] = _glapi_add_dynamic_entry(function_names[i]);
> > > > +if (entry[i] == NULL) {
> > > > + /* FIXME: Possible memory leak here.
> > > > + */
> > >
> > > What's leaked? You've simply copied/maintained the existing
> > > comment; presumably you know what's going on here now and could
> > > expand on the comment.
> >
> > The error is that, there might already be some dynamic dispatches
> > generated when we bail out. The generated dynamic dispatches are
> > useable. It can be considered a leak or not.
> >
> > This patch is about refactoring. I do not intend to introduce
> > functional changes if possible. If I do, I will try to document it.
>
> Sorry, I didn't mean to imply that you should fix the leak. I did mean
> to imply that it would be nice if you could update the comment from
> `possible memory leak' to `we might be leaking any dispatches that were
> generated above by returning here w/o cleaning them up' (or similar).
I will update the comments.
>
> > > Secondly, any chance of using stdlib's bsearch here?
> >
> > I just had a look at _mesa_bsearch. It seems bsearch is not
> > universally available? I think the inline version is also slightly
> > faster.
> I would bet a custom binary search would outperform any bsearch call,
> because there's always going to be a need for a function pointer in the
> latter. My preference is still on reusing the existing infrastructure,
> until a demonstrated performance benefit justifies not doing so.
My concern was not true. I am switching to bsearch().
> Anyway, regardless of which way some of these decisions go, this looks
> good to me / your responses have convinced me. I've also applied it
> and got one of my dynamic loading test programs to work.
> Signed-off-by: Tom Fogal
> FWIW.
>
> -tom
--
Regards,
olv
--
Come build with us! The BlackBerry(R) 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/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 18613] new account on fd.o
http://bugs.freedesktop.org/show_bug.cgi?id=18613 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #7 from Eric Anholt 2009-10-06 20:19:36 PST --- Closing due to required information not being supplied. Please re-open if you're still interested in getting an account and provide the AccountRequests information. -- 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(R) 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/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 20498] I'd like to have git commit access to freedesktop.org
http://bugs.freedesktop.org/show_bug.cgi?id=20498 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from Eric Anholt 2009-10-06 20:18:44 PST --- Required information never supplied. -- 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(R) 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/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 21334] I would like a new account to publish a new gprof project
http://bugs.freedesktop.org/show_bug.cgi?id=21334 Daniel Stone changed: What|Removed |Added AssignedTo|sitewrangl...@lists.freedesk|mesa3d- |top.org |d...@lists.sourceforge.net Component|New Accounts|Other Product|freedesktop.org |Mesa --- Comment #2 from Daniel Stone 2009-10-06 20:11:10 PST --- brian, is this ok? the uprof part looks fine by me, but you'll want to approve the mesa part. -- 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(R) 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/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 20498] I'd like to have git commit access to freedesktop.org
http://bugs.freedesktop.org/show_bug.cgi?id=20498 Daniel Stone changed: What|Removed |Added AssignedTo|sitewrangl...@lists.freedesk|mesa3d- |top.org |d...@lists.sourceforge.net Component|CVS |Other Product|freedesktop.org |Mesa --- Comment #4 from Daniel Stone 2009-10-06 20:03:33 PST --- can anyone from mesa approve this application or otherwise? -- 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(R) 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/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/4] Speed up _glapi_add_dispatch.
On Tue, Oct 06, 2009 at 11:09:46AM -0700, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Chia-I Wu wrote: > > On Mon, Oct 05, 2009 at 11:16:17AM -0600, tom fogal wrote: > >> Chia-I Wu writes: > >>> +#ifdef USE_X86_ASM > >>> +extern const GLubyte gl_dispatch_functions_start[]; > >>> +#endif > > There is no functional change here. The original code reads > > > > -#ifdef USE_X86_ASM > > - > > -#if defined( GLX_USE_TLS ) > > -extern GLubyte gl_dispatch_functions_start[]; > > -extern GLubyte gl_dispatch_functions_end[]; > > -#else > > -extern const GLubyte gl_dispatch_functions_start[]; > > -#endif > > - > > -#endif /* USE_X86_ASM */ > > > > Since gl_dispatch_functions_end is never used, and > > gl_dispatch_functions_start is never modified, they are simplified. > But gl_dispatch_funcitons_start is declared (in the assembly stub file) > differently in these cases. Now the extern doesn't match the declaration. I will change it to #if defined(GLX_USE_TLS) && !defined(GLX_X86_READONLY_TEXT) extern GLubyte gl_dispatch_functions_start[]; #else extern const GLubyte gl_dispatch_functions_start[]; #endif But I am curious about the difference. I mean, gl_dispatch_functions_start is no more than a symbol. There is no C declaration associated with it. Isn't it just fine to have glapi_getproc.c treat it as a constant array of bytes, even when it is modifiable? > > I just had a look at _mesa_bsearch. It seems bsearch is not universally > > available? I think the inline version is also slightly faster. > Madness. bsearch has been part of standard C since 1989. We can be > pretty sure that the implementation of bsearch, qsort, and others in the > C library have been thoroughly debugged. I think that peace of mind is > worth more that the small speed-up gained by open coding. Thanks for pointing out. I will update this part. I wanted to switch to bsearch() when Tom pointed out. The #ifdef in _mesa_bsearch() sort of stopped me. -- Regards, olv -- Come build with us! The BlackBerry(R) 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/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 18613] new account on fd.o
http://bugs.freedesktop.org/show_bug.cgi?id=18613 Daniel Stone changed: What|Removed |Added AssignedTo|sitewrangl...@lists.freedesk|mesa3d- |top.org |d...@lists.sourceforge.net Component|New Accounts|Other Product|freedesktop.org |Mesa --- Comment #6 from Daniel Stone 2009-10-06 19:55:34 PST --- brian or anyone else -- ping? -- 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(R) 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/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] shader_api: Fix bounds checking of glUniform and glUniformMatrix
Am Tuesday 06 October 2009 20:29:00 schrieb Ian Romanick:
> Nicolai Hähnle wrote:
> > glUniformMatrix() with too large count parameter could previously lead to
> > memory corruption.
>
> Is there a piglit test for this? I imagine calling it with count ==
> INT_MAX should crash fairly reliably. :)
Yes, though now that you mention INT_MAX, it should probably be tweaked for
that :}
Will do.
> > Signed-off-by: Nicolai Hähnle
>
> Reviewed-by: Ian Romanick
>
> > ---
> > src/mesa/shader/shader_api.c | 29 +
> > 1 files changed, 21 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/mesa/shader/shader_api.c b/src/mesa/shader/shader_api.c
> > index 6b19b4c..fbd995e 100644
> > --- a/src/mesa/shader/shader_api.c
> > +++ b/src/mesa/shader/shader_api.c
> > @@ -1707,7 +1707,7 @@ set_program_uniform(GLcontext *ctx, struct
> > gl_program *program,
> >}
> >else {
> > /* non-array: count must be one */
> > - if (count != 1) {
> > + if (count > 1) {
> > _mesa_error(ctx, GL_INVALID_OPERATION,
> > "glUniform(uniform is not an array)");
> > return;
>
> I'd update the comment here too. I had to look at the code to verify
> that count == 0 was handled correctly.
Okay.
--
Come build with us! The BlackBerry(R) 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/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] shader_api: Fix bounds checking of glUniform and glUniformMatrix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicolai Hähnle wrote:
> glUniformMatrix() with too large count parameter could previously lead to
> memory corruption.
Is there a piglit test for this? I imagine calling it with count ==
INT_MAX should crash fairly reliably. :)
> Signed-off-by: Nicolai Hähnle
Reviewed-by: Ian Romanick
> ---
> src/mesa/shader/shader_api.c | 29 +
> 1 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/shader/shader_api.c b/src/mesa/shader/shader_api.c
> index 6b19b4c..fbd995e 100644
> --- a/src/mesa/shader/shader_api.c
> +++ b/src/mesa/shader/shader_api.c
> @@ -1707,7 +1707,7 @@ set_program_uniform(GLcontext *ctx, struct gl_program
> *program,
>}
>else {
> /* non-array: count must be one */
> - if (count != 1) {
> + if (count > 1) {
> _mesa_error(ctx, GL_INVALID_OPERATION,
> "glUniform(uniform is not an array)");
> return;
I'd update the comment here too. I had to look at the code to verify
that count == 0 was handled correctly.
> @@ -1884,20 +1884,27 @@ set_program_uniform_matrix(GLcontext *ctx, struct
> gl_program *program,
> GLboolean transpose, const GLfloat *values)
> {
> GLuint mat, row, col;
> - GLuint dst = index + offset, src = 0;
> + GLuint src = 0;
> + const struct gl_program_parameter * param = &program->Parameters-
>> Parameters[index];
> + const GLint slots = (param->Size + 3) / 4;
> + const GLint typeSize = sizeof_glsl_type(param->DataType);
> GLint nr, nc;
>
> /* check that the number of rows, columns is correct */
> - get_matrix_dims(program->Parameters->Parameters[index].DataType, &nr,
> &nc);
> + get_matrix_dims(param->DataType, &nr, &nc);
> if (rows != nr || cols != nc) {
>_mesa_error(ctx, GL_INVALID_OPERATION,
>"glUniformMatrix(matrix size mismatch)");
>return;
> }
>
> - if (index + offset > program->Parameters->Size) {
> - /* out of bounds! */
> - return;
> + if (param->Size <= typeSize) {
> + /* non-array: count must be one */
> + if (count > 1) {
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "glUniformMatrix(uniform is not an array)");
> + return;
> + }
> }
>
> /*
> @@ -1911,7 +1918,12 @@ set_program_uniform_matrix(GLcontext *ctx, struct
> gl_program *program,
>
>/* each matrix: */
>for (col = 0; col < cols; col++) {
> - GLfloat *v = program->Parameters->ParameterValues[dst];
> + GLfloat *v;
> + if (offset >= slots) {
> +/* Ignore writes beyond the end of (the used part of) an array */
> +return;
> + }
> + v = program->Parameters->ParameterValues[index + offset];
> for (row = 0; row < rows; row++) {
> if (transpose) {
> v[row] = values[src + row * cols + col];
> @@ -1920,7 +1932,8 @@ set_program_uniform_matrix(GLcontext *ctx, struct
> gl_program *program,
> v[row] = values[src + col * rows + row];
> }
> }
> - dst++;
> +
> + offset++;
>}
>
>src += rows * cols; /* next matrix */
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrLjGsACgkQX1gOwKyEAw8sRwCfQ5U12Nv+RD3xnGyw2ZczNVji
9zEAnjyzCl3wuUbPUzQZHwMK4TOhy6v3
=7KI0
-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
[Mesa3d-dev] [PATCH] Regenerate gl_mangle.h.
Attached. -tom From 87ce26ad777157de905c33d24e4b24ba09dd9c90 Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Tue, 6 Oct 2009 12:16:39 -0600 Subject: [PATCH] Regenerate gl_mangle.h. --- include/GL/gl_mangle.h | 42 ++ 1 files changed, 42 insertions(+), 0 deletions(-) diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h index 54147f7..59f6149 100644 --- a/include/GL/gl_mangle.h +++ b/include/GL/gl_mangle.h @@ -108,12 +108,20 @@ #define glBlendColorEXT MANGLE(BlendColorEXT) #define glBlendColor MANGLE(BlendColor) #define glBlendEquationEXT MANGLE(BlendEquationEXT) +#define glBlendEquationi MANGLE(BlendEquationi) +#define glBlendEquationIndexedAMD MANGLE(BlendEquationIndexedAMD) #define glBlendEquation MANGLE(BlendEquation) #define glBlendEquationSeparateATI MANGLE(BlendEquationSeparateATI) #define glBlendEquationSeparateEXT MANGLE(BlendEquationSeparateEXT) +#define glBlendEquationSeparatei MANGLE(BlendEquationSeparatei) +#define glBlendEquationSeparateIndexedAMD MANGLE(BlendEquationSeparateIndexedAMD) #define glBlendEquationSeparate MANGLE(BlendEquationSeparate) +#define glBlendFunci MANGLE(BlendFunci) +#define glBlendFuncIndexedAMD MANGLE(BlendFuncIndexedAMD) #define glBlendFunc MANGLE(BlendFunc) #define glBlendFuncSeparateEXT MANGLE(BlendFuncSeparateEXT) +#define glBlendFuncSeparatei MANGLE(BlendFuncSeparatei) +#define glBlendFuncSeparateIndexedAMD MANGLE(BlendFuncSeparateIndexedAMD) #define glBlendFuncSeparateINGR MANGLE(BlendFuncSeparateINGR) #define glBlendFuncSeparate MANGLE(BlendFuncSeparate) #define glBlitFramebufferEXT MANGLE(BlitFramebufferEXT) @@ -148,6 +156,7 @@ #define glClientActiveTexture MANGLE(ClientActiveTexture) #define glClientActiveVertexStreamATI MANGLE(ClientActiveVertexStreamATI) #define glClientAttribDefaultEXT MANGLE(ClientAttribDefaultEXT) +#define glClientWaitSync MANGLE(ClientWaitSync) #define glClipPlane MANGLE(ClipPlane) #define glColor3b MANGLE(Color3b) #define glColor3bv MANGLE(Color3bv) @@ -320,6 +329,7 @@ #define glDeleteRenderbuffersEXT MANGLE(DeleteRenderbuffersEXT) #define glDeleteRenderbuffers MANGLE(DeleteRenderbuffers) #define glDeleteShader MANGLE(DeleteShader) +#define glDeleteSync MANGLE(DeleteSync) #define glDeleteTexturesEXT MANGLE(DeleteTexturesEXT) #define glDeleteTextures MANGLE(DeleteTextures) #define glDeleteTransformFeedbacksNV MANGLE(DeleteTransformFeedbacksNV) @@ -341,6 +351,7 @@ #define glDisableIndexedEXT MANGLE(DisableIndexedEXT) #define glDisable MANGLE(Disable) #define glDisableVariantClientStateEXT MANGLE(DisableVariantClientStateEXT) +#define glDisableVertexAttribAPPLE MANGLE(DisableVertexAttribAPPLE) #define glDisableVertexAttribArrayARB MANGLE(DisableVertexAttribArrayARB) #define glDisableVertexAttribArray MANGLE(DisableVertexAttribArray) #define glDrawArraysEXT MANGLE(DrawArraysEXT) @@ -354,7 +365,9 @@ #define glDrawBuffers MANGLE(DrawBuffers) #define glDrawElementArrayAPPLE MANGLE(DrawElementArrayAPPLE) #define glDrawElementArrayATI MANGLE(DrawElementArrayATI) +#define glDrawElementsBaseVertex MANGLE(DrawElementsBaseVertex) #define glDrawElementsInstancedARB MANGLE(DrawElementsInstancedARB) +#define glDrawElementsInstancedBaseVertex MANGLE(DrawElementsInstancedBaseVertex) #define glDrawElementsInstancedEXT MANGLE(DrawElementsInstancedEXT) #define glDrawElementsInstanced MANGLE(DrawElementsInstanced) #define glDrawElements MANGLE(DrawElements) @@ -362,6 +375,7 @@ #define glDrawPixels MANGLE(DrawPixels) #define glDrawRangeElementArrayAPPLE MANGLE(DrawRangeElementArrayAPPLE) #define glDrawRangeElementArrayATI MANGLE(DrawRangeElementArrayATI) +#define glDrawRangeElementsBaseVertex MANGLE(DrawRangeElementsBaseVertex) #define glDrawRangeElementsEXT MANGLE(DrawRangeElementsEXT) #define glDrawRangeElements MANGLE(DrawRangeElements) #define glDrawTransformFeedbackNV MANGLE(DrawTransformFeedbackNV) @@ -378,6 +392,7 @@ #define glEnableIndexedEXT MANGLE(EnableIndexedEXT) #define glEnable MANGLE(Enable) #define glEnableVariantClientStateEXT MANGLE(EnableVariantClientStateEXT) +#define glEnableVertexAttribAPPLE MANGLE(EnableVertexAttribAPPLE) #define glEnableVertexAttribArrayARB MANGLE(EnableVertexAttribArrayARB) #define glEnableVertexAttribArray MANGLE(EnableVertexAttribArray) #define glEndConditionalRender MANGLE(EndConditionalRender) @@ -409,6 +424,7 @@ #define glExecuteProgramNV MANGLE(ExecuteProgramNV) #define glExtractComponentEXT MANGLE(ExtractComponentEXT) #define glFeedbackBuffer MANGLE(FeedbackBuffer) +#define glFenceSync MANGLE(FenceSync) #define glFinalCombinerInputNV MANGLE(FinalCombinerInputNV) #define glFinishAsyncSGIX MANGLE(FinishAsyncSGIX) #define glFinishFenceAPPLE MANGLE(FinishFenceAPPLE) @@ -469,9 +485,11 @@ #define glFramebufferTextureEXT MANGLE(FramebufferTextureEXT) #define glFramebufferTextureFaceARB MANGLE(FramebufferTextureFaceARB) #define glFramebuf
Re: [Mesa3d-dev] [PATCH 0/4] Speed up _glapi_add_dispatch.
Chia-I Wu writes:
> On Mon, Oct 05, 2009 at 11:16:17AM -0600, tom fogal wrote:
> > Chia-I Wu writes:
> > > The third patch fixes a potential segfault. Calling a dynamic
> > > dispatch which is not supported by a DRI driver would crash an
> > > application. It is a bug of the application, since it should
> > > test the corresponding extension before calling such functions.
> > > But it is a simple fix to make such functions become no-op, just
> > > any static function that is not supported by the DRI driver.
> >
> > IMHO, an app *should* segfault in this case. It's a big red "you
> > have a bug" flag for developers, and I have definitely found it
> > useful at times.
>
> When glFooBar is never being SET_FooBar in mesa, it is dispatched to
> generic_nop. The change is mainly to make a dynamic dispatch behave
> exactly the same way. You can see the warnings when MESA_DEBUG is
> set.
>
> Having it crash is helpful sometimes, but it is less OpenGL-ism IMHO.
While I agree MESA_DEBUG is useful to me, a user emailing me saying
that "your application crashed" gets me to the problem a lot quicker
than "the window stays white; nothing ever renders into it".
Seems like this is a matter of opinion at this point, so maybe we
should just let Brian / whoever will commit it decide.
> Also, MANGLE was not and is not supported here on non-x86 platforms
> because of glprocs.h.
Hrm? I might have recently broken our AIX support, then..
> > > +static void
> > > +_glapi_update_dynamic_entry(struct _glapi_function *entry, GLuint offset,
> > >
> > > +const char *parameter_signature)
> > > +{
> > > + if (entry->parameter_signature)
> > > + free((char *) entry->parameter_signature);
> >
> > If we need to cast away the constness of parameter_signature ... maybe
> > parameter_signature should not point to something which is const.
>
> The const-ness is a hint that no function should modify the value
> directly. It can be modified only through the update function.
>
> But I am fine either way. I just feel like to keep the patch simpler.
Again, sounds like a decision not to be made by either of us.
Regardless, I think you're right that it belongs in a separate patch.
> > > - entry[i]->parameter_signature = str_dup(real_sig);
> > > - fill_in_entrypoint_offset(entry[i]->dispatch_stub, offset);
> > > - entry[i]->dispatch_offset = offset;
> > > + if (entry[i] == NULL) {
> > > +entry[i] = _glapi_add_dynamic_entry(function_names[i]);
> > > +if (entry[i] == NULL) {
> > > + /* FIXME: Possible memory leak here.
> > > + */
> >
> > What's leaked? You've simply copied/maintained the existing
> > comment; presumably you know what's going on here now and could
> > expand on the comment.
>
> The error is that, there might already be some dynamic dispatches
> generated when we bail out. The generated dynamic dispatches are
> useable. It can be considered a leak or not.
>
> This patch is about refactoring. I do not intend to introduce
> functional changes if possible. If I do, I will try to document it.
Sorry, I didn't mean to imply that you should fix the leak. I did mean
to imply that it would be nice if you could update the comment from
`possible memory leak' to `we might be leaking any dispatches that were
generated above by returning here w/o cleaning them up' (or similar).
> > Secondly, any chance of using stdlib's bsearch here?
>
> I just had a look at _mesa_bsearch. It seems bsearch is not
> universally available? I think the inline version is also slightly
> faster.
I would bet a custom binary search would outperform any bsearch call,
because there's always going to be a need for a function pointer in the
latter. My preference is still on reusing the existing infrastructure,
until a demonstrated performance benefit justifies not doing so.
Anyway, regardless of which way some of these decisions go, this looks
good to me / your responses have convinced me. I've also applied it
and got one of my dynamic loading test programs to work.
Signed-off-by: Tom Fogal
FWIW.
-tom
--
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/4] Speed up _glapi_add_dispatch.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chia-I Wu wrote:
> On Mon, Oct 05, 2009 at 11:16:17AM -0600, tom fogal wrote:
>> Chia-I Wu writes:
>>> +#ifdef USE_X86_ASM
>>> +extern const GLubyte gl_dispatch_functions_start[];
>>> +#endif
>> I'm a little concerned that something like this is changing. Your
>> introductory comment doesn't mention anything about modifying anything
>> to do with the dispatch itself; it seems like a table is changing from
>> an unordered -> ordered, and an algorithm from linear search -> binary
>> search. Thus changing the declaration type / decl. location of the
>> table itself doesn't seem like it would happen.
> There is no functional change here. The original code reads
>
> -#ifdef USE_X86_ASM
> -
> -#if defined( GLX_USE_TLS )
> -extern GLubyte gl_dispatch_functions_start[];
> -extern GLubyte gl_dispatch_functions_end[];
> -#else
> -extern const GLubyte gl_dispatch_functions_start[];
> -#endif
> -
> -#endif /* USE_X86_ASM */
>
> Since gl_dispatch_functions_end is never used, and
> gl_dispatch_functions_start is never modified, they are simplified.
But gl_dispatch_funcitons_start is declared (in the assembly stub file)
differently in these cases. Now the extern doesn't match the declaration.
>>> + GLuint lo, hi;
>>> +
>>> + /* binary search */
>>> + lo = 0;
>>> + hi = ARRAY_SIZE(sorted_static_function_offsets);
>>> + while (lo < hi) {
>>> + const glprocs_table_t *entry;
>>> + GLuint mid = (lo + hi) / 2;
>>> + int res;
>>> +
>>> + entry = &static_functions[sorted_static_function_offsets[mid]];
>>> + res = strcmp(_glapi_static_entry_name(entry), funcName);
>> This might be okay, but I don't want to scroll all the way up to check,
>> especially since I might have snipped it ;) Anyway, either this strcmp
>> should have a MANGLE case or _glapi_static_entry_name should always
>> return "glWhatever" even when the symbol is "mglWhatever".
> That would be the latter case.
>> Secondly, any chance of using stdlib's bsearch here?
> I just had a look at _mesa_bsearch. It seems bsearch is not universally
> available? I think the inline version is also slightly faster.
Madness. bsearch has been part of standard C since 1989. We can be
pretty sure that the implementation of bsearch, qsort, and others in the
C library have been thoroughly debugged. I think that peace of mind is
worth more that the small speed-up gained by open coding.
I strongly recommend you pick up a copy of Jon Bentley's "Programming
Pearls" and read chapter 2. It looks like part of the chapter, starting
with page 11, is available on Google books. See also:
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrLh+YACgkQX1gOwKyEAw+zYwCeKpoonWXZ70FyUxWmKRn2bE4G
AF8An0IsArTI0bGyZ8tlXOv0pjATpZZU
=ZnPv
-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
[Mesa3d-dev] [Bug 24321] glXQueryExtension doesn't set eventBase and errorBase
http://bugs.freedesktop.org/show_bug.cgi?id=24321 --- Comment #2 from Brian Paul 2009-10-06 08:29:10 PST --- Created an attachment (id=30111) --> (http://bugs.freedesktop.org/attachment.cgi?id=30111) return 0 for errorBase and eventBase Does this patch help you? -- 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
[Mesa3d-dev] [Bug 24321] glXQueryExtension doesn't set eventBase and errorBase
http://bugs.freedesktop.org/show_bug.cgi?id=24321 --- Comment #1 from Brian Paul 2009-10-06 08:28:33 PST --- I'm guessing that you're using the "fake" GLX library and not the real GLX library. When you're using fake GLX we're just emulating the GLX library so the errorbase and eventbase values are meaningless. I guess we could set them to zero. I'll attach a patch. -- 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
[Mesa3d-dev] [Bug 24320] glXQueryDrawable returns 0 for all attributes except GLX_FBCONFIG_ID
http://bugs.freedesktop.org/show_bug.cgi?id=24320 --- Comment #1 from Brian Paul 2009-10-06 08:23:09 PST --- One quick thing to check: Do you have GLX 1.3 or later? glXQueryDrawable() is a 1.3 function. Run 'glxinfo' and check the "GLX version" line. -- 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
[Mesa3d-dev] [Bug 24342] "bad target in _mesa_select_tex_object()" when using glXBindTexImageEXT
http://bugs.freedesktop.org/show_bug.cgi?id=24342 Mauro Iazzi changed: What|Removed |Added CC||mauro.ia...@gmail.com -- 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
[Mesa3d-dev] [Bug 24342] New: "bad target in _mesa_select_tex_object()" when using glXBindTexImageEXT
http://bugs.freedesktop.org/show_bug.cgi?id=24342 Summary: "bad target in _mesa_select_tex_object()" when using glXBindTexImageEXT Product: Mesa Version: 7.5 Platform: Other OS/Version: All Status: NEW Severity: minor Priority: medium Component: GLX AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: mauro.ia...@gmail.com the above error is triggered using glXBindTexImageEXT on a glxpixmap that was created without GLX_TEXTURE_TARGET_EXT. It claims an implementation error, though that path should not be hit in correct code. the error was tested on archlinux with intel drivers. I was able to duplicate the error with a slight modification of the texture_from_pixmap demo. -- 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
