[Mesa-dev] [Bug 39537] New: Build error at get vlVaGetVtable
https://bugs.freedesktop.org/show_bug.cgi?id=39537
Summary: Build error at get vlVaGetVtable
Product: Mesa
Version: git
Platform: Other
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: ad...@heiher.info
>From ac5c4c49e38b57a47b8dda0e77312ea6e4e7f99d Mon Sep 17 00:00:00 2001
From: Heiher
Date: Tue, 26 Jul 2011 16:11:30 +0800
Subject: [PATCH] Fix vlVaGetVtable
---
src/gallium/state_trackers/va/ftab.c |4 ++--
src/gallium/state_trackers/va/va_private.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/va/ftab.c
b/src/gallium/state_trackers/va/ftab.c
index dc9513e..b2545e9 100644
--- a/src/gallium/state_trackers/va/ftab.c
+++ b/src/gallium/state_trackers/va/ftab.c
@@ -130,7 +130,7 @@ static struct VADriverVTable vtable =
NULL /* struct VADriverVTableGLX *glx; "Optional" */
};
-struct VADriverVTable vlVaGetVtable()
+struct VADriverVTable * vlVaGetVtable()
{
- return vtable;
+ return &vtable;
}
diff --git a/src/gallium/state_trackers/va/va_private.h
b/src/gallium/state_trackers/va/va_private.h
index f1023db..a382e05 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -61,7 +61,7 @@ typedef struct {
VAStatus __vaDriverInit_0_31 (VADriverContextP ctx);
// Private functions:
-struct VADriverVTable vlVaGetVtable();
+struct VADriverVTable * vlVaGetVtable();
bool vlCreateHTAB(void);
void vlDestroyHTAB(void);
--
1.7.2.3
--
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 39537] Build error at get vlVaGetVtable
https://bugs.freedesktop.org/show_bug.cgi?id=39537 Christian König changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG Severity|normal |enhancement CC||deathsim...@vodafone.de --- Comment #1 from Christian König 2011-07-26 04:37:08 PDT --- The va state tracker currently compiles only with VAAPI Version 0.31. There is a check for that in configure.ac, your patch makes the state tracker build with VAAPI 0.32, but also breaks building with VAAPI 0.31. If you want to really fix that (which would be very welcome), you need to add something like: #if VA_CHECK_VERSION(0,32,0) ... #else ... #endif So please fix your patch and resubmit it to the mailing list. Thanks, Christian. -- 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] RC3 build problem
Line 1243 of configure.ac says if test "x$enable_dri" = xyes; then and enable_dri is nowhere defined. In RC2 the equivalent line said if test "$mesa_driver" = dri; then I do not know what the appropriate test is. This results in gbm_dri not being compiled, results in gbm_dri_backend not being defined, results in applications not starting because the .so won't load successfully. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): configure.ac: don' t build gallium driver libs just to see if there are no errors
On 26/07/2011 00:16, Marek Olšák wrote: sorry for the late reply. I have just sent a patch to ML which should fix this. See: http://lists.freedesktop.org/archives/mesa-dev/2011-July/009867.html Please let me know if that works for you. Yes, that fixes it. Thanks very much :-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: fix xlib-based softpipe build
On 26/07/2011 00:12, Marek Olšák wrote: --- configure.ac | 12 +--- 1 files changed, 5 insertions(+), 7 deletions(-) Tested-by: Jon TURNEY ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Make Gallium drivers respect the force_s3tc_enable environment variable
On Mon, Jul 25, 2011 at 1:50 PM, Jose Fonseca wrote: > I have no objection FWIW. > > Jose > > - Original Message - >> This is a revised version of my previous patches. Patch 1 >> incorporates >> Brian's feedback, and patch 2 is unchanged from before. I did test >> patch 2 >> without patch 1, and found that both patches are neeeded for >> force_s3tc_enable >> to work. >> >> Both of these are candidates for 7.10 and 7.11, since games such as 0 >> A.D. >> expect drivers to support this. >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > Can I go ahead and push these patches this afternoon if there are no objections? Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] softpipe: When doing write_all_cbufs, don't stomp over the color.
On 07/25/2011 04:39 PM, Eric Anholt wrote:
We have to make it through this loop processing the color multiple
times, so we can't go overwriting it on our first color buffer.
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c
b/src/gallium/drivers/softpipe/sp_quad_blend.c
index 82f9785..c881194 100644
--- a/src/gallium/drivers/softpipe/sp_quad_blend.c
+++ b/src/gallium/drivers/softpipe/sp_quad_blend.c
@@ -817,17 +817,25 @@ blend_fallback(struct quad_stage *qs,
quads[0]->input.y0);
boolean has_dst_alpha
= util_format_has_alpha(softpipe->framebuffer.cbufs[cbuf]->format);
- uint q, i, j, qbuf;
-
- qbuf = write_all ? 0 : cbuf;
+ uint q, i, j;
for (q = 0; q< nr; q++) {
struct quad_header *quad = quads[q];
float (*quadColor)[4];
+ float temp_quad_color[QUAD_SIZE][4];
const int itx = (quad->input.x0& (TILE_SIZE-1));
const int ity = (quad->input.y0& (TILE_SIZE-1));
- quadColor = quad->output.color[qbuf];
+ if (write_all) {
+for (j = 0; j< QUAD_SIZE; j++) {
+ for (i = 0; i< 4; i++) {
+ temp_quad_color[i][j] = quad->output.color[0][i][j];
+ }
+}
I wonder if memcpy(temp_quad_color, quad->output.color[0]) would be
faster. No biggie.
+quadColor = temp_quad_color;
+ } else {
+quadColor = quad->output.color[cbuf];
+ }
/* get/swizzle dest colors
*/
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/8] mesa: Fix ff fragment shader inputs calculation when enabling a VS.
On 07/25/2011 04:39 PM, Eric Anholt wrote:
The FF VS generation happens just after the FF FS generation in
state.c, so the ctx->VP._Current value is for the previous state
update's vertex shader, not the one that will be chosen as a result of
this state update. The vertexShader and vertexProgram variables
should be accurately telling us whether there's going to be a
ctx->VP._Current (except on _MaintainTnlProgram drivers, where it's
always true).
---
src/mesa/main/ff_fragment_shader.cpp |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
index 0b53c28..dbfa6b5 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -330,8 +330,7 @@ static GLbitfield get_fp_input_mask( struct gl_context *ctx
)
/* _NEW_RENDERMODE */
fp_inputs = (FRAG_BIT_COL0 | FRAG_BIT_TEX0);
}
- else if (!(vertexProgram || vertexShader) ||
-!ctx->VertexProgram._Current) {
+ else if (!(vertexProgram || vertexShader)) {
/* Fixed function vertex logic */
/* _NEW_ARRAY */
GLbitfield varying_inputs = ctx->varying_vp_inputs;
This kind of change always requires thorough testing, but anyway:
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Make Gallium drivers respect the force_s3tc_enable environment variable
On 07/26/2011 07:30 AM, Bryan Cain wrote: On Mon, Jul 25, 2011 at 1:50 PM, Jose Fonseca wrote: I have no objection FWIW. Jose - Original Message - This is a revised version of my previous patches. Patch 1 incorporates Brian's feedback, and patch 2 is unchanged from before. I did test patch 2 without patch 1, and found that both patches are neeeded for force_s3tc_enable to work. Both of these are candidates for 7.10 and 7.11, since games such as 0 A.D. expect drivers to support this. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev Can I go ahead and push these patches this afternoon if there are no objections? I think so. I still haven't found time to dig into this myself. We can try to simplify things at a later time. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 release candidate 3
On Mon, Jul 25, 2011 at 9:54 PM, Ian Romanick wrote: > The only changes in the 7.11 branch (until the final release) should be > low-risk fixes for significant bugs. Other than updates to the release > notes and changing the version, RC3 should represent 7.11 final. Would my patches for making Gallium drivers respect force_s3tc_enable qualify? They are very low-risk, and fix https://bugs.freedesktop.org/show_bug.cgi?id=29012. I don't know what qualifies as a "significant bug", but the fix makes at least one game (fs2_open) work out of the box with Gallium drivers that didn't before. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 release candidate 3
On Tue, Jul 26, 2011 at 11:05 AM, Bryan Cain wrote: > On Mon, Jul 25, 2011 at 9:54 PM, Ian Romanick wrote: >> The only changes in the 7.11 branch (until the final release) should be >> low-risk fixes for significant bugs. Other than updates to the release >> notes and changing the version, RC3 should represent 7.11 final. > > Would my patches for making Gallium drivers respect force_s3tc_enable > qualify? They are very low-risk, and fix > https://bugs.freedesktop.org/show_bug.cgi?id=29012. I don't know what > qualifies as a "significant bug", but the fix makes at least one game > (fs2_open) work out of the box with Gallium drivers that didn't > before. Seems ok to me. Alex > > Bryan > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RC3 build problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/26/2011 05:52 AM, Marty Jack wrote: > Line 1243 of configure.ac says > if test "x$enable_dri" = xyes; then > and enable_dri is nowhere defined. In RC2 the equivalent line said > if test "$mesa_driver" = dri; then > I do not know what the appropriate test is. > > This results in gbm_dri not being compiled, results in gbm_dri_backend not > being defined, results in applications not starting because the .so won't > load successfully. Does building Mesa master work? It sounds like some configure.ac patches still need to be picked over. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4u8jgACgkQX1gOwKyEAw/vMACfe4B0ArHZ01Fhuj7D1MQONdOO CmkAniirISFoaU3xM+c3+bz5M1LPF06E =GSzE -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] mesa: Call updated_drawbuffers() if the buffer count changes in _mesa_drawbuffers().
On 26 July 2011 02:21, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/25/2011 01:23 PM, Henri Verbeet wrote:
>> Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
>> {COLOR0}, {COLOR0, COLOR1}.
>
> Is there a piglit test to reproduce this failure?
>
No, I found this using the Wine D3D tests. I can easily write one though.
On 26 July 2011 04:29, Eric Anholt wrote:
> Ah, I see. I like this better than setting remaining buffers to NONE.
> (and with this patch, we could avoid doing so, right?).
>
Yeah. As a follow up we can probably also get rid of setting the
remaining buffers to NONE in the n != 1 path, unless there's code that
doesn't check _NumColorDrawBuffers. Such code would currently break on
the n == 1 path as well though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
On 07/26/2011 01:49 AM, Roland Scheidegger wrote: > (Strange thought sent that before - mail client going crazy...) > >> Resolving color buffers is pretty well defined (for standard msaa at >> least). I have no idea how that's supposed to be defined for depth >> and stencil values. Frankly I'm not sure what glBlitFramebuffer is >> supposed to do here, maybe it's defined somewhere but even applying >> the term "resolve" to a depth buffer seems very iffy. At the very >> least it needs to be documented in the gallium docs what "resolving" >> a depth/stencil buffer really means. > > Hmm actually it must be like ReadPixels. So it is "recommended" that > implementations just use the centermost sample, but this is not required. In > particular "any function using depth/stencil values" is valid. > Taking this to the extreme, this means just returning 0 is valid (f = > 0*sample0 + 0*sample1...) though probably not recommended... > Averaging would be allowed as would be any other crazy stuff. In any case > calling this step, whatever it does, "resolve" seems abusive with results > possibly quite implementation dependent. I have no idea what nv50 does here > though I guess given the loose definition it should certainly fit the > requirements. > But that's great, it means drivers can't do anything wrong here. And either way, GL demands that you can "resolve" it so you better support it. nv50 gallium would follow the behaviour of the binary driver, which is take the value from a single sample. Should hw for some reason not be able to do this (I can't imagine how), well, they can return black. Or whatever the st would do instead. Now again about the rest of the new arguments: pipe_resource *aux (from my first reply): The are multisampling implementations that store extra sample data required for resolve in a separate buffer, nv's coverage sampling for example. I think the pipe driver can store a link to such a buffer in the associated colour resource, so, forget about that one. Now the important ones: mask: If depth resolve is supported, you are not allowed to clobber stencil. You have to allow the pipe driver to not do double the work. dst_level: If the user resolves to the (n != 0)-th level of a texture, you certainly want this; doing an extra copy of several MiB only because you don't like the looks of an extra parameter in the function declaration is insane from any angle. dstx, dsty, box: BlitFramebuffer honours scissor state. What if the user is scissoring away half of the destination ? Do you really want to push through the other half, all that to temporary storage, and then again blit several MiB of data over, just because you don't like to clutter the interface ? yflip: When the user is able to resolve to the window system buffer (if mesa is kind enough to choose the same component ordering, or if the "same format" requirement is interpreted loosely - this is certainly possible with the binary drivers), then you have to do this flip. And you don't want to ALWAYS do double the work. You *really* do not. Not ! Christoph ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Ensure that r300 compiler files only appear once in the tarballs
From: Ian Romanick Cc: Jeremy Huddleston Cc: Andreas Radke --- Please let me know if this patch fixes the issue once and for all. Makefile |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index c142a93..48e779c 100644 --- a/Makefile +++ b/Makefile @@ -285,9 +285,6 @@ MAIN_FILES = \ $(DIRECTORY)/src/mesa/drivers/osmesa/descrip.mms\ $(DIRECTORY)/src/mesa/drivers/osmesa/osmesa.def \ $(DIRECTORY)/src/mesa/drivers/osmesa/*.[ch] \ - $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/*.[ch] \ - $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/Makefile\ - $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/SConscript \ $(DIRECTORY)/src/mesa/drivers/windows/*/*.[ch] \ $(DIRECTORY)/src/mesa/drivers/windows/*/*.def \ $(DIRECTORY)/src/mesa/drivers/x11/Makefile \ @@ -393,6 +390,7 @@ DRI_FILES = \ $(DIRECTORY)/src/mesa/drivers/dri/*/*/*.[chS] \ $(DIRECTORY)/src/mesa/drivers/dri/*/Makefile\ $(DIRECTORY)/src/mesa/drivers/dri/*/*/Makefile \ + $(DIRECTORY)/src/mesa/drivers/dri/*/*/SConscript\ $(DIRECTORY)/src/mesa/drivers/dri/*/Doxyfile SGI_GLU_FILES = \ -- 1.7.4.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3 v2] i965: Check actual tile offsets in Gen4 miptree workaround.
On 07/25/2011 05:06 PM, Kenneth Graunke wrote:
> The apitrace dump in bug #34009 managed to fool the draw_offset check
> into thinking that we were tile aligned when we weren't. This led to an
> assertion failure in brw_update_renderbuffer_surface with tile_y != 0.
>
> Simply compute tile_x and tile_y and check those, as that way both
> places are checking the same thing.
>
> NOTE: This is a candidate for stable release branches.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34009
> Cc: Chad Versace
> Cc: Eric Anholt
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/intel/intel_fbo.c | 28 ++--
> 1 files changed, 26 insertions(+), 2 deletions(-)
>
> v2 doesn't break the faked packed/depth stencil on Ivybridge (there is no
> irb->region on the wrapper), and introduces a function (since I need to add
> more conditions in a third patch.)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
> b/src/mesa/drivers/dri/intel/intel_fbo.c
> index 35be325..90bfe96 100644
> --- a/src/mesa/drivers/dri/intel/intel_fbo.c
> +++ b/src/mesa/drivers/dri/intel/intel_fbo.c
> @@ -647,6 +647,22 @@ intel_renderbuffer_tile_offsets(struct
> intel_renderbuffer *irb,
> }
> }
>
> +#ifndef I915
> +static bool
> +need_tile_offset_workaround(struct brw_context *brw,
> + struct intel_renderbuffer *irb)
> +{
> + uint32_t tile_x, tile_y;
> +
> + intel_renderbuffer_tile_offsets(irb, &tile_x, &tile_y);
> +
> + if (!brw->has_surface_tile_offset)
> + return tile_x != 0 || tile_y != 0;
> +
> + return false;
> +}
> +#endif
> +
> /**
> * Called by glFramebufferTexture[123]DEXT() (and other places) to
> * prepare for rendering into texture memory. This might be called
> @@ -699,9 +715,17 @@ intel_render_texture(struct gl_context * ctx,
> intel_renderbuffer_set_draw_offset(irb, intel_image, att->Zoffset);
> intel_image->used_as_render_target = GL_TRUE;
>
> + bool is_depthbuffer = irb->Base._BaseFormat == GL_DEPTH_COMPONENT ||
> + irb->Base._BaseFormat == GL_DEPTH_STENCIL;
> +
> + /* Resolve combined depth/stencil wrapper to get at the real depth buffer.
> +* Notably, we don't need the original irb after this point.
> +*/
> + if (is_depthbuffer)
> + irb = intel_get_renderbuffer(fb, BUFFER_DEPTH);
> +
> #ifndef I915
> - if (!brw_context(ctx)->has_surface_tile_offset &&
> - (irb->draw_offset & 4095) != 0) {
Why did you remove `(irb->draw_offset & 4095) != 0`? It's not evident from the
patch.
> + if (need_tile_offset_workaround(brw_context(ctx), irb)) {
>/* Original gen4 hardware couldn't draw to a non-tile-aligned
> * destination in a miptree unless you actually setup your
> * renderbuffer as a miptree and used the fragile
--
Chad Versace
c...@chad-versace.us
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Firefox driver detection: happy ending, Gallium drivers no longer blacklisted
Hi List, This is just some good news. Recently, I wrote to this list [1] announcing that as of Firefox 6, we were able to safely detect driver versions, and consequently many recent system, including Mesa >= 7.10, were whitelisted. At that time, unfortunately, we were blacklisting Gallium. The good news is that as of Firefox 7, Gallium is no longer blacklisted. While we do hit a bug with Gallium as explained in [1], it's turned out to not be more severe than many other bugs that exist in all drivers. The other bit of good news is that our biggest remaining source of GLX-related crashes (really X errors) has been fixed, it was really a bug on our side [2] debugged thanks to APItrace and Jose Fonseca [3]. Thanks, Benoit PS. Regarding OpenGL-accelerated compositing in Firefox on X11, this is still disabled by default but will hopefully be turned on by default for Firefox circa 8-9. [1] http://lists.freedesktop.org/archives/mesa-dev/2011-May/007428.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c76 and 79 [3] https://bugs.freedesktop.org/show_bug.cgi?id=38312#c21 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39570] New: glx-multithread lock during piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=39570 Summary: glx-multithread lock during piglit test Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: xodd...@gmail.com Created an attachment (id=49587) --> (https://bugs.freedesktop.org/attachment.cgi?id=49587) glx-multithread_backtrace sometime, during piglit test the glx-multithread doesn't finish. PS: The last time I had the problem, i run piglit test on a Ubuntu 11.04 with kernel 3.0. Glxinfo say : OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD REDWOOD OpenGL version string: 2.1 Mesa 7.12-devel (git-b189d16) OpenGL shading language version string: 1.20 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Ensure that r300 compiler files only appear once in the tarballs
That looks like it: Reviewed-by: Jeremy Huddleston Tested-by: Jeremy Huddleston You can probably revert the --dereference one as well. On Jul 26, 2011, at 12:09 PM, Ian Romanick wrote: > From: Ian Romanick > > Cc: Jeremy Huddleston > Cc: Andreas Radke > --- > Please let me know if this patch fixes the issue once and for all. > > Makefile |4 +--- > 1 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index c142a93..48e779c 100644 > --- a/Makefile > +++ b/Makefile > @@ -285,9 +285,6 @@ MAIN_FILES = \ > $(DIRECTORY)/src/mesa/drivers/osmesa/descrip.mms\ > $(DIRECTORY)/src/mesa/drivers/osmesa/osmesa.def \ > $(DIRECTORY)/src/mesa/drivers/osmesa/*.[ch] \ > - $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/*.[ch] \ > - $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/Makefile\ > - $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/SConscript \ > $(DIRECTORY)/src/mesa/drivers/windows/*/*.[ch] \ > $(DIRECTORY)/src/mesa/drivers/windows/*/*.def \ > $(DIRECTORY)/src/mesa/drivers/x11/Makefile \ > @@ -393,6 +390,7 @@ DRI_FILES = \ > $(DIRECTORY)/src/mesa/drivers/dri/*/*/*.[chS] \ > $(DIRECTORY)/src/mesa/drivers/dri/*/Makefile\ > $(DIRECTORY)/src/mesa/drivers/dri/*/*/Makefile \ > + $(DIRECTORY)/src/mesa/drivers/dri/*/*/SConscript\ > $(DIRECTORY)/src/mesa/drivers/dri/*/Doxyfile > > SGI_GLU_FILES = \ > -- > 1.7.4.4 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] glsl: Document parameters_lists_match()
The function's parameter do not indicate which parameter list belongs to
the function signature and which is the actual parameter list. So clarify
this in a Doxygen comment.
Signed-off-by: Chad Versace
---
src/glsl/ir_function.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
index 0f2f1a0..6795988 100644
--- a/src/glsl/ir_function.cpp
+++ b/src/glsl/ir_function.cpp
@@ -85,6 +85,12 @@ type_compare(const glsl_type *a, const glsl_type *b)
}
+/**
+ * Called by matching_signature().
+ *
+ * \param list_a Parameters of the function definition.
+ * \param list_b Actual parameters passed to the function.
+ */
static int
parameter_lists_match(const exec_list *list_a, const exec_list *list_b)
{
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] glsl: Clarify and document type_compare()
The parameters were named 'a' and 'b', but there was no documentation
indicating which was being converted to which. So rename 'a' -> 'to' and
'b' -> 'from'.
Also add a Doxygen comment.
Signed-off-by: Chad Versace
---
src/glsl/ir_function.cpp | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
index 6795988..e6ba359 100644
--- a/src/glsl/ir_function.cpp
+++ b/src/glsl/ir_function.cpp
@@ -24,29 +24,36 @@
#include "glsl_types.h"
#include "ir.h"
+/**
+ * \brief Check if an implicit type conversion is possible.
+ *
+ * Called by type_compare().
+ *
+ * \return If conversion is possible, 1. Else, -1.
+ */
int
-type_compare(const glsl_type *a, const glsl_type *b)
+type_compare(const glsl_type *to, const glsl_type *from)
{
/* If the types are the same, they trivially match.
*/
- if (a == b)
+ if (to == from)
return 0;
- switch (a->base_type) {
+ switch (to->base_type) {
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
case GLSL_TYPE_BOOL:
/* There is no implicit conversion to or from integer types or bool.
*/
- if ((a->is_integer() != b->is_integer())
- || (a->is_boolean() != b->is_boolean()))
+ if ((to->is_integer() != from->is_integer())
+ || (to->is_boolean() != from->is_boolean()))
return -1;
/* FALLTHROUGH */
case GLSL_TYPE_FLOAT:
- if ((a->vector_elements != b->vector_elements)
- || (a->matrix_columns != b->matrix_columns))
+ if ((to->vector_elements != from->vector_elements)
+ || (to->matrix_columns != from->matrix_columns))
return -1;
return 1;
@@ -58,8 +65,8 @@ type_compare(const glsl_type *a, const glsl_type *b)
return -1;
case GLSL_TYPE_ARRAY:
- if ((b->base_type != GLSL_TYPE_ARRAY)
- || (a->length != b->length))
+ if ((from->base_type != GLSL_TYPE_ARRAY)
+ || (to->length != from->length))
return -1;
/* From GLSL 1.50 spec, page 27 (page 33 of the PDF):
@@ -68,7 +75,7 @@ type_compare(const glsl_type *a, const glsl_type *b)
* If the comparison of the array element types detects that a conversion
* would be required, the array types do not match.
*/
- return (type_compare(a->fields.array, b->fields.array) == 0) ? 0 : -1;
+ return (type_compare(to->fields.array, from->fields.array) == 0) ? 0 :
-1;
case GLSL_TYPE_VOID:
case GLSL_TYPE_ERROR:
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glsl: Fix illegal implicit type conversions in type_compare()
type_compare() allowed the following illegal implicit conversions:
bool -> float
bvecN -> vecN
Fixes Piglit tests
spec/glsl-1.20/compiler/built-in-functions/outerProduct-bvec*.vert.
Note: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Chad Versace
---
src/glsl/ir_function.cpp | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
index e6ba359..2abc7aa 100644
--- a/src/glsl/ir_function.cpp
+++ b/src/glsl/ir_function.cpp
@@ -45,18 +45,23 @@ type_compare(const glsl_type *to, const glsl_type *from)
case GLSL_TYPE_BOOL:
/* There is no implicit conversion to or from integer types or bool.
*/
- if ((to->is_integer() != from->is_integer())
- || (to->is_boolean() != from->is_boolean()))
+ if (to->base_type == from->base_type
+ && to->vector_elements == from->vector_elements
+ && to->matrix_columns == from->matrix_columns) {
+return 1;
+ } else {
return -1;
-
- /* FALLTHROUGH */
+ }
case GLSL_TYPE_FLOAT:
- if ((to->vector_elements != from->vector_elements)
- || (to->matrix_columns != from->matrix_columns))
+ /* Integer types can be implicity converted to float. */
+ if ((from->base_type == GLSL_TYPE_FLOAT || from->is_integer())
+ && to->vector_elements == from->vector_elements
+ && to->matrix_columns == from->matrix_columns) {
+return 1;
+ } else {
return -1;
-
- return 1;
+ }
case GLSL_TYPE_SAMPLER:
case GLSL_TYPE_STRUCT:
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
> On 07/26/2011 01:49 AM, Roland Scheidegger wrote: > > (Strange thought sent that before - mail client going crazy...) > > > >> Resolving color buffers is pretty well defined (for standard msaa > >> at > >> least). I have no idea how that's supposed to be defined for depth > >> and stencil values. Frankly I'm not sure what glBlitFramebuffer is > >> supposed to do here, maybe it's defined somewhere but even > >> applying > >> the term "resolve" to a depth buffer seems very iffy. At the very > >> least it needs to be documented in the gallium docs what > >> "resolving" > >> a depth/stencil buffer really means. > > > > Hmm actually it must be like ReadPixels. So it is "recommended" > > that implementations just use the centermost sample, but this is > > not required. In particular "any function using depth/stencil > > values" is valid. > > Taking this to the extreme, this means just returning 0 is valid (f > > = 0*sample0 + 0*sample1...) though probably not recommended... > > Averaging would be allowed as would be any other crazy stuff. In > > any case calling this step, whatever it does, "resolve" seems > > abusive with results possibly quite implementation dependent. I > > have no idea what nv50 does here though I guess given the loose > > definition it should certainly fit the requirements. > > > But that's great, it means drivers can't do anything wrong here. > > And either way, GL demands that you can "resolve" it so you better > support it. nv50 gallium would follow the behaviour of the binary > driver, which is take the value from a single sample. > Should hw for some reason not be able to do this (I can't imagine > how), > well, they can return black. Or whatever the st would do instead. If this is really useful to anyone, I agree we probably should be able to handle that in the driver (though using the name "resolve" for that operation still irks me but I could live with it). I'd like to hear from others though, certainly I don't really know if it's that useful. State tracker could resolve through using a shader (ok that requires d3d101 feature but it's likely generally a feature which is way more useful than any of this stuff), though certainly a driver could do that internally as well. > Now again about the rest of the new arguments: > > pipe_resource *aux (from my first reply): > The are multisampling implementations that store extra sample data > required for resolve in a separate buffer, nv's coverage sampling for > example. > I think the pipe driver can store a link to such a buffer in the > associated colour resource, so, forget about that one. Yes I think if it can be hidden it should be hidden, unless we've got some way to deal with such features in some good generic way (which seems hard to do though coverage sampling isn't so special anymore since AMD does the same too nowadays). > > Now the important ones: > > mask: If depth resolve is supported, you are not allowed to clobber > stencil. You have to allow the pipe driver to not do double the work. Yes. If we're going to support depth "resolve" there this should be included. > > dst_level: > If the user resolves to the (n != 0)-th level of a texture, you > certainly want this; doing an extra copy of several MiB only because > you > don't like the looks of an extra parameter in the function > declaration > is insane from any angle. Since source is always level 0, why would you want to resolve to a different than 0 level anyway? I cannot imagine why that would be useful. But maybe my imagination is limited. There's likely a reason d3d10 decided it didn't want to bother driver writers with this stuff... > > dstx, dsty, box: > BlitFramebuffer honours scissor state. What if the user is scissoring > away half of the destination ? Do you really want to push through the > other half, all that to temporary storage, and then again blit > several > MiB of data over, just because you don't like to clutter the > interface ? Seems an acceptable tradeoff to me if it's a rare case. It's not like the blit of half a buffer is going to kill your framerate anyway these days. But again I don't know if it's really used that way... Sort of reminds me of drivers which tried to scissor away things which weren't going to be visible on screen. Just made things way more complex with very little benefits. But well if you include any of these parameters you can just as well include dst_level too because it won't be a simple resolve-whole-surface anymore. > > yflip: > When the user is able to resolve to the window system buffer (if mesa > is > kind enough to choose the same component ordering, or if the "same > format" requirement is interpreted loosely - this is certainly > possible > with the binary drivers), then you have to do this flip. > And you don't want to ALWAYS do double the work. You *really* do not. > Not ! Yes, I said the yflip seemed the most useful to me. Hopefully you can actually make it without an additional copy...
[Mesa-dev] [Bug 39490] 7.11.RC2 configure doesn't let me disable gallium-llvm
https://bugs.freedesktop.org/show_bug.cgi?id=39490 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Marek Olšák 2011-07-26 17:22:12 PDT --- I have pushed the patch. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] glsl: Fix illegal implicit type conversions in type_compare()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/26/2011 04:08 PM, Chad Versace wrote:
> type_compare() allowed the following illegal implicit conversions:
> bool -> float
> bvecN -> vecN
>
> Fixes Piglit tests
> spec/glsl-1.20/compiler/built-in-functions/outerProduct-bvec*.vert.
Does this also fix array-ctor-implicit-conversion-bvec[234]-vec[234]?
It occurred to me the other day that these failures are probably related.
> Note: This is a candidate for the 7.10 and 7.11 branches.
> Signed-off-by: Chad Versace
> ---
> src/glsl/ir_function.cpp | 21 +
> 1 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
> index e6ba359..2abc7aa 100644
> --- a/src/glsl/ir_function.cpp
> +++ b/src/glsl/ir_function.cpp
> @@ -45,18 +45,23 @@ type_compare(const glsl_type *to, const glsl_type *from)
> case GLSL_TYPE_BOOL:
>/* There is no implicit conversion to or from integer types or bool.
> */
> - if ((to->is_integer() != from->is_integer())
> - || (to->is_boolean() != from->is_boolean()))
> + if (to->base_type == from->base_type
> + && to->vector_elements == from->vector_elements
> + && to->matrix_columns == from->matrix_columns) {
> + return 1;
> + } else {
>return -1;
> -
> - /* FALLTHROUGH */
> + }
>
> case GLSL_TYPE_FLOAT:
> - if ((to->vector_elements != from->vector_elements)
> - || (to->matrix_columns != from->matrix_columns))
> + /* Integer types can be implicity converted to float. */
> + if ((from->base_type == GLSL_TYPE_FLOAT || from->is_integer())
> + && to->vector_elements == from->vector_elements
> + && to->matrix_columns == from->matrix_columns) {
> + return 1;
> + } else {
>return -1;
> -
> - return 1;
> + }
>
> case GLSL_TYPE_SAMPLER:
> case GLSL_TYPE_STRUCT:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4vXy8ACgkQX1gOwKyEAw96hgCeKQiS0+fC6IV+NuEIwyr7kxZQ
YlAAmwTox4acBRuvQ5FTbRyaIZWPx6XJ
=QBlZ
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RC3 build problem
> -Original Message- > From: mesa-dev-bounces+jian.j.zhao=intel@lists.freedesktop.org > [mailto:mesa-dev-bounces+jian.j.zhao=intel@lists.freedesktop.org] On > Behalf Of Ian Romanick > Sent: Wednesday, July 27, 2011 12:59 AM > To: Marty Jack > Cc: =?windows-1252?Q?Kristian_H=F8gsber?=@freedesktop.org; > mesa-dev@lists.freedesktop.org > Subject: Re: [Mesa-dev] RC3 build problem > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/26/2011 05:52 AM, Marty Jack wrote: > > Line 1243 of configure.ac says > > if test "x$enable_dri" = xyes; then > > and enable_dri is nowhere defined. In RC2 the equivalent line said > > if test "$mesa_driver" = dri; then > > I do not know what the appropriate test is. > > > > This results in gbm_dri not being compiled, results in gbm_dri_backend not > being defined, results in applications not starting because the .so won't load > successfully. > > Does building Mesa master work? It sounds like some configure.ac > patches still need to be picked over. We can build mesa on both master branch(b189d1635d89cd7d900e8f9a5eed88d7dc0b46cb) and 7.11 branch(13d12b35e90e4c2e7ba3beb6b2cf7fff3c4429d5) with the arguments in the command autogen.sh --with-driver=dri --with-dri-drivers="i915 i965 swrast" --with-dri-driverdir=$INSTALL_ROOT/lib/dri --enable-gles1 --enable-gles2 --with-gallium-drivers= --enable-texture-float. Thanks. Best regards zhaojian > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4u8jgACgkQX1gOwKyEAw/vMACfe4B0ArHZ01Fhuj7D1MQO > NdOO > CmkAniirISFoaU3xM+c3+bz5M1LPF06E > =GSzE > -END PGP SIGNATURE- > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RC3 build problem
On 07/26/2011 09:52 PM, Zhao, Jian J wrote: >> -Original Message- >> From: mesa-dev-bounces+jian.j.zhao=intel@lists.freedesktop.org >> [mailto:mesa-dev-bounces+jian.j.zhao=intel@lists.freedesktop.org] On >> Behalf Of Ian Romanick >> Sent: Wednesday, July 27, 2011 12:59 AM >> To: Marty Jack >> Cc: =?windows-1252?Q?Kristian_H=F8gsber?=@freedesktop.org; >> mesa-dev@lists.freedesktop.org >> Subject: Re: [Mesa-dev] RC3 build problem >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 07/26/2011 05:52 AM, Marty Jack wrote: >>> Line 1243 of configure.ac says >>> if test "x$enable_dri" = xyes; then >>> and enable_dri is nowhere defined. In RC2 the equivalent line said >>> if test "$mesa_driver" = dri; then >>> I do not know what the appropriate test is. >>> >>> This results in gbm_dri not being compiled, results in gbm_dri_backend not >> being defined, results in applications not starting because the .so won't >> load >> successfully. >> >> Does building Mesa master work? It sounds like some configure.ac >> patches still need to be picked over. > > > We can build mesa on both master > branch(b189d1635d89cd7d900e8f9a5eed88d7dc0b46cb) and 7.11 > branch(13d12b35e90e4c2e7ba3beb6b2cf7fff3c4429d5) with the arguments in the > command autogen.sh --with-driver=dri --with-dri-drivers="i915 i965 swrast" > --with-dri-driverdir=$INSTALL_ROOT/lib/dri --enable-gles1 --enable-gles2 > --with-gallium-drivers= --enable-texture-float. Thanks. > > Best regards > zhaojian > >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk4u8jgACgkQX1gOwKyEAw/vMACfe4B0ArHZ01Fhuj7D1MQO >> NdOO >> CmkAniirISFoaU3xM+c3+bz5M1LPF06E >> =GSzE >> -END PGP SIGNATURE- >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > Once again, the problem does not occur at build time. libgbm.so built with the problematic if disabled: martyj:~/Build/Mesa-7.11-rc3/lib$ nm /usr/lib/libgbm.so | grep dri 17a0 t dri_bind_extensions 3ca8 d dri_core_extensions 1730 t dri_destroy 1b30 t dri_device_create 1ca0 t dri_fd_get_driver_name 1870 t dri_load_driver 1480 t dri_lookup_egl_image 3a60 d driver_map 3ca0 d gbm_dri_backend 15d0 t gbm_dri_bo_create 14e0 t gbm_dri_bo_create_from_egl_image 16f0 t gbm_dri_bo_destroy 3cc0 d gbm_dri_device_extensions 14b0 t gbm_dri_is_format_supported libgbm.so built from the RC3 tarball: martyj:~/Build/Mesa-7.11-rc3/lib$ nm libgbm.so | grep dri U gbm_dri_backend Result when running application with the faulty .so martyj:/usr/lib/gbm$ firefox /usr/lib/firefox-5.0.1/firefox-bin: symbol lookup error: /usr/lib/libgbm.so.1: undefined symbol: gbm_dri_backend ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] Fix implicit conversions
These fixes are candidates for the stable branches. Chad Versace (4): glsl: Document parameters_lists_match() glsl: Refactor ast_function.cpp:type_compare() into a glsl_type method glsl: Fix illegal implicit type conversions glsl: Fix implicit conversions in array constructors src/glsl/ast_function.cpp |4 +- src/glsl/glsl_types.cpp | 306 ++--- src/glsl/glsl_types.h | 11 ++ src/glsl/ir_function.cpp | 77 ++-- 4 files changed, 177 insertions(+), 221 deletions(-) -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] glsl: Document parameters_lists_match()
The function's parameter do not indicate which parameter list belongs to
the function signature and which is the actual parameter list. So clarify
this in a Doxygen comment.
Signed-off-by: Chad Versace
---
src/glsl/ir_function.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
index 0f2f1a0..6795988 100644
--- a/src/glsl/ir_function.cpp
+++ b/src/glsl/ir_function.cpp
@@ -85,6 +85,12 @@ type_compare(const glsl_type *a, const glsl_type *b)
}
+/**
+ * Called by matching_signature().
+ *
+ * \param list_a Parameters of the function definition.
+ * \param list_b Actual parameters passed to the function.
+ */
static int
parameter_lists_match(const exec_list *list_a, const exec_list *list_b)
{
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] glsl: Refactor ast_function.cpp:type_compare() into a glsl_type method
On a subsequent commit, ast_function_expression::hir() will need access to
type_compare(), but it is defined in a different file. So refactor
type_compare() into glsl_type::implicit_conversion_compare().
CC: Ian Romanick
Signed-off-by: Chad Versace
---
src/glsl/glsl_types.cpp | 304 ++
src/glsl/glsl_types.h| 11 ++
src/glsl/ir_function.cpp | 71 +--
3 files changed, 166 insertions(+), 220 deletions(-)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index a5e21bb..752c1af 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -36,84 +36,64 @@ hash_table *glsl_type::array_types = NULL;
hash_table *glsl_type::record_types = NULL;
void *glsl_type::mem_ctx = NULL;
-void
-glsl_type::init_ralloc_type_ctx(void)
-{
+void glsl_type::init_ralloc_type_ctx(void) {
if (glsl_type::mem_ctx == NULL) {
glsl_type::mem_ctx = ralloc_autofree_context();
assert(glsl_type::mem_ctx != NULL);
}
}
-glsl_type::glsl_type(GLenum gl_type,
-glsl_base_type base_type, unsigned vector_elements,
-unsigned matrix_columns, const char *name) :
- gl_type(gl_type),
- base_type(base_type),
- sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
- sampler_type(0),
- vector_elements(vector_elements), matrix_columns(matrix_columns),
- length(0)
-{
+glsl_type::glsl_type(GLenum gl_type, glsl_base_type base_type,
+ unsigned vector_elements, unsigned matrix_columns, const char *name) :
+ gl_type(gl_type), base_type(base_type), sampler_dimensionality(0),
sampler_shadow(
+ 0), sampler_array(0), sampler_type(0), vector_elements(
+ vector_elements), matrix_columns(matrix_columns), length(0) {
init_ralloc_type_ctx();
this->name = ralloc_strdup(this->mem_ctx, name);
/* Neither dimension is zero or both dimensions are zero.
*/
assert((vector_elements == 0) == (matrix_columns == 0));
- memset(& fields, 0, sizeof(fields));
+ memset(&fields, 0, sizeof(fields));
}
-glsl_type::glsl_type(GLenum gl_type,
-enum glsl_sampler_dim dim, bool shadow, bool array,
-unsigned type, const char *name) :
- gl_type(gl_type),
- base_type(GLSL_TYPE_SAMPLER),
- sampler_dimensionality(dim), sampler_shadow(shadow),
- sampler_array(array), sampler_type(type),
- vector_elements(0), matrix_columns(0),
- length(0)
-{
+glsl_type::glsl_type(GLenum gl_type, enum glsl_sampler_dim dim, bool shadow,
+ bool array, unsigned type, const char *name) :
+ gl_type(gl_type), base_type(GLSL_TYPE_SAMPLER), sampler_dimensionality(
+ dim), sampler_shadow(shadow), sampler_array(array), sampler_type(
+ type), vector_elements(0), matrix_columns(0), length(0) {
init_ralloc_type_ctx();
this->name = ralloc_strdup(this->mem_ctx, name);
- memset(& fields, 0, sizeof(fields));
+ memset(&fields, 0, sizeof(fields));
}
glsl_type::glsl_type(const glsl_struct_field *fields, unsigned num_fields,
-const char *name) :
- base_type(GLSL_TYPE_STRUCT),
- sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
- sampler_type(0),
- vector_elements(0), matrix_columns(0),
- length(num_fields)
-{
+ const char *name) :
+ base_type(GLSL_TYPE_STRUCT), sampler_dimensionality(0),
sampler_shadow(0), sampler_array(
+ 0), sampler_type(0), vector_elements(0), matrix_columns(0), length(
+ num_fields) {
unsigned int i;
init_ralloc_type_ctx();
this->name = ralloc_strdup(this->mem_ctx, name);
this->fields.structure = ralloc_array(this->mem_ctx,
-glsl_struct_field, length);
+glsl_struct_field, length);
for (i = 0; i < length; i++) {
this->fields.structure[i].type = fields[i].type;
this->fields.structure[i].name = ralloc_strdup(this->fields.structure,
-fields[i].name);
+ fields[i].name);
}
}
-static void
-add_types_to_symbol_table(glsl_symbol_table *symtab,
- const struct glsl_type *types,
- unsigned num_types, bool warn)
-{
+static void add_types_to_symbol_table(glsl_symbol_table *symtab,
+ const struct glsl_type *types, unsigned num_types, bool warn) {
(void) warn;
for (unsigned i = 0; i < num_types; i++) {
- symtab->add_type(types[i].name, & types[i]);
+ symtab->add_type(types[i].name, &types[i]);
}
}
-bool
-glsl_type::contains_sampler() const
-{
+bool glsl_type::contains_sampler() const {
if (this->is_array()) {
return this->fields.array->contains_sampler();
} else if (this->is_record()) {
@@ -127,84 +107,57 @@ glsl_type::contains_sampler() const
}
}
-void
-glsl_type::generate_100ES_types(glsl_symbol_table *symtab)
-{
+void glsl_type::generate_100ES_types(glsl_symbol_table *symtab) {
[Mesa-dev] [PATCH 3/4] glsl: Fix illegal implicit type conversions
glsl_type::implicit_conversion_compare() allowed the following illegal
implicit conversions:
bool -> float
bvecN -> vecN
int -> uint
ivecN -> uvecN
uint -> int
uvecN -> ivecN
Fixes Piglit
spec/glsl-1.20/compiler/built-in-functions/outerProduct-bvec*.vert.
If cherry-picked, the following commit is required:
glsl: Refactor ast_function.cpp:type_compare() into a glsl_type method
Note: This is a candidate for the 7.10 and 7.11 branches.
CC: Ian Romanick
Signed-off-by: Chad Versace
---
src/glsl/glsl_types.cpp | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 752c1af..dd62502 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -466,20 +466,22 @@ int glsl_type::implicit_conversion_compare(const
glsl_type *desired) const {
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
case GLSL_TYPE_BOOL:
- /* There is no implicit conversion to or from integer types or bool. */
- if ((this->is_integer() != desired->is_integer())
- || (this->is_boolean() != desired->is_boolean()))
+ /* There is no implicit conversion among any of the above types. */
+ if (this->base_type == desired->base_type
+ && this->vector_elements == desired->vector_elements
+ && this->matrix_columns == desired->matrix_columns)
+return 1;
+ else
return -1;
- /* FALLTHROUGH */
-
case GLSL_TYPE_FLOAT:
- if ((this->vector_elements != desired->vector_elements)
- || (this->matrix_columns != desired->matrix_columns))
+ if ((this->is_float() || this->is_integer())
+ && this->vector_elements == desired->vector_elements
+ && this->matrix_columns == desired->matrix_columns)
+return 1;
+ else
return -1;
- return 1;
-
case GLSL_TYPE_SAMPLER:
case GLSL_TYPE_STRUCT:
/* Samplers and structures must match exactly. */
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] glsl: Fix implicit conversions in array constructors
Array constructors obey narrower conversion rules than other constructors,
but process_array_constructor() was incorrectly applying the broader
rules. From page 33 (page 39 of the pdf) of the GLSL 1.20 spec, Section
5.4.4 Array Constructors:
Each argument must be the same type as the element type of the array,
or be a type that can be converted to the element type of the array
according to Section 4.1.10 “Implicit Conversions.”
Fixes Piglit
spec/glsl-1.20/compiler/structure-and-array-operations/array-ctor-implicit-conversion-bvec*-vec*.vert.
If cherry-picked, the following commits are required:
glsl: Refactor ast_function.cpp:type_compare() into a glsl_type method
glsl: Fix illegal implicit type conversions
Note: This is a candidate for the 7.10 and 7.11 branches.
CC: Ian Romanick
Signed-off-by: Chad Versace
---
src/glsl/ast_function.cpp |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index bdb73f4..77c236f 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -448,7 +448,9 @@ process_array_constructor(exec_list *instructions,
glsl_type::get_instance(GLSL_TYPE_FLOAT,
ir->type->vector_elements,
ir->type->matrix_columns);
-result = convert_component(ir, desired_type);
+if (ir->type->implicit_conversion_compare(desired_type) >= 0) {
+ result = convert_component(ir, desired_type);
+}
}
if (result->type != constructor_type->element_type()) {
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] glsl: Fix illegal implicit type conversions in type_compare()
On 07/26/2011 05:43 PM, Ian Romanick wrote: > On 07/26/2011 04:08 PM, Chad Versace wrote: >> type_compare() allowed the following illegal implicit conversions: >> bool -> float >> bvecN -> vecN > >> Fixes Piglit tests >> spec/glsl-1.20/compiler/built-in-functions/outerProduct-bvec*.vert. > > Does this also fix array-ctor-implicit-conversion-bvec[234]-vec[234]? > It occurred to me the other day that these failures are probably related. Those two sets of tests take very different code paths in doing the implicit conversions. They are not related. Nak this patch series. I've posted a new one that fixes both test sets. -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
