Re: [Mesa-dev] [PATCH] i965/Gen4: Zero extra coordinates for ir_tex
Does indeed fix 65236 -- will put the bugzilla reference in the commit. -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V3 3/5] i965 Gen4/5: clip: correctly handle flat varyings
+ for (i=0; i < c->vue_map.num_slots; i++) {
+ if (c->key.interpolation_mode[i] == INTERP_QUALIFIER_FLAT) {
+ printf("flatshaded: %d @ %d\n", i,
+ brw_vue_slot_to_offset(i));
Oops, that wasn't supposed to still be in there!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa Help
On 10/07/2013 3:20 PM, Andy Li wrote: Hello everyone, I have some questions regarding to OSMesa. I am currently working on a project which I have to use Mesa on an embedded system. My current goal is to port the base functions over to the embedded system, so that I can draw a line on a provided VGA screen. Since the embedded system I am using does not contain a GPU, therefore I have decided to use OSMesa for rendering process. I am wondering if there are any documentations/ specifications for OSMesa? Anyone know which are the base functions that OSMesa used for the rendering process? I have looked into src/mesa/swrast/s_lines.c and s_drawpix.c and trying to figure out how the code works, am I in the right direction? Moreover, for example, if I found a drawpix() function, how do I know if OSMesa actually used this function during rendering process? Is there any tool/debugger I can use to confirm my findings? Thank you for your time. Andy. See http://cgit.freedesktop.org/mesa/demos/tree/src/osdemos for example of using OSMesa. Regards, Jonathan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
On Friday 12 July 2013, Chad Versace wrote: > On 07/12/2013 12:25 PM, Fredrik Höglund wrote: > > On Friday 12 July 2013, Chad Versace wrote: > >> On 07/11/2013 10:18 PM, Paul Berry wrote: > >>> Another possibility that Chad suggested when I was talking to him this > >>> afternoon is to just just return BAD_MATCH if the client supplies the > >>> forward-compatibility flag when requesting a 3.0+ context. Rationale: > >>> Mesa > >>> doesn't really support the forward-compatibility flag anyhow (since the > >>> EGL > >>> and GLX front-ends just drop it on the floor), and besides we don't know > >>> of > >>> any shipping apps that require it (the flag is intended as a developer > >>> aid, > >>> so it's unlikely that published apps rely on it). I don't have a really > >>> strong opinion about is, so I'll let Chad weigh in if he wants to champion > >>> this alternative. > >> > >> Let's fix Mesa to simply emit EGL_BAD_MATCH if the user requests a forward- > >> compatible context. I don't believe we have the right balance of resources > >> and interest to properly implement and test support for the > >> forward-compatible > >> flag. No one users are asking for it, and it's likely nearly no one will > >> use it. > >> The future may change this situation, but that's a big 'may'. > > > > KWin always sets the forward-compatible bit in 4.11, but it's not too late > > to change that. It appears to be accepted by all implementations and has > > no negative side effects, so there was no compelling reason to leave it > > out in a release build. > > For what GL context versions does KWin set the forward-compatible bit? > For 3.0 only? For all versions >= 3.0? For that matter, what context > versions does KWin request? It first tries to create a 3.1 forward-compatible context. If that fails, it tries to create a context with the version set to 1.2, and without the forward-compatible bit set. There are currently no real functional differences between the 3.1 and the 2.x paths in KWin. The main motivation for adding the option to create a 3.1 context was the thinking at the time that Mesa would only enable threaded dispatch in a core context. > Why does KWin set the forward-compatible bit? There must be some motivation > for that, other than "the button is there so let's push it". It's to ensure that we're not using deprecated features in the 3.x paths, and more importantly that no one introduces new code that uses deprecated features. In practice it seems that both Mesa and the NVIDIA driver ignores the flag though, which I guess is a good reason not to set it. Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Reject VertexAttribPointer() with GL_BGRA and !normalized.
On Monday 15 July 2013, Kenneth Graunke wrote:
> Fixes Piglit's ARB_vertex_attrib_bgra/api-errors test.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/main/varray.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
> index 529d933..48f15bd 100644
> --- a/src/mesa/main/varray.c
> +++ b/src/mesa/main/varray.c
> @@ -463,6 +463,16 @@ _mesa_VertexAttribPointer(GLuint index, GLint size,
> GLenum type,
>return;
> }
>
> + /* From the GL_ARB_vertex_array_bgra specification:
> +* "The error INVALID_VALUE is generated by VertexAttribPointer if
> +* size is BGRA and normalized is FALSE."
> +*/
> + if (size == GL_BGRA && !normalized) {
> + _mesa_error(ctx, GL_INVALID_VALUE,
> + "glVertexAttribPointer(BGRA and !normalized)");
> + return;
> + }
> +
I think this code belongs in update_array(), since it already handles other
BGRA errors, and also checks if the extension is supported.
This also reminds me that we need to decide if we should make the error
code depend on the GL version and entry point.
Both OpenGL 3.3 and GL_ARB_vertex_attrib_binding changes the error code
to GL_INVALID_OPERATION. The extension only does it for the entry points
it adds.
I personally don't think it's worth adding the additional complexity for
that since the conditions under which the errors to be generated haven't
changed.
Fredrik
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66558] RS690: 3D artifacts when playing SuperTuxKart
https://bugs.freedesktop.org/show_bug.cgi?id=66558 --- Comment #8 from Marek Olšák --- Created attachment 82446 --> https://bugs.freedesktop.org/attachment.cgi?id=82446&action=edit possible fix Please try this patch. -- 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] [RFC] [PATCH 0/3] Introduce a new EGL/DRI extension for resource sharing with Open CL.
On 07/14/2013 11:46 PM, Zhigang Gong wrote: Hi Kristian, The OpenCL spec has one extension to support interoperation between OpenGL and OpenCL. The key requirement for this extension is to export an OpenGL resource (texture/buffer object/render buffer)'s internal attributes to the OpenCL's driver side. IMHO, to support that cl extension we may need to add a new extension to the EGL/DRI layer which let the OpenCL driver could use this interface to query the low level attributes of the resource from the mesa dri driver side. Thus I propose this extension as below: EGLAPI EGLBoolean EGLAPIENTRY eglAcquireResourceMESA(EGLDisplay dpy, EGLContext ctx, const EGLenum target, const EGLint *attrib_list, void * user_data); EGLAPI EGLBoolean EGLAPIENTRY eglReleaseResourceMESA(EGLDisplay dpy, EGLContext ctx, const EGLenum target, const EGLint *attrib_list); The first API is to acquire the specified resource and get the low level attribute back in the driver specified user_data structure. The OpenCL side could use this structure to create a correct buffer object in OpenCL domain. The eglAcquireResourceMESA will also implicitly increase the resoruce's reference counter. The second API is to be called when the resource is no longer be shared with Open CL domain. It will decrease the resource's reference counter. The following patchset is to implement this extension, and I also implemented the OpenCL side on Beignet's runtime library. The texture sharing part works fine. Any comments are welcome and if this new extension is not the right way to solve the original problem, please feel free to point it out and kindly guide which is the right way to implement the cl-gl interoperations. Thanks. Any new OpenGL extension should have a specification. You can find the OpenGL extension template at http://www.opengl.org/registry/doc/template.txt I can hardly guess what the two new functions do without documentation of their parameters and behaviour. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa Help
On 07/14/2013 09:34 PM, Andy Li wrote: > Hi, > > I have some questions on the OSMesa code. > As you suggested, I have continue looking into the swrast code. > However, I have trouble figuring out how the code works exactly. > Now I am now only focusing on the functions which draw lines. > As I look into s_lines.c, I saw the _swrast_choose_line(). > And depends on different cases, it will call > > _swrast_choose_aa_line_function(ctx) > or > USE(general_line) > or > USE(rgba_line) > or > USE(simple_no_z_rgba_line) > etc. > > The first thing I did is looking into the > _swrast_choose_aa_line_function() and it direct me to s_aaline.c > In that file, I saw the struct of LineInfo and other computation > functions for plane. > Then I looked at the _swrast_choose_aa_line_function() > > and when I saw the code: > swrast->Line = aa_general_rgba_line; > and > swrast->Line = aa_rgba_line; > > I am not sure what do they mean. And I won't be able to continue finding > useful info. aa_rgba_line() drawns a "simple" RGBA antialiased line while aa_general_rgba_line() also computes texture coords, fog coord, etc. > I think the main problem I am having is I am not sure what are the steps > OSMesa have to take in order to draw a line into the frame buffer. > Would you be able to explain a bit on that? (what are the steps OSMesa > have to take in order to draw a line into the frame buffer?) > Does drawing a line involve computing the plane? AA lines are drawn by drawing a quadrilateral and computing pixel coverage involves computing plane equations. > What do s_aaline.c and s_aalinetemp.h actually mean? the "temp" files contain template code that's re-used multiple times in the .c file. > What is USE(general_line) ? Where is USE() define? grep "define USE" src/mesa/swrast/*.[ch] > What is swrast->Line = aa_general_rgba_line;? swrast->Line is a function pointer that points to the current line drawing function. The function is chosen by examining current GL rasterization state. > Would you suggest any debugging tool for me so that I can trace which > functions are called while the program is running? > For example I have the code below: > glBegin(GL_LINES); > glVertex3f(0.0, 0.0, 0.0); > glVertex3f(15, 0, 0); > glEnd(); > Is there any debugging tool which can trace glVertex3f back in the > library and see how OSMesa works? > I have tried using gdb, however, it would only by-pass the call the go > to the next command. You'll need to build mesa for debugging (CFLAGS="-g -O0" --enable-debug). But I don't really have time to explain all the nuances of debugging/tracing in Mesa. I'm not sure that'd really help you anyway. In general, when you drawing points/lines/triangles the s_points.c or s_lines.c or s_triangle.c code winds up calling _swrast_write_rgba() span. This function does Z testing, texturing, stippling, etc before calling a "put_pixels" or "put_row" function. Those functions call a "pack" function to pack an array of RGBA ubyte/float values into the framebuffer. Packing involves converting a canonical RGBA format into a specific pixel format, like RGBA, or RGB565, etc. The color buffer address, stride, etc. is obtained earlier through a call to ctx->Driver.MapRenderbuffer(). In the case of OSMesa, the color buffer is ordinary malloc'd memory that the user allocated. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/8] Support of RENDER_TYPE property [1/6] Correct handling of RENDER_TYPE property.
The change is to correctly handle the value of renderType in both
fbconfig and context. Uses of renderType are commented, where needed,
to avoid confusion between the two types. The fact that float configs
can be only used for pbuffers is correctly addressed.
---
src/glx/dri2_glx.c |7 +++
src/glx/dri_glx.c |2 ++
src/glx/drisw_glx.c |5 +
src/glx/glxcmds.c |4 ++--
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 7ce5775..630dbd9 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -226,6 +226,8 @@ dri2_create_context(struct glx_screen *base,
return NULL;
}
+ pcp->base.renderType = renderType;
+
pcp->driContext =
(*psc->dri2->createNewContext) (psc->driScreen,
config->driConfig, shared, pcp);
@@ -311,6 +313,11 @@ dri2_create_context_attribs(struct glx_screen *base,
ctx_attribs[num_ctx_attribs++] = flags;
}
+ /* The renderType is retrieved from attribs, or set to default
+* of GLX_RGBA_TYPE.
+*/
+ pcp->base.renderType = renderType;
+
pcp->driContext =
(*psc->dri2->createContextAttribs) (psc->driScreen,
api,
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index ba8fda2..cc45734 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -602,6 +602,8 @@ dri_create_context(struct glx_screen *base,
return NULL;
}
+ pcp->base.renderType = renderType;
+
if (!XF86DRICreateContextWithConfig(psc->base.dpy, psc->base.scr,
config->base.visualID,
&pcp->hwContextID, &hwContext)) {
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 832e964..80ddf9c 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -401,6 +401,8 @@ drisw_create_context(struct glx_screen *base,
return NULL;
}
+ pcp->base.renderType = renderType;
+
pcp->driContext =
(*psc->core->createNewContext) (psc->driScreen,
config->driConfig, shared, pcp);
@@ -429,6 +431,7 @@ drisw_create_context_attribs(struct glx_screen *base,
uint32_t minor_ver = 1;
uint32_t major_ver = 0;
+ uint32_t renderType = GLX_RGBA_TYPE;
uint32_t flags = 0;
unsigned api;
int reset = __DRI_CTX_RESET_NO_NOTIFICATION;
@@ -479,6 +482,8 @@ drisw_create_context_attribs(struct glx_screen *base,
ctx_attribs[num_ctx_attribs++] = flags;
}
+ pcp->base.renderType = renderType;
+
pcp->driContext =
(*psc->swrast->createContextAttribs) (psc->driScreen,
api,
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 019165a..51b2237 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -354,7 +354,7 @@ glXCreateContext(Display * dpy, XVisualInfo * vis,
GLXContext shareList, Bool allowDirect)
{
struct glx_config *config = NULL;
- int renderType = 0;
+ int renderType = GLX_RGBA_TYPE;
#if defined(GLX_DIRECT_RENDERING) || defined(GLX_USE_APPLEGL)
struct glx_screen *const psc = GetGLXScreenConfigs(dpy, vis->screen);
@@ -1441,7 +1441,7 @@ glXImportContextEXT(Display *dpy, GLXContextID contextID)
numProps = nPropListBytes / (2 * sizeof(propList[0]));
share = None;
mode = NULL;
- renderType = 0;
+ renderType = GLX_RGBA_TYPE; /* By default, assume RGBA context */
pProp = propList;
for (i = 0, pProp = propList; i < numProps; i++, pProp += 2)
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/8] Support of RENDER_TYPE property [3/6] Changes to visual configs initialization.
The change is to correctly handle the value of renderType and
drawableType in fbconfig. This part modifies glXInitializeVisualConfigFromTags
to read the parameter value, or detect it if it's not there.
---
src/glx/glxext.c | 35 +++
src/mesa/drivers/x11/fakeglx.c |7 ++-
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index ef1e7ad..83580d4 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -337,6 +337,7 @@ __glXInitializeVisualConfigFromTags(struct glx_config *
config, int count,
Bool fbconfig_style_tags)
{
int i;
+ GLint renderType = 0;
if (!tagged_only) {
/* Copy in the first set of properties */
@@ -471,8 +472,8 @@ __glXInitializeVisualConfigFromTags(struct glx_config *
config, int count,
config->drawableType |= GLX_WINDOW_BIT | GLX_PIXMAP_BIT |
GLX_PBUFFER_BIT;
#endif
break;
- case GLX_RENDER_TYPE:
- config->renderType = *bp++;
+ case GLX_RENDER_TYPE: /* fbconfig render type bits */
+ renderType = *bp++;
break;
case GLX_X_RENDERABLE:
config->xRenderable = *bp++;
@@ -555,8 +556,34 @@ __glXInitializeVisualConfigFromTags(struct glx_config *
config, int count,
}
}
- config->renderType =
- (config->rgbMode) ? GLX_RGBA_BIT : GLX_COLOR_INDEX_BIT;
+ if (renderType) {
+ config->renderType = renderType;
+ config->floatMode = (renderType &
+ (GLX_RGBA_FLOAT_BIT_ARB|GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT)) ?
+ GL_TRUE : GL_FALSE;
+ } else if (!tagged_only) {
+ /* If there wasn't GLX_RENDER_TYPE property, set it based on
config->*Mode
+* It is not always explicit, but we have no other choice. We will not
know
+* if the float mode should be signed or unsigned, and we won't know if
+* the mode supports both integer and float RGBA. */
+ config->renderType =
+ ((config->floatMode==GL_TRUE) ? GLX_RGBA_FLOAT_BIT_ARB : 0) |
+ ((config->rgbMode==GL_TRUE && config->floatMode!=GL_TRUE) ?
GLX_RGBA_BIT : 0) |
+ ((config->rgbMode!=GL_TRUE) ? GLX_COLOR_INDEX_BIT : 0);
+ } else {
+ /* If there wasn't such property and we should return fbconfig with
only part of
+* properties set, then don't change (allow zero) renderType. This will
allow matching
+* the generated fbconfig with fbconfigs_compatible(), no matter which
flags are set
+* in the fbconfig being compared. */
+ }
+ /* cannot create window out of float fbconfigs, these are offscreen only */
+ if (config->floatMode == GL_TRUE) {
+ /* GLX_ARB_fbconfig_float specs:
+* Note that floating point rendering is only supported for
+* GLXPbuffer drawables.
+*/
+ config->drawableType &= ~(GLX_WINDOW_BIT|GLX_PIXMAP_BIT);
+ }
}
static struct glx_config *
diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c
index 969ee7d..7a2cfbe 100644
--- a/src/mesa/drivers/x11/fakeglx.c
+++ b/src/mesa/drivers/x11/fakeglx.c
@@ -1090,6 +1090,9 @@ choose_visual( Display *dpy, int screen, const int *list,
GLboolean fbConfig )
else if (*parselist & GLX_COLOR_INDEX_BIT) {
rgb_flag = GL_FALSE;
}
+else if (*parselist &
(GLX_RGBA_FLOAT_BIT_ARB|GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT)) {
+ rgb_flag = GL_TRUE;
+}
else if (*parselist == 0) {
rgb_flag = GL_TRUE;
}
@@ -1761,7 +1764,9 @@ get_config( XMesaVisual xmvis, int attrib, int *value,
GLboolean fbconfig )
case GLX_RENDER_TYPE_SGIX:
if (!fbconfig)
return GLX_BAD_ATTRIBUTE;
- if (xmvis->mesa_visual.rgbMode)
+ if (xmvis->mesa_visual.floatMode)
+*value = GLX_RGBA_FLOAT_BIT_ARB;
+ else if (xmvis->mesa_visual.rgbMode)
*value = GLX_RGBA_BIT;
else
*value = GLX_COLOR_INDEX_BIT;
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/8] Support of RENDER_TYPE property [2/6] Retrieving the value of RENDER_TYPE from GLX attribs array.
This change makes sure that context creation routines are provided
with the value of RENDER_TYPE retrieved from GLX attribs.
---
src/glx/dri2_glx.c |3 ++-
src/glx/dri_common.c |8
src/glx/dri_common.h |2 +-
src/glx/drisw_glx.c |2 +-
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 630dbd9..d60c675 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -258,6 +258,7 @@ dri2_create_context_attribs(struct glx_screen *base,
uint32_t minor_ver = 1;
uint32_t major_ver = 2;
+ uint32_t renderType = GLX_RGBA_TYPE;
uint32_t flags = 0;
unsigned api;
int reset = __DRI_CTX_RESET_NO_NOTIFICATION;
@@ -272,7 +273,7 @@ dri2_create_context_attribs(struct glx_screen *base,
/* Remap the GLX tokens to DRI2 tokens.
*/
if (!dri2_convert_glx_attribs(num_attribs, attribs,
-&major_ver, &minor_ver, &flags, &api, &reset,
+&major_ver, &minor_ver, &renderType, &flags,
&api, &reset,
error))
goto error_exit;
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 1bf20ec..7ab303e 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -456,14 +456,13 @@ driReleaseDrawables(struct glx_context *gc)
_X_HIDDEN bool
dri2_convert_glx_attribs(unsigned num_attribs, const uint32_t *attribs,
-unsigned *major_ver, unsigned *minor_ver,
+unsigned *major_ver, unsigned *minor_ver, int
*render_type,
uint32_t *flags, unsigned *api, int *reset,
unsigned *error)
{
unsigned i;
bool got_profile = false;
uint32_t profile;
- int render_type = GLX_RGBA_TYPE;
if (num_attribs == 0) {
*api = __DRI_API_OPENGL;
@@ -479,6 +478,7 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
uint32_t *attribs,
*major_ver = 1;
*minor_ver = 0;
+ *render_type = GLX_RGBA_TYPE;
*reset = __DRI_CTX_RESET_NO_NOTIFICATION;
for (i = 0; i < num_attribs; i++) {
@@ -497,7 +497,7 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
uint32_t *attribs,
got_profile = true;
break;
case GLX_RENDER_TYPE:
-render_type = attribs[i * 2 + 1];
+*render_type = attribs[i * 2 + 1];
break;
case GLX_CONTEXT_RESET_NOTIFICATION_STRATEGY_ARB:
switch (attribs[i * 2 + 1]) {
@@ -568,7 +568,7 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
uint32_t *attribs,
return false;
}
- if (*major_ver >= 3 && render_type == GLX_COLOR_INDEX_TYPE) {
+ if (*major_ver >= 3 && *render_type == GLX_COLOR_INDEX_TYPE) {
*error = __DRI_CTX_ERROR_BAD_FLAG;
return false;
}
diff --git a/src/glx/dri_common.h b/src/glx/dri_common.h
index 93cd744..86b0eba 100644
--- a/src/glx/dri_common.h
+++ b/src/glx/dri_common.h
@@ -71,7 +71,7 @@ extern void *driOpenDriver(const char *driverName);
extern bool
dri2_convert_glx_attribs(unsigned num_attribs, const uint32_t *attribs,
-unsigned *major_ver, unsigned *minor_ver,
+unsigned *major_ver, unsigned *minor_ver, int
*render_type,
uint32_t *flags, unsigned *api, int *reset,
unsigned *error);
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 80ddf9c..ef0e52b 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -447,7 +447,7 @@ drisw_create_context_attribs(struct glx_screen *base,
/* Remap the GLX tokens to DRI2 tokens.
*/
if (!dri2_convert_glx_attribs(num_attribs, attribs,
-&major_ver, &minor_ver, &flags, &api, &reset,
+&major_ver, &minor_ver, &renderType, &flags,
&api, &reset,
error))
return NULL;
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/8] Support of RENDER_TYPE property [5/6] Storing the RENDER_TYPE in indirect rendering.
The change allows to store RENDER_TYPE value in GLX context
when indirect rendering is in use.
---
src/glx/create_context.c |4 +++-
src/glx/glxclient.h |7 +++
src/glx/glxcmds.c|1 -
src/glx/indirect_glx.c | 23 ++-
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/src/glx/create_context.c b/src/glx/create_context.c
index a755e83..38e949a 100644
--- a/src/glx/create_context.c
+++ b/src/glx/create_context.c
@@ -84,7 +84,9 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig config,
#ifdef GLX_USE_APPLEGL
gc = applegl_create_context(psc, cfg, share, 0);
#else
- gc = indirect_create_context(psc, cfg, share, 0);
+ gc = indirect_create_context_attribs(psc, cfg, share, num_attribs,
+ (const uint32_t *) attrib_list,
+ &dummy_err);
#endif
}
diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index 3e9b730..fc8f31c 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -817,5 +817,12 @@ extern struct glx_context *
indirect_create_context(struct glx_screen *psc,
struct glx_config *mode,
struct glx_context *shareList, int renderType);
+extern struct glx_context *
+indirect_create_context_attribs(struct glx_screen *base,
+ struct glx_config *config_base,
+ struct glx_context *shareList,
+ unsigned num_attribs,
+ const uint32_t *attribs,
+ unsigned *error);
#endif /* !__GLX_client_h__ */
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 967dab3..99b0218 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -344,7 +344,6 @@ CreateContext(Display *dpy, int generic_id, struct
glx_config *config,
gc->share_xid = shareList ? shareList->xid : None;
gc->imported = GL_FALSE;
- gc->renderType = renderType;
return (GLXContext) gc;
}
diff --git a/src/glx/indirect_glx.c b/src/glx/indirect_glx.c
index ff869e2..fc5107d 100644
--- a/src/glx/indirect_glx.c
+++ b/src/glx/indirect_glx.c
@@ -32,6 +32,7 @@
#include "glapi.h"
#include "glxclient.h"
+#include "dri_common.h"
extern struct _glapi_table *__glXNewIndirectAPI(void);
@@ -362,6 +363,8 @@ indirect_create_context(struct glx_screen *psc,
gc->isDirect = GL_FALSE;
gc->vtable = &indirect_context_vtable;
state = calloc(1, sizeof(struct __GLXattributeRec));
+ gc->renderType = renderType;
+
if (state == NULL) {
/* Out of memory */
free(gc);
@@ -430,7 +433,7 @@ indirect_create_context(struct glx_screen *psc,
return gc;
}
-static struct glx_context *
+_X_HIDDEN struct glx_context *
indirect_create_context_attribs(struct glx_screen *base,
struct glx_config *config_base,
struct glx_context *shareList,
@@ -438,18 +441,28 @@ indirect_create_context_attribs(struct glx_screen *base,
const uint32_t *attribs,
unsigned *error)
{
+uint32_t minor_ver = 1;
+uint32_t major_ver = 2;
+uint32_t renderType = GLX_RGBA_TYPE;
+uint32_t flags = 0;
+unsigned api;
+int reset = __DRI_CTX_RESET_NO_NOTIFICATION;
/* All of the attribute validation for indirect contexts is handled on the
-* server, so there's not much to do here.
+* server, so there's not much to do here. Still, we need to parse the
attributes
+* to correctly set renderType.
*/
- (void) num_attribs;
- (void) attribs;
+if (!dri2_convert_glx_attribs(num_attribs, attribs,
+ &major_ver, &minor_ver, &renderType, &flags,
+ &api, &reset, error)) {
+return NULL;
+}
/* The error parameter is only used on the server so that correct GLX
* protocol errors can be generated. On the client, it can be ignored.
*/
(void) error;
- return indirect_create_context(base, config_base, shareList, 0);
+ return indirect_create_context(base, config_base, shareList, renderType);
}
struct glx_screen_vtable indirect_screen_vtable = {
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/8] Support of RENDER_TYPE property [4/6] Handling in glXCreateContext and init_fbconfig_for_chooser.
This patch sets the correct values of renderType and drawableType
in glXCreateContext and init_fbconfig_for_chooser routines.
---
src/glx/glxcmds.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 51b2237..967dab3 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -373,7 +373,25 @@ glXCreateContext(Display * dpy, XVisualInfo * vis,
return None;
}
- renderType = config->rgbMode ? GLX_RGBA_TYPE : GLX_COLOR_INDEX_TYPE;
+ /* Choose the context render type based on DRI config values.
+* It is unusual to set this type from config, but we have no other choice,
+* as this old API does not provide renderType parameter. */
+ if (config->renderType & GLX_RGBA_FLOAT_BIT_ARB) {
+ renderType = GLX_RGBA_FLOAT_TYPE_ARB;
+ } else if (config->renderType & GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT) {
+ renderType = GLX_RGBA_UNSIGNED_FLOAT_TYPE_EXT;
+ } else if (config->renderType & GLX_RGBA_BIT) {
+ renderType = GLX_RGBA_TYPE;
+ } else if (config->renderType & GLX_COLOR_INDEX_BIT) {
+ renderType = GLX_COLOR_INDEX_TYPE;
+ } else if (config->rgbMode == GL_TRUE) {
+ /* If we're here, then renderType is not set correctly.
+* Let's use a safeguard - any TrueColor or DirectColor mode is RGB
mode */
+ renderType = GLX_RGBA_TYPE;
+ } else {
+ /* Safeguard - only one option left, all non-RGB modes are indexed
modes */
+ renderType = GLX_COLOR_INDEX_TYPE;
+ }
#endif
return CreateContext(dpy, vis->visualid, config, shareList, allowDirect,
@@ -860,12 +878,17 @@ init_fbconfig_for_chooser(struct glx_config * config,
config->visualID = (XID) GLX_DONT_CARE;
config->visualType = GLX_DONT_CARE;
- /* glXChooseFBConfig specifies different defaults for these two than
+ /* glXChooseFBConfig specifies different defaults for these properties than
* glXChooseVisual.
*/
if (fbconfig_style_tags) {
config->rgbMode = GL_TRUE;
config->doubleBufferMode = GLX_DONT_CARE;
+ /* allow any kind of drawable, including those for off-screen buffers */
+ config->drawableType = 0;
+ } else {
+ /* allow configs which support on-screen drawing */
+ config->drawableType = GLX_WINDOW_BIT;
}
config->visualRating = GLX_DONT_CARE;
@@ -876,9 +899,8 @@ init_fbconfig_for_chooser(struct glx_config * config,
config->transparentAlpha = GLX_DONT_CARE;
config->transparentIndex = GLX_DONT_CARE;
- config->drawableType = GLX_WINDOW_BIT;
- config->renderType =
- (config->rgbMode) ? GLX_RGBA_BIT : GLX_COLOR_INDEX_BIT;
+ /* Set GLX_RENDER_TYPE property to not expect any flags by default. */
+ config->renderType = 0;
config->xRenderable = GLX_DONT_CARE;
config->fbconfigID = (GLXFBConfigID) (GLX_DONT_CARE);
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/8] Support of RENDER_TYPE property [6/6] Verification of the RENDER_TYPE value.
The change is to correctly handle the value of renderType in GLX context.
In case of the value being incorrect, context creation fails.
---
src/glx/dri2_glx.c | 11 +++
src/glx/dri_glx.c |6 ++
src/glx/drisw_glx.c| 12
src/glx/glxclient.h|2 ++
src/glx/glxcmds.c | 25 +
src/glx/indirect_glx.c |6 ++
src/mesa/drivers/x11/fakeglx.c |5 -
7 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index d60c675..539e7f1 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -205,6 +205,12 @@ dri2_create_context(struct glx_screen *base,
__GLXDRIconfigPrivate *config = (__GLXDRIconfigPrivate *) config_base;
__DRIcontext *shared = NULL;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType) {
+ return NULL;
+ }
+
if (shareList) {
/* If the shareList context is not a DRI2 context, we cannot possibly
* create a DRI2 context that shares it.
@@ -277,6 +283,11 @@ dri2_create_context_attribs(struct glx_screen *base,
error))
goto error_exit;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType)
+ goto error_exit;
+
if (shareList) {
pcp_shared = (struct dri2_context *) shareList;
shared = pcp_shared->driContext;
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index cc45734..de44451 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -581,6 +581,12 @@ dri_create_context(struct glx_screen *base,
if (!psc->base.driScreen)
return NULL;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType) {
+ return NULL;
+ }
+
if (shareList) {
/* If the shareList context is not a DRI context, we cannot possibly
* create a DRI context that shares it.
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index ef0e52b..0e45607 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -380,6 +380,12 @@ drisw_create_context(struct glx_screen *base,
if (!psc->base.driScreen)
return NULL;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType) {
+ return NULL;
+ }
+
if (shareList) {
/* If the shareList context is not a DRISW context, we cannot possibly
* create a DRISW context that shares it.
@@ -451,6 +457,12 @@ drisw_create_context_attribs(struct glx_screen *base,
error))
return NULL;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType) {
+ return NULL;
+ }
+
if (reset != __DRI_CTX_RESET_NO_NOTIFICATION)
return NULL;
diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index fc8f31c..0e78584 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -803,6 +803,8 @@ extern int
applegl_create_display(struct glx_display *display);
#endif
+extern int verifyContextRenderTypeGLX(const struct glx_config *config, int
renderType);
+
extern struct glx_drawable *GetGLXDrawable(Display *dpy, GLXDrawable drawable);
extern int InitGLXDrawable(Display *dpy, struct glx_drawable *glxDraw,
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 99b0218..e5ae7f8 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -224,6 +224,31 @@ ValidateGLXFBConfig(Display * dpy, GLXFBConfig fbconfig)
return NULL;
}
+/**
+ * Verifies context's GLX_RENDER_TYPE value with config.
+ * \param config GLX FBConfig which will support the returned renderType.
+ * \param renderType The context render type to be verified.
+ * \return Gives the approved value of context renderType, or 0 if no valid
value was found.
+ */
+int
+verifyContextRenderTypeGLX(const struct glx_config *config, int renderType)
+{
+switch (renderType)
+{
+case GLX_RGBA_TYPE:
+return (config->renderType & GLX_RGBA_BIT) ? GLX_RGBA_TYPE : 0;
+case GLX_COLOR_INDEX_TYPE:
+return (config->renderType & GLX_COLOR_INDEX_BIT) ?
GLX_COLOR_INDEX_TYPE : 0;
+case GLX_RGBA_FLOAT_TYPE_ARB:
+return (config->renderType & GLX_RGBA_FLOAT_BIT_ARB) ?
GLX_RGBA_FLOAT_TYPE_ARB : 0;
+case GLX_RGBA_UNSIGNED_FLOAT_TYPE_EXT:
+return (config->renderType & GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT) ?
GLX_RGBA_UNSIGNED_FLOAT_TYPE_EXT : 0;
+default:
+break;
+}
+return 0;
+}
+
_X_HIDDEN Bool
glx_context_init(struct glx_context *gc,
struct glx_screen *psc, struct glx_config *config)
diff --git a/src/glx/indirect_glx.c b/src/glx/indirect_glx.c
index fc5107d..c1a81d5 100644
--- a/src/glx/indirect_glx.c
+++ b/src/glx/indirect
[Mesa-dev] [PATCH 7/8] Float fbconfigs frontend patch [1/2] Float configs extension strings.
From: Tomasz Lis
The patch defines fbconfig_float in tables of extensions and enables
reporting the extension availability.
Signed-off-by: Tomasz Lis
---
src/glx/glxextensions.c |4
src/glx/glxextensions.h |6 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index caa6d99..27c6017 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
@@ -74,6 +74,7 @@ static const struct extension_info known_glx_extensions[] = {
{ GLX(ARB_create_context), VER(0,0), Y, N, N, N },
{ GLX(ARB_create_context_profile), VER(0,0), Y, N, N, N },
{ GLX(ARB_create_context_robustness), VER(0,0), Y, N, N, N },
+ { GLX(ARB_fbconfig_float), VER(1,3), Y, N, Y, N },
{ GLX(ARB_framebuffer_sRGB),VER(0,0), Y, Y, N, N },
{ GLX(ARB_get_proc_address),VER(1,4), Y, N, Y, N },
{ GLX(ARB_multisample), VER(1,4), Y, Y, N, N },
@@ -82,6 +83,7 @@ static const struct extension_info known_glx_extensions[] = {
{ GLX(EXT_visual_info), VER(0,0), Y, Y, N, N },
{ GLX(EXT_visual_rating), VER(0,0), Y, Y, N, N },
{ GLX(EXT_framebuffer_sRGB),VER(0,0), Y, Y, N, N },
+ { GLX(EXT_fbconfig_packed_float), VER(1,3), Y, N, Y, N },
{ GLX(EXT_create_context_es2_profile), VER(0,0), Y, N, N, Y },
{ GLX(MESA_copy_sub_buffer),VER(0,0), Y, N, N, N },
{ GLX(MESA_multithread_makecurrent),VER(0,0), Y, N, Y, N },
@@ -132,6 +134,7 @@ static const struct extension_info known_gl_extensions[] = {
{ GL(ARB_vertex_buffer_object), VER(1,5), N, N, N, N },
{ GL(ARB_vertex_program), VER(0,0), Y, N, N, N },
{ GL(ARB_window_pos), VER(1,4), Y, N, N, N },
+ { GL(ARB_color_buffer_float), VER(3,0), Y, Y, Y, N },
{ GL(EXT_abgr), VER(0,0), Y, N, N, N },
{ GL(EXT_bgra), VER(1,2), Y, N, N, N },
{ GL(EXT_blend_color),VER(1,4), Y, N, N, N },
@@ -155,6 +158,7 @@ static const struct extension_info known_gl_extensions[] = {
{ GL(EXT_multi_draw_arrays), VER(1,4), Y, N, Y, N },
{ GL(EXT_packed_depth_stencil), VER(0,0), Y, N, N, N },
{ GL(EXT_packed_pixels), VER(1,2), Y, N, N, N },
+ { GL(EXT_packed_float), VER(1,1), Y, N, N, N },
{ GL(EXT_paletted_texture), VER(0,0), Y, N, N, N },
{ GL(EXT_pixel_buffer_object),VER(0,0), N, N, N, N },
{ GL(EXT_point_parameters), VER(1,4), Y, N, N, N },
diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
index 3c5d407..7d2bf96 100644
--- a/src/glx/glxextensions.h
+++ b/src/glx/glxextensions.h
@@ -36,6 +36,7 @@ enum
ARB_create_context_bit = 0,
ARB_create_context_profile_bit,
ARB_create_context_robustness_bit,
+ ARB_fbconfig_float_bit,
ARB_get_proc_address_bit,
ARB_multisample_bit,
ATI_pixel_format_float_bit,
@@ -43,6 +44,7 @@ enum
EXT_visual_rating_bit,
EXT_import_context_bit,
EXT_framebuffer_sRGB_bit,
+ EXT_fbconfig_packed_float_bit,
EXT_create_context_es2_profile_bit,
MESA_copy_sub_buffer_bit,
MESA_depth_float_bit,
@@ -72,7 +74,8 @@ enum
enum
{
- GL_ARB_depth_texture_bit = 0,
+ GL_ARB_color_buffer_float_bit = 0,
+ GL_ARB_depth_texture_bit,
GL_ARB_draw_buffers_bit,
GL_ARB_fragment_program_bit,
GL_ARB_fragment_program_shadow_bit,
@@ -122,6 +125,7 @@ enum
GL_EXT_framebuffer_sRGB_bit,
GL_EXT_multi_draw_arrays_bit,
GL_EXT_packed_depth_stencil_bit,
+ GL_EXT_packed_float_bit,
GL_EXT_packed_pixels_bit,
GL_EXT_paletted_texture_bit,
GL_EXT_pixel_buffer_object_bit,
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 8/8] Float fbconfigs frontend patch [2/2] Introduced new flags in __DRI_ATTRIB_RENDER_TYPE.
From: Tomasz Lis
The patch marks __DRI_ATTRIB_FLOAT_MODE as deprecated and introduces
nrw flags to __DRI_ATTRIB_RENDER_TYPE which are to define float modes.
Both signed float (fbconfig_float) and unsigned (packed_float) is
introduced as a flag. The old attribute should be set for both float
modes.
Signed-off-by: Tomasz Lis
---
include/GL/internal/dri_interface.h |2 ++
src/egl/drivers/dri2/egl_dri2.c | 22 +-
src/glx/dri_common.c| 16 +++-
src/mesa/drivers/dri/common/utils.c |6 --
4 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 30ce175..3316fd2 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -552,6 +552,8 @@ struct __DRIuseInvalidateExtensionRec {
#define __DRI_ATTRIB_RGBA_BIT 0x01
#define __DRI_ATTRIB_COLOR_INDEX_BIT 0x02
#define __DRI_ATTRIB_LUMINANCE_BIT 0x04
+#define __DRI_ATTRIB_FLOAT_BIT 0x08
+#define __DRI_ATTRIB_UNSIGNED_FLOAT_BIT0x10
/* __DRI_ATTRIB_CONFIG_CAVEAT */
#define __DRI_ATTRIB_SLOW_BIT 0x01
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 1bce314..7ec1a5d 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -75,7 +75,7 @@ EGLint dri2_to_egl_attribute_map[] = {
0, /* __DRI_ATTRIB_TRANSPARENT_GREEN_VALUE */
0, /* __DRI_ATTRIB_TRANSPARENT_BLUE_VALUE */
0, /* __DRI_ATTRIB_TRANSPARENT_ALPHA_VALUE */
- 0, /* __DRI_ATTRIB_FLOAT_MODE */
+ 0, /* __DRI_ATTRIB_FLOAT_MODE (deprecated) */
0, /* __DRI_ATTRIB_RED_MASK */
0, /* __DRI_ATTRIB_GREEN_MASK */
0, /* __DRI_ATTRIB_BLUE_MASK */
@@ -136,14 +136,18 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig
*dri_config, int id,
while (dri2_dpy->core->indexConfigAttrib(dri_config, i++, &attrib, &value))
{
switch (attrib) {
case __DRI_ATTRIB_RENDER_TYPE:
-if (value & __DRI_ATTRIB_RGBA_BIT)
- value = EGL_RGB_BUFFER;
-else if (value & __DRI_ATTRIB_LUMINANCE_BIT)
- value = EGL_LUMINANCE_BUFFER;
-else
- /* not valid */;
-_eglSetConfigKey(&base, EGL_COLOR_BUFFER_TYPE, value);
-break;
+ if (value & __DRI_ATTRIB_RGBA_BIT)
+value = EGL_RGB_BUFFER;
+ else if (value & __DRI_ATTRIB_LUMINANCE_BIT)
+value = EGL_LUMINANCE_BUFFER;
+ else if (value & __DRI_ATTRIB_FLOAT_BIT)
+return NULL; // Don't allow float configs for EGL
+ else if (value & __DRI_ATTRIB_UNSIGNED_FLOAT_BIT)
+return NULL; // Don't allow float configs for EGL
+ else
+/* not valid */;
+ _eglSetConfigKey(&base, EGL_COLOR_BUFFER_TYPE, value);
+ break;
case __DRI_ATTRIB_CONFIG_CAVEAT:
if (value & __DRI_ATTRIB_NON_CONFORMANT_CONFIG)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 7ab303e..872f5c3 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -281,14 +281,20 @@ driConfigEqual(const __DRIcoreExtension *core,
while (core->indexConfigAttrib(driConfig, i++, &attrib, &value)) {
switch (attrib) {
case __DRI_ATTRIB_RENDER_TYPE:
- glxValue = 0;
+ glxValue = 0;
if (value & __DRI_ATTRIB_RGBA_BIT) {
-glxValue |= GLX_RGBA_BIT;
+ glxValue |= GLX_RGBA_BIT;
+ }
+ if (value & __DRI_ATTRIB_COLOR_INDEX_BIT) {
+ glxValue |= GLX_COLOR_INDEX_BIT;
+ }
+ if (value & __DRI_ATTRIB_FLOAT_BIT) {
+ glxValue |= GLX_RGBA_FLOAT_BIT_ARB;
}
- else if (value & __DRI_ATTRIB_COLOR_INDEX_BIT) {
-glxValue |= GLX_COLOR_INDEX_BIT;
+ if (value & __DRI_ATTRIB_UNSIGNED_FLOAT_BIT) {
+ glxValue |= GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT;
}
- if (glxValue != config->renderType)
+ if ((glxValue & config->renderType) == 0)
return GL_FALSE;
break;
diff --git a/src/mesa/drivers/dri/common/utils.c
b/src/mesa/drivers/dri/common/utils.c
index ac0773b..c9fc218 100644
--- a/src/mesa/drivers/dri/common/utils.c
+++ b/src/mesa/drivers/dri/common/utils.c
@@ -366,7 +366,6 @@ static const struct { unsigned int attrib, offset; }
attribMap[] = {
__ATTRIB(__DRI_ATTRIB_TRANSPARENT_GREEN_VALUE, transparentGreen),
__ATTRIB(__DRI_ATTRIB_TRANSPARENT_BLUE_VALUE, transparentBlue),
__ATTRIB(__DRI_ATTRIB_TRANSPARENT_ALPHA_VALUE, transparentAlpha),
-__ATTRIB(__DRI_ATTRIB_FLOAT_MODE, floatMode),
__ATTRIB(__DRI_ATTRIB_RED_MASK,redMask),
__ATTRIB(__D
Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes
On 07/12/2013 06:19 PM, Carl Worth wrote: Brian Paul writes: Carl, it would be good if you could put all the above info in Mesa docs/. The devinfo.html page mentions the "This is a candidate for the stable branches" convention, etc. The docs/lists.html file describes all the mailing lists. And so on. Great idea. Thanks for pointing me to where this documentation should live. I'll have a patch soon which incorporates all the feedback from this thread, (along with some ideas culled from the kernel guidelines as recommended). Thanks, Carl. Meanwhile, what's the correct process for updating the website itself? I upload the files to the mesa directory via my SF account. I notice that www.mesa3d.org/devinfo.html page on the web currently talks about pushing tar files out to sourceforge.net and copying files to /home/users/b/br/brianp/mesa-www/htdocs/ . Are those instructions still current? Yes. Do I have permission to do those steps? (I'm quite certain I don't' even have a sourceforge account.) You'd need a SF account at least. I also notice that mesa3d.org/index.html hasn't been updated for new releases since 9.1.2 on April 30. Thanks for the reminder. I've uploaded the new pages. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: use MCJIT on ARM and AArch64
From: Kyle McMartin MCJIT is the only supported LLVM JIT on AArch64 and ARM (the regular JIT has bit-rotted badly on ARM and doesn't exist on AArch64.) Signed-off-by: Kyle McMartin --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c @@ -49,7 +49,7 @@ * - MC-JIT supports limited OSes (MacOSX and Linux) * - standard JIT in LLVM 3.1, with backports */ -#if defined(PIPE_ARCH_PPC_64) || defined(PIPE_ARCH_S390) +#if defined(PIPE_ARCH_PPC_64) || defined(PIPE_ARCH_S390) || defined(PIPE_ARCH_ARM) || defined(PIPE_ARCH_AARCH64) # define USE_MCJIT 1 # define HAVE_AVX 0 #elif HAVE_LLVM >= 0x0302 || (HAVE_LLVM == 0x0301 && defined(HAVE_JIT_AVX_SUPPORT)) diff --git a/src/gallium/include/pipe/p_config.h b/src/gallium/include/pipe/p_config.h index 6b51160..96b5247 100644 --- a/src/gallium/include/pipe/p_config.h +++ b/src/gallium/include/pipe/p_config.h @@ -114,6 +114,13 @@ #define PIPE_ARCH_S390 #endif +#if defined(__arm__) +#define PIPE_ARCH_ARM +#endif + +#if defined(__aarch64__) +#define PIPE_ARCH_AARCH64 +#endif /* * Endian detection. @@ -148,7 +155,7 @@ #else -#if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) +#if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) || defined(PIPE_ARCH_ARM) || defined(PIPE_ARCH_AARCH64) #define PIPE_ARCH_LITTLE_ENDIAN #elif defined(PIPE_ARCH_PPC) || defined(PIPE_ARCH_PPC_64) || defined(PIPE_ARCH_S390) #define PIPE_ARCH_BIG_ENDIAN ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66931] New: Can't specify local buffer size using clSetKernelArg
https://bugs.freedesktop.org/show_bug.cgi?id=66931 Priority: medium Bug ID: 66931 Assignee: mesa-dev@lists.freedesktop.org Summary: Can't specify local buffer size using clSetKernelArg Severity: normal Classification: Unclassified OS: Linux (All) Reporter: jchar...@gmail.com Hardware: Other Status: NEW Version: git Component: Other Product: Mesa I always get return code -51 when I try to set the second argument of my kernel. This argument is a local buffer. Here is the call I make: clSetKernelArg(in_Kernel.mKernel, 1, 1024, NULL); The kernel prototype is: __kernel void GetEfficiency( __constant const SimulationParams * const in_pSimulationParams, __local float * l_afEfficiencies, __global const float * const in_pRandomValues, __global float * const out_pfEfficiencies) So argument index 1 is really a local buffer as can be seen from the prototype. I will try to investigate this further. -- 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] [Mesa-stable] [PATCH] glsl: Disallow return with a void argument from void functions.
Kenneth Graunke writes: > There are two kinds of bug fixes: > 1. Patches that make valid programs work > 2. Patches that disallow invalid programs > > This is in category 2 - it won't fix any applications, but runs a risk > of breaking working programs. We often avoid backporting these. Excellent point, Ken. This fits in well with several of the other criteria we have for stable patches. I'll drop this commit from my stable queue and update my list of criteria. Thanks, -Carl -- carl.d.wo...@intel.com pgpqOm9QZfyZB.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes
Brian Paul writes: >> Meanwhile, what's the correct process for updating the website itself? > > I upload the files to the mesa directory via my SF account. ... >> Do I have permission to do those steps? (I'm quite certain I don't' >> even have a sourceforge account.) > > You'd need a SF account at least. ... > Thanks for the reminder. I've uploaded the new pages. Thanks, Brian. That looks great. I don't think I'll pursue an SF account for now. Instead, I'll just expect you to pick up any web-page updates I commit, and I'll send you reminders like the above if necessary. Thanks for doing this, -Carl -- carl.d.wo...@intel.com pgpYsk1jrkS2_.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66833] Text rendering problems on Dota 2, all mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=66833 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #14 from Ian Romanick --- (In reply to comment #9) > I just tried to change the source of shaders 498, 500 and 502 to use the red > channel instead of alpha channel, and it confirms my reasoning. This is how > it looks: Thanks for the analysis! > https://dl.dropboxusercontent.com/u/87650/dota_linux.225278.trim.trace. > edited_call_180410-1_0.png The other way to deal with GL_ALPHA being removed: glTexImage2D(GL_TEXTURE_2D, 0, GL_RED, w, h, 0, GL_RED, GL_UNSIGNED_BYTE, pixels); glTexParamateri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_R, GL_ZERO); glTexParamateri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_G, GL_ZERO); glTexParamateri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_B, GL_ZERO); glTexParamateri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_A, GL_RED); That will make it behave identically (for texturing) to an old GL_ALPHA texture. I'm going to close this as NOTOURBUG and work with Valve to get this resolved in Dota 2. -- 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 66558] RS690: 3D artifacts when playing SuperTuxKart
https://bugs.freedesktop.org/show_bug.cgi?id=66558 --- Comment #9 from Björn Beutel --- Marek, your patch solves the problem for me. Thanks! -- 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 66931] Can't specify local buffer size using clSetKernelArg
https://bugs.freedesktop.org/show_bug.cgi?id=66931 --- Comment #1 from Jonathan Charest --- Created attachment 82462 --> https://bugs.freedesktop.org/attachment.cgi?id=82462&action=edit Addess spaces support for kernel arguments Use the data from getAddressSpaceMap to determine the correct type of the kernel arguments. -- 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 7/8] Float fbconfigs frontend patch [1/2] Float configs extension strings.
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
From: Tomasz Lis
The patch defines fbconfig_float in tables of extensions and enables
reporting the extension availability.
Since this patch enables the functionality, it should come after the
patch that implements the functionality.
Signed-off-by: Tomasz Lis
---
src/glx/glxextensions.c |4
src/glx/glxextensions.h |6 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index caa6d99..27c6017 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
@@ -74,6 +74,7 @@ static const struct extension_info known_glx_extensions[] = {
{ GLX(ARB_create_context), VER(0,0), Y, N, N, N },
{ GLX(ARB_create_context_profile), VER(0,0), Y, N, N, N },
{ GLX(ARB_create_context_robustness), VER(0,0), Y, N, N, N },
+ { GLX(ARB_fbconfig_float), VER(1,3), Y, N, Y, N },
None of these extensions are required for GLX 1.3. This should be VER(0,0).
{ GLX(ARB_framebuffer_sRGB),VER(0,0), Y, Y, N, N },
{ GLX(ARB_get_proc_address),VER(1,4), Y, N, Y, N },
{ GLX(ARB_multisample), VER(1,4), Y, Y, N, N },
@@ -82,6 +83,7 @@ static const struct extension_info known_glx_extensions[] = {
{ GLX(EXT_visual_info), VER(0,0), Y, Y, N, N },
{ GLX(EXT_visual_rating), VER(0,0), Y, Y, N, N },
{ GLX(EXT_framebuffer_sRGB),VER(0,0), Y, Y, N, N },
+ { GLX(EXT_fbconfig_packed_float), VER(1,3), Y, N, Y, N },
{ GLX(EXT_create_context_es2_profile), VER(0,0), Y, N, N, Y },
{ GLX(MESA_copy_sub_buffer),VER(0,0), Y, N, N, N },
{ GLX(MESA_multithread_makecurrent),VER(0,0), Y, N, Y, N },
@@ -132,6 +134,7 @@ static const struct extension_info known_gl_extensions[] = {
{ GL(ARB_vertex_buffer_object), VER(1,5), N, N, N, N },
{ GL(ARB_vertex_program), VER(0,0), Y, N, N, N },
{ GL(ARB_window_pos), VER(1,4), Y, N, N, N },
+ { GL(ARB_color_buffer_float), VER(3,0), Y, Y, Y, N },
Even though this is part of OpenGL 3.0, there is nothing else in libGL
to support indirect rendering for OpenGL 3.0. I would leave this as
VER(0,0).
It's also not alphabetized in the list.
Is there any code needed to support this functionality for indirect
rendering?
{ GL(EXT_abgr), VER(0,0), Y, N, N, N },
{ GL(EXT_bgra), VER(1,2), Y, N, N, N },
{ GL(EXT_blend_color),VER(1,4), Y, N, N, N },
@@ -155,6 +158,7 @@ static const struct extension_info known_gl_extensions[] = {
{ GL(EXT_multi_draw_arrays), VER(1,4), Y, N, Y, N },
{ GL(EXT_packed_depth_stencil), VER(0,0), Y, N, N, N },
{ GL(EXT_packed_pixels), VER(1,2), Y, N, N, N },
+ { GL(EXT_packed_float), VER(1,1), Y, N, N, N },
The VER here is wrong too.
Same question about implementation.
Have you tested either one of these for indirect rendering?
{ GL(EXT_paletted_texture), VER(0,0), Y, N, N, N },
{ GL(EXT_pixel_buffer_object),VER(0,0), N, N, N, N },
{ GL(EXT_point_parameters), VER(1,4), Y, N, N, N },
diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
index 3c5d407..7d2bf96 100644
--- a/src/glx/glxextensions.h
+++ b/src/glx/glxextensions.h
@@ -36,6 +36,7 @@ enum
ARB_create_context_bit = 0,
ARB_create_context_profile_bit,
ARB_create_context_robustness_bit,
+ ARB_fbconfig_float_bit,
ARB_get_proc_address_bit,
ARB_multisample_bit,
ATI_pixel_format_float_bit,
@@ -43,6 +44,7 @@ enum
EXT_visual_rating_bit,
EXT_import_context_bit,
EXT_framebuffer_sRGB_bit,
+ EXT_fbconfig_packed_float_bit,
EXT_create_context_es2_profile_bit,
MESA_copy_sub_buffer_bit,
MESA_depth_float_bit,
@@ -72,7 +74,8 @@ enum
enum
{
- GL_ARB_depth_texture_bit = 0,
+ GL_ARB_color_buffer_float_bit = 0,
+ GL_ARB_depth_texture_bit,
GL_ARB_draw_buffers_bit,
GL_ARB_fragment_program_bit,
GL_ARB_fragment_program_shadow_bit,
@@ -122,6 +125,7 @@ enum
GL_EXT_framebuffer_sRGB_bit,
GL_EXT_multi_draw_arrays_bit,
GL_EXT_packed_depth_stencil_bit,
+ GL_EXT_packed_float_bit,
GL_EXT_packed_pixels_bit,
GL_EXT_paletted_texture_bit,
GL_EXT_pixel_buffer_object_bit,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] Float fbconfigs frontend patch [2/2] Introduced new flags in __DRI_ATTRIB_RENDER_TYPE.
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
From: Tomasz Lis
The patch marks __DRI_ATTRIB_FLOAT_MODE as deprecated and introduces
nrw flags to __DRI_ATTRIB_RENDER_TYPE which are to define float modes.
Both signed float (fbconfig_float) and unsigned (packed_float) is
introduced as a flag. The old attribute should be set for both float
modes.
Signed-off-by: Tomasz Lis
---
include/GL/internal/dri_interface.h |2 ++
src/egl/drivers/dri2/egl_dri2.c | 22 +-
src/glx/dri_common.c| 16 +++-
src/mesa/drivers/dri/common/utils.c |6 --
4 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 30ce175..3316fd2 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -552,6 +552,8 @@ struct __DRIuseInvalidateExtensionRec {
#define __DRI_ATTRIB_RGBA_BIT 0x01
#define __DRI_ATTRIB_COLOR_INDEX_BIT 0x02
#define __DRI_ATTRIB_LUMINANCE_BIT0x04
+#define __DRI_ATTRIB_FLOAT_BIT 0x08
+#define __DRI_ATTRIB_UNSIGNED_FLOAT_BIT0x10
/* __DRI_ATTRIB_CONFIG_CAVEAT */
#define __DRI_ATTRIB_SLOW_BIT 0x01
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 1bce314..7ec1a5d 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -75,7 +75,7 @@ EGLint dri2_to_egl_attribute_map[] = {
0, /* __DRI_ATTRIB_TRANSPARENT_GREEN_VALUE */
0, /* __DRI_ATTRIB_TRANSPARENT_BLUE_VALUE */
0, /* __DRI_ATTRIB_TRANSPARENT_ALPHA_VALUE */
- 0, /* __DRI_ATTRIB_FLOAT_MODE */
+ 0, /* __DRI_ATTRIB_FLOAT_MODE (deprecated) */
0, /* __DRI_ATTRIB_RED_MASK */
0, /* __DRI_ATTRIB_GREEN_MASK */
0, /* __DRI_ATTRIB_BLUE_MASK */
@@ -136,14 +136,18 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig
*dri_config, int id,
while (dri2_dpy->core->indexConfigAttrib(dri_config, i++, &attrib,
&value)) {
switch (attrib) {
case __DRI_ATTRIB_RENDER_TYPE:
-if (value & __DRI_ATTRIB_RGBA_BIT)
- value = EGL_RGB_BUFFER;
-else if (value & __DRI_ATTRIB_LUMINANCE_BIT)
- value = EGL_LUMINANCE_BUFFER;
-else
- /* not valid */;
-_eglSetConfigKey(&base, EGL_COLOR_BUFFER_TYPE, value);
-break;
+ if (value & __DRI_ATTRIB_RGBA_BIT)
+value = EGL_RGB_BUFFER;
+ else if (value & __DRI_ATTRIB_LUMINANCE_BIT)
+value = EGL_LUMINANCE_BUFFER;
+ else if (value & __DRI_ATTRIB_FLOAT_BIT)
+return NULL; // Don't allow float configs for EGL
+ else if (value & __DRI_ATTRIB_UNSIGNED_FLOAT_BIT)
+return NULL; // Don't allow float configs for EGL
+ else
+/* not valid */;
+ _eglSetConfigKey(&base, EGL_COLOR_BUFFER_TYPE, value);
+ break;
There are some spurious white space changes here.
Also, I think this code could be simplified by replacing the /* not
valid */ comment with 'return NULL;' The existing final else case just
looks wrong to me.
Kristian: Do you remember why that code is like that?
case __DRI_ATTRIB_CONFIG_CAVEAT:
if (value & __DRI_ATTRIB_NON_CONFORMANT_CONFIG)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 7ab303e..872f5c3 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -281,14 +281,20 @@ driConfigEqual(const __DRIcoreExtension *core,
while (core->indexConfigAttrib(driConfig, i++, &attrib, &value)) {
switch (attrib) {
case __DRI_ATTRIB_RENDER_TYPE:
Lots of spurious white space changes in this hunk too. It looks like
there are other spurious changes too... it makes it hard to tell what is
actually changed.
- glxValue = 0;
+ glxValue = 0;
if (value & __DRI_ATTRIB_RGBA_BIT) {
-glxValue |= GLX_RGBA_BIT;
+ glxValue |= GLX_RGBA_BIT;
+ }
+ if (value & __DRI_ATTRIB_COLOR_INDEX_BIT) {
+ glxValue |= GLX_COLOR_INDEX_BIT;
+ }
+ if (value & __DRI_ATTRIB_FLOAT_BIT) {
+ glxValue |= GLX_RGBA_FLOAT_BIT_ARB;
}
- else if (value & __DRI_ATTRIB_COLOR_INDEX_BIT) {
-glxValue |= GLX_COLOR_INDEX_BIT;
+ if (value & __DRI_ATTRIB_UNSIGNED_FLOAT_BIT) {
+ glxValue |= GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT;
}
- if (glxValue != config->renderType)
+ if ((glxValue & config->renderType) == 0)
return GL_FALSE;
break;
diff --git a/src/mesa/drivers/dri/common/utils.c
b/src/mesa/drivers/dri/common/utils.c
index ac0773b..c9fc218 100644
--- a/src/mesa/drivers/dri/common/utils.c
+++ b/sr
Re: [Mesa-dev] [PATCH 1/8] Support of RENDER_TYPE property [1/6] Correct handling of RENDER_TYPE property.
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
The change is to correctly handle the value of renderType in both
fbconfig and context. Uses of renderType are commented, where needed,
to avoid confusion between the two types. The fact that float configs
can be only used for pbuffers is correctly addressed.
These commit messages are not so good. The first line should be a short
description of the change. The remainder should be additional
information (details or supporting evidence) of the change. For this
patch, I would suggest:
Correctly handle the value of renderType in both fbconfig and context.
Uses of renderType are commented, where needed, to avoid confusion
between the two types. The fact that float configs can be only used
for pbuffers is correctly addressed.
---
src/glx/dri2_glx.c |7 +++
src/glx/dri_glx.c |2 ++
src/glx/drisw_glx.c |5 +
src/glx/glxcmds.c |4 ++--
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 7ce5775..630dbd9 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -226,6 +226,8 @@ dri2_create_context(struct glx_screen *base,
return NULL;
}
+ pcp->base.renderType = renderType;
+
pcp->driContext =
(*psc->dri2->createNewContext) (psc->driScreen,
config->driConfig, shared, pcp);
@@ -311,6 +313,11 @@ dri2_create_context_attribs(struct glx_screen *base,
ctx_attribs[num_ctx_attribs++] = flags;
}
+ /* The renderType is retrieved from attribs, or set to default
+* of GLX_RGBA_TYPE.
+*/
+ pcp->base.renderType = renderType;
+
pcp->driContext =
(*psc->dri2->createContextAttribs) (psc->driScreen,
api,
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index ba8fda2..cc45734 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -602,6 +602,8 @@ dri_create_context(struct glx_screen *base,
return NULL;
}
+ pcp->base.renderType = renderType;
+
if (!XF86DRICreateContextWithConfig(psc->base.dpy, psc->base.scr,
config->base.visualID,
&pcp->hwContextID, &hwContext)) {
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 832e964..80ddf9c 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -401,6 +401,8 @@ drisw_create_context(struct glx_screen *base,
return NULL;
}
+ pcp->base.renderType = renderType;
+
pcp->driContext =
(*psc->core->createNewContext) (psc->driScreen,
config->driConfig, shared, pcp);
@@ -429,6 +431,7 @@ drisw_create_context_attribs(struct glx_screen *base,
uint32_t minor_ver = 1;
uint32_t major_ver = 0;
+ uint32_t renderType = GLX_RGBA_TYPE;
uint32_t flags = 0;
unsigned api;
int reset = __DRI_CTX_RESET_NO_NOTIFICATION;
@@ -479,6 +482,8 @@ drisw_create_context_attribs(struct glx_screen *base,
ctx_attribs[num_ctx_attribs++] = flags;
}
+ pcp->base.renderType = renderType;
+
pcp->driContext =
(*psc->swrast->createContextAttribs) (psc->driScreen,
api,
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 019165a..51b2237 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -354,7 +354,7 @@ glXCreateContext(Display * dpy, XVisualInfo * vis,
GLXContext shareList, Bool allowDirect)
{
struct glx_config *config = NULL;
- int renderType = 0;
+ int renderType = GLX_RGBA_TYPE;
#if defined(GLX_DIRECT_RENDERING) || defined(GLX_USE_APPLEGL)
struct glx_screen *const psc = GetGLXScreenConfigs(dpy, vis->screen);
@@ -1441,7 +1441,7 @@ glXImportContextEXT(Display *dpy, GLXContextID contextID)
numProps = nPropListBytes / (2 * sizeof(propList[0]));
share = None;
mode = NULL;
- renderType = 0;
+ renderType = GLX_RGBA_TYPE; /* By default, assume RGBA context */
pProp = propList;
for (i = 0, pProp = propList; i < numProps; i++, pProp += 2)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/8] Support of RENDER_TYPE property [4/6] Handling in glXCreateContext and init_fbconfig_for_chooser.
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
This patch sets the correct values of renderType and drawableType
in glXCreateContext and init_fbconfig_for_chooser routines.
---
src/glx/glxcmds.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 51b2237..967dab3 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -373,7 +373,25 @@ glXCreateContext(Display * dpy, XVisualInfo * vis,
return None;
}
- renderType = config->rgbMode ? GLX_RGBA_TYPE : GLX_COLOR_INDEX_TYPE;
+ /* Choose the context render type based on DRI config values.
+* It is unusual to set this type from config, but we have no other choice,
+* as this old API does not provide renderType parameter. */
+ if (config->renderType & GLX_RGBA_FLOAT_BIT_ARB) {
I /think/ GCC will generate a warning about this. Something like
'suggest parenthesis around ...". Could you double check that and fix
the warning if it exists?
+ renderType = GLX_RGBA_FLOAT_TYPE_ARB;
+ } else if (config->renderType & GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT) {
+ renderType = GLX_RGBA_UNSIGNED_FLOAT_TYPE_EXT;
+ } else if (config->renderType & GLX_RGBA_BIT) {
+ renderType = GLX_RGBA_TYPE;
+ } else if (config->renderType & GLX_COLOR_INDEX_BIT) {
+ renderType = GLX_COLOR_INDEX_TYPE;
+ } else if (config->rgbMode == GL_TRUE) {
} else if (config->rgbMode) {
However, I'm unsure about this. It seems like if the renderType is not
correctly set that something has gone seriously wrong. Shouldn't this
function just fail?
+ /* If we're here, then renderType is not set correctly.
+* Let's use a safeguard - any TrueColor or DirectColor mode is RGB
mode */
+ renderType = GLX_RGBA_TYPE;
+ } else {
+ /* Safeguard - only one option left, all non-RGB modes are indexed
modes */
+ renderType = GLX_COLOR_INDEX_TYPE;
+ }
#endif
return CreateContext(dpy, vis->visualid, config, shareList, allowDirect,
@@ -860,12 +878,17 @@ init_fbconfig_for_chooser(struct glx_config * config,
config->visualID = (XID) GLX_DONT_CARE;
config->visualType = GLX_DONT_CARE;
- /* glXChooseFBConfig specifies different defaults for these two than
+ /* glXChooseFBConfig specifies different defaults for these properties than
* glXChooseVisual.
*/
if (fbconfig_style_tags) {
config->rgbMode = GL_TRUE;
config->doubleBufferMode = GLX_DONT_CARE;
+ /* allow any kind of drawable, including those for off-screen buffers */
+ config->drawableType = 0;
+ } else {
+ /* allow configs which support on-screen drawing */
+ config->drawableType = GLX_WINDOW_BIT;
}
This feels like it should be a separate commit. Is there some spec text
or further justification for this? We ought to at least have a piglit
test case...
config->visualRating = GLX_DONT_CARE;
@@ -876,9 +899,8 @@ init_fbconfig_for_chooser(struct glx_config * config,
config->transparentAlpha = GLX_DONT_CARE;
config->transparentIndex = GLX_DONT_CARE;
- config->drawableType = GLX_WINDOW_BIT;
- config->renderType =
- (config->rgbMode) ? GLX_RGBA_BIT : GLX_COLOR_INDEX_BIT;
+ /* Set GLX_RENDER_TYPE property to not expect any flags by default. */
+ config->renderType = 0;
config->xRenderable = GLX_DONT_CARE;
config->fbconfigID = (GLXFBConfigID) (GLX_DONT_CARE);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/8] Support of RENDER_TYPE property [5/6] Storing the RENDER_TYPE in indirect rendering.
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
The change allows to store RENDER_TYPE value in GLX context
when indirect rendering is in use.
---
src/glx/create_context.c |4 +++-
src/glx/glxclient.h |7 +++
src/glx/glxcmds.c|1 -
src/glx/indirect_glx.c | 23 ++-
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/src/glx/create_context.c b/src/glx/create_context.c
index a755e83..38e949a 100644
--- a/src/glx/create_context.c
+++ b/src/glx/create_context.c
@@ -84,7 +84,9 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig config,
#ifdef GLX_USE_APPLEGL
gc = applegl_create_context(psc, cfg, share, 0);
#else
- gc = indirect_create_context(psc, cfg, share, 0);
+ gc = indirect_create_context_attribs(psc, cfg, share, num_attribs,
+ (const uint32_t *) attrib_list,
+ &dummy_err);
#endif
}
diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index 3e9b730..fc8f31c 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -817,5 +817,12 @@ extern struct glx_context *
indirect_create_context(struct glx_screen *psc,
struct glx_config *mode,
struct glx_context *shareList, int renderType);
+extern struct glx_context *
+indirect_create_context_attribs(struct glx_screen *base,
+ struct glx_config *config_base,
+ struct glx_context *shareList,
+ unsigned num_attribs,
+ const uint32_t *attribs,
+ unsigned *error);
#endif /* !__GLX_client_h__ */
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 967dab3..99b0218 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -344,7 +344,6 @@ CreateContext(Display *dpy, int generic_id, struct
glx_config *config,
gc->share_xid = shareList ? shareList->xid : None;
gc->imported = GL_FALSE;
- gc->renderType = renderType;
return (GLXContext) gc;
}
diff --git a/src/glx/indirect_glx.c b/src/glx/indirect_glx.c
index ff869e2..fc5107d 100644
--- a/src/glx/indirect_glx.c
+++ b/src/glx/indirect_glx.c
@@ -32,6 +32,7 @@
#include "glapi.h"
#include "glxclient.h"
+#include "dri_common.h"
extern struct _glapi_table *__glXNewIndirectAPI(void);
@@ -362,6 +363,8 @@ indirect_create_context(struct glx_screen *psc,
gc->isDirect = GL_FALSE;
gc->vtable = &indirect_context_vtable;
state = calloc(1, sizeof(struct __GLXattributeRec));
+ gc->renderType = renderType;
+
if (state == NULL) {
/* Out of memory */
free(gc);
@@ -430,7 +433,7 @@ indirect_create_context(struct glx_screen *psc,
return gc;
}
-static struct glx_context *
+_X_HIDDEN struct glx_context *
indirect_create_context_attribs(struct glx_screen *base,
struct glx_config *config_base,
struct glx_context *shareList,
@@ -438,18 +441,28 @@ indirect_create_context_attribs(struct glx_screen *base,
const uint32_t *attribs,
unsigned *error)
{
+uint32_t minor_ver = 1;
+uint32_t major_ver = 2;
+uint32_t renderType = GLX_RGBA_TYPE;
+uint32_t flags = 0;
+unsigned api;
+int reset = __DRI_CTX_RESET_NO_NOTIFICATION;
There should be a blank line between the declarations and the comment.
/* All of the attribute validation for indirect contexts is handled on the
-* server, so there's not much to do here.
+* server, so there's not much to do here. Still, we need to parse the
attributes
+* to correctly set renderType.
*/
- (void) num_attribs;
- (void) attribs;
+if (!dri2_convert_glx_attribs(num_attribs, attribs,
+ &major_ver, &minor_ver, &renderType, &flags,
+ &api, &reset, error)) {
+return NULL;
+}
/* The error parameter is only used on the server so that correct GLX
* protocol errors can be generated. On the client, it can be ignored.
*/
(void) error;
Since error is used now, this should be deleted.
- return indirect_create_context(base, config_base, shareList, 0);
+ return indirect_create_context(base, config_base, shareList, renderType);
}
struct glx_screen_vtable indirect_screen_vtable = {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 1/3] glsl ES: Fix magnitude of gl_MaxVertexUniformVectors.
Paul Berry writes: > NOTE: This is a candidate for the stable branches. > > Cc: mesa-sta...@lists.freedesktop.org Thanks, Paul. This is merged on the stable branch now. -Carl pgperrTaouzDR.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
On 07/15/2013 06:26 AM, Fredrik Höglund wrote: On Friday 12 July 2013, Chad Versace wrote: On 07/12/2013 12:25 PM, Fredrik Höglund wrote: On Friday 12 July 2013, Chad Versace wrote: On 07/11/2013 10:18 PM, Paul Berry wrote: Another possibility that Chad suggested when I was talking to him this afternoon is to just just return BAD_MATCH if the client supplies the forward-compatibility flag when requesting a 3.0+ context. Rationale: Mesa doesn't really support the forward-compatibility flag anyhow (since the EGL and GLX front-ends just drop it on the floor), and besides we don't know of any shipping apps that require it (the flag is intended as a developer aid, so it's unlikely that published apps rely on it). I don't have a really strong opinion about is, so I'll let Chad weigh in if he wants to champion this alternative. Let's fix Mesa to simply emit EGL_BAD_MATCH if the user requests a forward- compatible context. I don't believe we have the right balance of resources and interest to properly implement and test support for the forward-compatible flag. No one users are asking for it, and it's likely nearly no one will use it. The future may change this situation, but that's a big 'may'. KWin always sets the forward-compatible bit in 4.11, but it's not too late to change that. It appears to be accepted by all implementations and has no negative side effects, so there was no compelling reason to leave it out in a release build. For what GL context versions does KWin set the forward-compatible bit? For 3.0 only? For all versions >= 3.0? For that matter, what context versions does KWin request? It first tries to create a 3.1 forward-compatible context. If that fails, it tries to create a context with the version set to 1.2, and without the forward-compatible bit set. There are currently no real functional differences between the 3.1 and the 2.x paths in KWin. The main motivation for adding the option to create a 3.1 context was the thinking at the time that Mesa would only enable threaded dispatch in a core context. core context != forward-compatible context Just requesting OpenGL 3.1 would have been sufficient. Why does KWin set the forward-compatible bit? There must be some motivation for that, other than "the button is there so let's push it". It's to ensure that we're not using deprecated features in the 3.x paths, and more importantly that no one introduces new code that uses deprecated features. That's a good idea for debug builds, but I'm not so sure about release builds. Hmm... In practice it seems that both Mesa and the NVIDIA driver ignores the flag though, which I guess is a good reason not to set it. If you know specific cases where we do the wrong thing, I'd like to have bug reports. I think we figured out that we've totally botched the GLSL side, but I think the API side /should/ be correct. Fredrik ___ 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
[Mesa-dev] The forward-compatible bit question
If the user creates a context with EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR set, must Mesa return a context of *exactly* that version. For example, if the user requests a 3.0 context with the forward-compatible bit set, is Mesa required to return a 3.0 context but not allowed to return a 3.1 context? Here's the pertinent portion of the EGL_KHR_create_context spec. Perhaps I'm interpreting the keywords "specific" and "exactly" too strictly. How do you interpret this? Because the purpose of forward-compatible contexts is to allow application development on a specific OpenGL version with the knowledge that the app will run on a future version, context creation will fail if EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR is set and the context version returned cannot implement exactly the requested version. Do we know what the other vendors do (Intel Windows, Nvidia, AMD)? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
On 07/15/2013 02:05 PM, Ian Romanick wrote: On 07/15/2013 06:26 AM, Fredrik Höglund wrote: On Friday 12 July 2013, Chad Versace wrote: On 07/12/2013 12:25 PM, Fredrik Höglund wrote: On Friday 12 July 2013, Chad Versace wrote: On 07/11/2013 10:18 PM, Paul Berry wrote: There are currently no real functional differences between the 3.1 and the 2.x paths in KWin. The main motivation for adding the option to create a 3.1 context was the thinking at the time that Mesa would only enable threaded dispatch in a core context. core context != forward-compatible context Just requesting OpenGL 3.1 would have been sufficient. Just requesting OpenGL 3.1 would have been sufficient for Mesa, because it no Mesa driver creates an GL 3.1 context with the GL_ARB_compatibility extension. But, according to the spec, implementations are allowed to return a GL 3.1 context *with or without* the GL_ARB_compatibility extension when the user requests a 3.1 context. So, the only way to ensure that your 3.1 context won't have GL_ARB_compatibility is to request a context with the forward-compatible bit. Why does KWin set the forward-compatible bit? There must be some motivation for that, other than "the button is there so let's push it". It's to ensure that we're not using deprecated features in the 3.x paths, and more importantly that no one introduces new code that uses deprecated features. That's a good idea for debug builds, but I'm not so sure about release builds. Hmm... I concur. I think it would be wise to enable that flag only for development builds. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] The forward-compatible bit question
On Mon, Jul 15, 2013 at 2:08 PM, Chad Versace wrote: > If the user creates a context with > EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR set, > must Mesa return a context of *exactly* that version. For example, if the > user requests > a 3.0 context with the forward-compatible bit set, is Mesa required to > return a 3.0 > context but not allowed to return a 3.1 context? It should return the precise version requested. That's always been my understanding. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix sRGB renderbuffers without EXT_framebuffer_sRGB support
https://bugs.freedesktop.org/show_bug.cgi?id=59322
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_cb_fbo.c | 8
src/mesa/state_tracker/st_format.c | 7 +++
2 files changed, 15 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 826722b..77aaccd 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -37,6 +37,7 @@
#include "main/context.h"
#include "main/fbobject.h"
#include "main/framebuffer.h"
+#include "main/glformats.h"
#include "main/macros.h"
#include "main/renderbuffer.h"
@@ -132,6 +133,13 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
pipe_surface_reference( &strb->surface, NULL );
pipe_resource_reference( &strb->texture, NULL );
+ /* If an sRGB framebuffer is unsupported, sRGB formats behave like linear
+* formats.
+*/
+ if (!ctx->Extensions.EXT_framebuffer_sRGB) {
+ internalFormat = _mesa_get_linear_internalformat(internalFormat);
+ }
+
/* Handle multisample renderbuffers first.
*
* From ARB_framebuffer_object:
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 16d977f..64bfd1f 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -1782,6 +1782,13 @@ st_QuerySamplesForFormat(struct gl_context *ctx, GLenum
target,
else
bind = PIPE_BIND_RENDER_TARGET;
+ /* If an sRGB framebuffer is unsupported, sRGB formats behave like linear
+* formats.
+*/
+ if (!ctx->Extensions.EXT_framebuffer_sRGB) {
+ internalFormat = _mesa_get_linear_internalformat(internalFormat);
+ }
+
/* Set sample counts in descending order. */
for (i = 16; i > 1; i--) {
format = st_choose_format(st, internalFormat, GL_NONE, GL_NONE,
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Trying MSAAx2 (r300g) on RS690/AMD Radeon X1200 128MB
Hi Bryan, I have just pushed a fix for a lockup in MSAA resolve: http://cgit.freedesktop.org/mesa/mesa/commit/?id=7969b567bd4361b44ead6ed5eb86218769a025be Feel free to try MSAA again. Marek On Fri, Jan 25, 2013 at 9:30 PM, Bryan Quigley wrote: > When trying glxgears the screen locks up, and SSH eventually stops > responding as well, but I was able to get these messages from kern.log: > > [ 790.516059] radeon :01:05.0: >GPU lockup CP stall for more than > 1msec > [ 790.516076] radeon :01:05.0: >GPU lockup (waiting for > 0x215b last fence id 0x2157) > [ 790.664495] radeon: wait for empty RBBM fifo failed ! Bad things might > happen. > [ 790.793829] Failed to wait GUI idle while programming pipes. Bad things > might happen. > [ 790.794831] radeon :01:05.0: >(rs600_asic_reset:357) > RBBM_STATUS=0x9411C100 > [ 791.292885] radeon :01:05.0: >(rs600_asic_reset:377) > RBBM_STATUS=0x9401C100 > [ 791.789934] radeon :01:05.0: >(rs600_asic_reset:385) > RBBM_STATUS=0x9400C100 > > Testing as requested in commit 8ed6b1400. Using the oibaf PPA on a Quantal > Lubuntu LiveUSB. I just upgraded mesa from oibaf repo this second time, but > it still crashed when I did everything (Xorg/libdrm). Unfortunately, I can > only do live testing on this machine and using the persistence file didn't > seem to work with the big Xorg changes required, so upgrading mesa will be > done fresh for every test. > > Thanks, > 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
[Mesa-dev] [Bug 66558] RS690: 3D artifacts when playing SuperTuxKart
https://bugs.freedesktop.org/show_bug.cgi?id=66558 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Olšák --- I committed the patch as 22427640b248aeb9875b40b216d27bedb13a1db8. Closing. -- 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 RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
On 07/15/2013 02:14 PM, Chad Versace wrote: On 07/15/2013 02:05 PM, Ian Romanick wrote: On 07/15/2013 06:26 AM, Fredrik Höglund wrote: On Friday 12 July 2013, Chad Versace wrote: On 07/12/2013 12:25 PM, Fredrik Höglund wrote: On Friday 12 July 2013, Chad Versace wrote: On 07/11/2013 10:18 PM, Paul Berry wrote: There are currently no real functional differences between the 3.1 and the 2.x paths in KWin. The main motivation for adding the option to create a 3.1 context was the thinking at the time that Mesa would only enable threaded dispatch in a core context. core context != forward-compatible context Just requesting OpenGL 3.1 would have been sufficient. Just requesting OpenGL 3.1 would have been sufficient for Mesa, because it no Mesa driver creates an GL 3.1 context with the GL_ARB_compatibility extension. But, according to the spec, implementations are allowed to return a GL 3.1 context *with or without* the GL_ARB_compatibility extension when the user requests a 3.1 context. So, the only way to ensure that your 3.1 context won't have GL_ARB_compatibility is to request a context with the forward-compatible bit. Right... but he was talking about using that to get at some other Mesa-specific feature... that we never finished. :) Why does KWin set the forward-compatible bit? There must be some motivation for that, other than "the button is there so let's push it". It's to ensure that we're not using deprecated features in the 3.x paths, and more importantly that no one introduces new code that uses deprecated features. That's a good idea for debug builds, but I'm not so sure about release builds. Hmm... I concur. I think it would be wise to enable that flag only for development builds. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/5] main: do nothing in the ff fragment shader when using the core profile.
On 07/12/2013 06:25 PM, Paul Berry wrote: When the core profile is active, there is no fixed function fragment shader functionality. However, we still need to generate a dummy fragment shader program in case the back-end expects it (e.g. to cover the case where GL_RASTERIZER_DISCARD is active and the client hasn't supplied a fragment shader). This patch makes the dummy fragment shader program do nothing when the core profile is active. This will prevent breakages in later patches, when we stop exposing compatibility-only builtin variables in the core profile. Does this have potential interactions with meta? --- src/mesa/main/ff_fragment_shader.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/ff_fragment_shader.cpp b/src/mesa/main/ff_fragment_shader.cpp index 86317ef..713e52a 100644 --- a/src/mesa/main/ff_fragment_shader.cpp +++ b/src/mesa/main/ff_fragment_shader.cpp @@ -1331,7 +1331,7 @@ create_new_program(struct gl_context *ctx, struct state_key *key) main_f->add_signature(main_sig); p.instructions = &main_sig->body; - if (key->num_draw_buffers) + if (key->num_draw_buffers && ctx->API != API_OPENGL_CORE) emit_instructions(&p); validate_ir_tree(p.shader->ir); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa Help
Hi Brian, Thank you so much for your time and help along, up to this point, the code make much more sense to me.However, I have a few more questions here, hope that you will be able to help me out. I am wondering Where the aa_general_rgba_line() and aa_rgba_line() functions defined?When and where the functions in s_aalinetemp.h and s_aaline.c are called/used?Are the draw_line, draw_triangle, draw_point functions in OSMesa some how connected with src/mesa/main/line.c or point.c?Is it possible to take out some required functions for example aa_rgba_line(), gl_context, etc. and compile it on my system so that I can draw a line into the framebuffer? (Or since there are too many functions linked together, you would not recommend me to do that?) Thanks Andy. > Date: Mon, 15 Jul 2013 08:24:58 -0600 > From: bri...@vmware.com > To: lilap...@hotmail.com > CC: mesa-dev@lists.freedesktop.org > Subject: Re: [Mesa-dev] OSMesa Help > > On 07/14/2013 09:34 PM, Andy Li wrote: > > Hi, > > > > I have some questions on the OSMesa code. > > As you suggested, I have continue looking into the swrast code. > > However, I have trouble figuring out how the code works exactly. > > Now I am now only focusing on the functions which draw lines. > > As I look into s_lines.c, I saw the _swrast_choose_line(). > > And depends on different cases, it will call > > > > _swrast_choose_aa_line_function(ctx) > > or > > USE(general_line) > > or > > USE(rgba_line) > > or > > USE(simple_no_z_rgba_line) > > etc. > > > > The first thing I did is looking into the > > _swrast_choose_aa_line_function() and it direct me to s_aaline.c > > In that file, I saw the struct of LineInfo and other computation > > functions for plane. > > Then I looked at the _swrast_choose_aa_line_function() > > > > and when I saw the code: > > swrast->Line = aa_general_rgba_line; > > and > > swrast->Line = aa_rgba_line; > > > > I am not sure what do they mean. And I won't be able to continue finding > > useful info. > > aa_rgba_line() drawns a "simple" RGBA antialiased line while > aa_general_rgba_line() also computes texture coords, fog coord, etc. > > > > > I think the main problem I am having is I am not sure what are the steps > > OSMesa have to take in order to draw a line into the frame buffer. > > Would you be able to explain a bit on that? (what are the steps OSMesa > > have to take in order to draw a line into the frame buffer?) > > Does drawing a line involve computing the plane? > > AA lines are drawn by drawing a quadrilateral and computing pixel > coverage involves computing plane equations. > > > What do s_aaline.c and s_aalinetemp.h actually mean? > > the "temp" files contain template code that's re-used multiple times in > the .c file. > > > > What is USE(general_line) ? Where is USE() define? > > grep "define USE" src/mesa/swrast/*.[ch] > > > > What is swrast->Line = aa_general_rgba_line;? > > swrast->Line is a function pointer that points to the current line > drawing function. The function is chosen by examining current GL > rasterization state. > > > > Would you suggest any debugging tool for me so that I can trace which > > functions are called while the program is running? > > For example I have the code below: > > glBegin(GL_LINES); > > glVertex3f(0.0, 0.0, 0.0); > > glVertex3f(15, 0, 0); > > glEnd(); > > Is there any debugging tool which can trace glVertex3f back in the > > library and see how OSMesa works? > > I have tried using gdb, however, it would only by-pass the call the go > > to the next command. > > You'll need to build mesa for debugging (CFLAGS="-g -O0" > --enable-debug). But I don't really have time to explain all the > nuances of debugging/tracing in Mesa. I'm not sure that'd really help > you anyway. > > In general, when you drawing points/lines/triangles the s_points.c or > s_lines.c or s_triangle.c code winds up calling _swrast_write_rgba() > span. This function does Z testing, texturing, stippling, etc before > calling a "put_pixels" or "put_row" function. Those functions call a > "pack" function to pack an array of RGBA ubyte/float values into the > framebuffer. Packing involves converting a canonical RGBA format into a > specific pixel format, like RGBA, or RGB565, etc. The color buffer > address, stride, etc. is obtained earlier through a call to > ctx->Driver.MapRenderbuffer(). In the case of OSMesa, the color buffer > is ordinary malloc'd memory that the user allocated. > > -Brian > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 00/12] Enable GL_AMD_vertex_shader_layer extension
git://people.freedesktop.org/~jljusten/mesa ivb-full-depth-buffer-v1 This series converts DEPTH_BUFFER to use the LOD and minimum array element fields and always points the depth, hiz and stencil buffers at the top of the miptree surface. This should allows us to support layered rendering, although testing of this is not completed. Layered rendering will be required for GL 3.2 / GLSL 1.50 support, but it can also be exposed via the GL_AMD_vertex_shader_layer extension. Testing on this series (IVB and HSW): * Piglit: Fixes array-depth-roundtrip * Basic visual inspection of Unigine Tropics Jordan Justen (12): i965: init global state first in brw_workaround_depthstencil_alignment gen7 depth surface: calculate more specific surface type gen7 depth surface: calculate depth (array size) for depth surface gen7 depth surface: calculate LOD being rendered to gen7 depth surface: determine if layered rendering is being used gen7 depth surface: calculate minimum array element being rendered gen7 blorp depth: calculate base surface width/height hsw hiz: Add new size restrictions for miplevels > 0 gen7 depth surface: program 3DSTATE_DEPTH_BUFFER to top of surface hsw hiz: Remove x/y offset restriction for hiz i965 gen7: don't set FORCE_ZERO_RTAINDEX in clip state intel: enable GL_AMD_vertex_shader_layer extension for gen7+ src/mesa/drivers/dri/i965/brw_misc_state.c| 25 +-- src/mesa/drivers/dri/i965/brw_tex_layout.c| 10 +-- src/mesa/drivers/dri/i965/gen7_blorp.cpp | 93 - src/mesa/drivers/dri/i965/gen7_clip_state.c |3 +- src/mesa/drivers/dri/i965/gen7_misc_state.c | 87 --- src/mesa/drivers/dri/i965/intel_extensions.c |4 ++ src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 30 +++- 7 files changed, 157 insertions(+), 95 deletions(-) -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 01/12] i965: init global state first in brw_workaround_depthstencil_alignment
In a future pass this will allow us to exit-early from this
routine to disable it for gen >= 7.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 0ab1e76..1e31ad8 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -341,6 +341,20 @@ brw_workaround_depthstencil_alignment(struct brw_context
*brw,
if (depth_irb)
depth_mt = depth_irb->mt;
+ /* Initialize brw->depthstencil to 'nop' workaround state.
+*/
+ brw->depthstencil.tile_x = 0;
+ brw->depthstencil.tile_y = 0;
+ brw->depthstencil.depth_offset = 0;
+ brw->depthstencil.stencil_offset = 0;
+ brw->depthstencil.hiz_offset = 0;
+ brw->depthstencil.depth_mt = NULL;
+ brw->depthstencil.stencil_mt = NULL;
+ if (depth_irb)
+ brw->depthstencil.depth_mt = depth_mt;
+ if (stencil_irb)
+ brw->depthstencil.stencil_mt = get_stencil_miptree(stencil_irb);
+
/* Check if depth buffer is in depth/stencil format. If so, then it's only
* safe to invalidate it if we're also clearing stencil, and both depth_irb
* and stencil_irb point to the same miptree.
@@ -515,11 +529,6 @@ brw_workaround_depthstencil_alignment(struct brw_context
*brw,
*/
brw->depthstencil.tile_x = tile_x;
brw->depthstencil.tile_y = tile_y;
- brw->depthstencil.depth_offset = 0;
- brw->depthstencil.stencil_offset = 0;
- brw->depthstencil.hiz_offset = 0;
- brw->depthstencil.depth_mt = NULL;
- brw->depthstencil.stencil_mt = NULL;
if (depth_irb) {
depth_mt = depth_irb->mt;
brw->depthstencil.depth_mt = depth_mt;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 02/12] gen7 depth surface: calculate more specific surface type
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp| 11 +++
src/mesa/drivers/dri/i965/gen7_misc_state.c | 26 ++
2 files changed, 37 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index acd6237..32dadf7 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -657,12 +657,23 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
uint32_t draw_x = params->depth.x_offset;
uint32_t draw_y = params->depth.y_offset;
uint32_t tile_mask_x, tile_mask_y;
+ uint32_t surftype;
+ GLenum gl_target = params->depth.mt->target;
brw_get_depthstencil_tile_masks(params->depth.mt,
params->depth.level,
params->depth.layer,
NULL,
&tile_mask_x, &tile_mask_y);
+ switch (gl_target) {
+ case GL_TEXTURE_CUBE_MAP_ARRAY:
+ case GL_TEXTURE_CUBE_MAP:
+ surftype = BRW_SURFACE_2D;
+ break;
+ default:
+ surftype = translate_tex_target(gl_target);
+ break;
+ }
/* 3DSTATE_DEPTH_BUFFER */
{
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index fe63fef..b3734e0 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -21,6 +21,7 @@
* IN THE SOFTWARE.
*/
+#include "main/mtypes.h"
#include "intel_batchbuffer.h"
#include "intel_mipmap_tree.h"
#include "intel_regions.h"
@@ -40,9 +41,34 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
uint32_t tile_x, uint32_t tile_y)
{
struct gl_context *ctx = &brw->ctx;
+ struct gl_framebuffer *fb = ctx->DrawBuffer;
+ uint32_t surftype;
+ GLenum gl_target = GL_TEXTURE_2D;
+ const struct intel_renderbuffer *irb = NULL;
+ const struct gl_renderbuffer *rb = NULL;
intel_emit_depth_stall_flushes(brw);
+ irb = intel_get_renderbuffer(fb, BUFFER_DEPTH);
+ if (!irb)
+ irb = intel_get_renderbuffer(fb, BUFFER_STENCIL);
+ rb = (struct gl_renderbuffer*) irb;
+
+ if (rb) {
+ if (rb->TexImage)
+ gl_target = rb->TexImage->TexObject->Target;
+ }
+
+ switch (gl_target) {
+ case GL_TEXTURE_CUBE_MAP_ARRAY:
+ case GL_TEXTURE_CUBE_MAP:
+ surftype = BRW_SURFACE_2D;
+ break;
+ default:
+ surftype = translate_tex_target(gl_target);
+ break;
+ }
+
/* _NEW_DEPTH, _NEW_STENCIL, _NEW_BUFFERS */
BEGIN_BATCH(7);
OUT_BATCH(GEN7_3DSTATE_DEPTH_BUFFER << 16 | (7 - 2));
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 03/12] gen7 depth surface: calculate depth (array size) for depth surface
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp|2 ++
src/mesa/drivers/dri/i965/gen7_misc_state.c |3 +++
2 files changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 32dadf7..1ec05ad 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -658,6 +658,7 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
uint32_t draw_y = params->depth.y_offset;
uint32_t tile_mask_x, tile_mask_y;
uint32_t surftype;
+ int depth = MAX2(params->depth.mt->logical_depth0, 1);
GLenum gl_target = params->depth.mt->target;
brw_get_depthstencil_tile_masks(params->depth.mt,
@@ -669,6 +670,7 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
case GL_TEXTURE_CUBE_MAP_ARRAY:
case GL_TEXTURE_CUBE_MAP:
surftype = BRW_SURFACE_2D;
+ depth *= 6;
break;
default:
surftype = translate_tex_target(gl_target);
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index b3734e0..798da41 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -43,6 +43,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
struct gl_context *ctx = &brw->ctx;
struct gl_framebuffer *fb = ctx->DrawBuffer;
uint32_t surftype;
+ int depth = 1;
GLenum gl_target = GL_TEXTURE_2D;
const struct intel_renderbuffer *irb = NULL;
const struct gl_renderbuffer *rb = NULL;
@@ -55,6 +56,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
rb = (struct gl_renderbuffer*) irb;
if (rb) {
+ depth = MAX2(rb->Depth, 1);
if (rb->TexImage)
gl_target = rb->TexImage->TexObject->Target;
}
@@ -63,6 +65,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
case GL_TEXTURE_CUBE_MAP_ARRAY:
case GL_TEXTURE_CUBE_MAP:
surftype = BRW_SURFACE_2D;
+ depth *= 6;
break;
default:
surftype = translate_tex_target(gl_target);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 04/12] gen7 depth surface: calculate LOD being rendered to
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp|3 +++
src/mesa/drivers/dri/i965/gen7_misc_state.c |3 +++
2 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 1ec05ad..7df78f6 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -660,6 +660,7 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
uint32_t surftype;
int depth = MAX2(params->depth.mt->logical_depth0, 1);
GLenum gl_target = params->depth.mt->target;
+ int lod;
brw_get_depthstencil_tile_masks(params->depth.mt,
params->depth.level,
@@ -677,6 +678,8 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
break;
}
+ lod = params->depth.level - params->depth.mt->first_level;
+
/* 3DSTATE_DEPTH_BUFFER */
{
uint32_t tile_x = draw_x & tile_mask_x;
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 798da41..14257cc 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -45,6 +45,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
uint32_t surftype;
int depth = 1;
GLenum gl_target = GL_TEXTURE_2D;
+ int lod;
const struct intel_renderbuffer *irb = NULL;
const struct gl_renderbuffer *rb = NULL;
@@ -72,6 +73,8 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
break;
}
+ lod = irb ? irb->mt_level - irb->mt->first_level : 0;
+
/* _NEW_DEPTH, _NEW_STENCIL, _NEW_BUFFERS */
BEGIN_BATCH(7);
OUT_BATCH(GEN7_3DSTATE_DEPTH_BUFFER << 16 | (7 - 2));
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 06/12] gen7 depth surface: calculate minimum array element being rendered
In layered rendering this will be 0. Otherwise it will be the
selected slice.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp|6 ++
src/mesa/drivers/dri/i965/gen7_misc_state.c |9 +
2 files changed, 15 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 7df78f6..3d1710e 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -659,6 +659,7 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
uint32_t tile_mask_x, tile_mask_y;
uint32_t surftype;
int depth = MAX2(params->depth.mt->logical_depth0, 1);
+ int min_array_element;
GLenum gl_target = params->depth.mt->target;
int lod;
@@ -678,6 +679,11 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
break;
}
+ min_array_element = params->depth.layer;
+ if (params->depth.mt->num_samples > 1) {
+ min_array_element /= params->depth.mt->num_samples;
+ }
+
lod = params->depth.level - params->depth.mt->first_level;
/* 3DSTATE_DEPTH_BUFFER */
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 404d7d2..87fbfaa 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -45,6 +45,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
struct gl_framebuffer *fb = ctx->DrawBuffer;
uint32_t surftype;
int depth = 1;
+ int min_array_element;
GLenum gl_target = GL_TEXTURE_2D;
int lod;
bool layered = false;
@@ -84,6 +85,14 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
break;
}
+ if (layered || !irb) {
+ min_array_element = 0;
+ } else if (irb->mt->num_samples > 1) {
+ min_array_element = irb->mt_layer / irb->mt->num_samples;
+ } else {
+ min_array_element = irb->mt_layer;
+ }
+
lod = irb ? irb->mt_level - irb->mt->first_level : 0;
/* _NEW_DEPTH, _NEW_STENCIL, _NEW_BUFFERS */
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 05/12] gen7 depth surface: determine if layered rendering is being used
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_misc_state.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 14257cc..404d7d2 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -22,6 +22,7 @@
*/
#include "main/mtypes.h"
+#include "main/fbobject.h"
#include "intel_batchbuffer.h"
#include "intel_mipmap_tree.h"
#include "intel_regions.h"
@@ -46,6 +47,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
int depth = 1;
GLenum gl_target = GL_TEXTURE_2D;
int lod;
+ bool layered = false;
const struct intel_renderbuffer *irb = NULL;
const struct gl_renderbuffer *rb = NULL;
@@ -62,6 +64,15 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
gl_target = rb->TexImage->TexObject->Target;
}
+ if (_mesa_is_user_fbo(fb)) {
+ const struct gl_renderbuffer_attachment *depth_att =
+ _mesa_get_attachment(ctx, fb, GL_DEPTH_ATTACHMENT);
+ const struct gl_renderbuffer_attachment *stencil_att =
+ _mesa_get_attachment(ctx, fb, GL_STENCIL_ATTACHMENT);
+ layered = (depth_att && depth_att->Layered) ||
+(stencil_att && stencil_att->Layered);
+ }
+
switch (gl_target) {
case GL_TEXTURE_CUBE_MAP_ARRAY:
case GL_TEXTURE_CUBE_MAP:
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 07/12] gen7 blorp depth: calculate base surface width/height
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 3d1710e..a5863f8 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -657,6 +657,7 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
uint32_t draw_x = params->depth.x_offset;
uint32_t draw_y = params->depth.y_offset;
uint32_t tile_mask_x, tile_mask_y;
+ uint32_t surfwidth, surfheight;
uint32_t surftype;
int depth = MAX2(params->depth.mt->logical_depth0, 1);
int min_array_element;
@@ -686,6 +687,18 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
lod = params->depth.level - params->depth.mt->first_level;
+ if (params->hiz_op != GEN6_HIZ_OP_NONE && lod == 0) {
+ /* HIZ ops for lod 0 may set the width & height a little
+ * larger to allow the fast depth clear to fit the hardware
+ * alignment requirements. (8x4)
+ */
+ surfwidth = params->depth.width;
+ surfheight = params->depth.height;
+ } else {
+ surfwidth = params->depth.mt->physical_width0;
+ surfheight = params->depth.mt->physical_height0;
+ }
+
/* 3DSTATE_DEPTH_BUFFER */
{
uint32_t tile_x = draw_x & tile_mask_x;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 08/12] hsw hiz: Add new size restrictions for miplevels > 0
When performing hiz ops, we must ensure that the region sizes
have an 8 aligned width and 4 aligned height. We can tweak the
size for blorp hiz operations at LOD 0, but for the others we
can't. Therefore, we disable hiz for these miplevels if they
don't meet the size alignment requirements.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 36a080f..d6988e0 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1264,9 +1264,19 @@ intel_miptree_slice_enable_hiz(struct brw_context *brw,
* stencil buffer tile size, 64x64 pixels, then
* 3DSTATE_DEPTH_BUFFER.Depth_Coordinate_Offset_X/Y is set to 0.
*/
- uint32_t depth_x_offset = mt->level[level].slice[layer].x_offset;
- uint32_t depth_y_offset = mt->level[level].slice[layer].y_offset;
- if ((depth_x_offset & 63) || (depth_y_offset & 63)) {
+ const struct intel_mipmap_level *l = &mt->level[level];
+ const struct intel_mipmap_slice *s = &l->slice[layer];
+ if ((s->x_offset & 63) || (s->y_offset & 63)) {
+ return false;
+ }
+
+ /* Disable HiZ for LOD > 0 unless the width is 8 aligned
+ * and the height is 4 aligned. This allows our HiZ support
+ * to fulfill Haswell restrictions for HiZ ops. For LOD == 0,
+ * we can grow the width & height to allow the HiZ op to
+ * force the proper size alignments.
+ */
+ if (level > 0 && ((l->width & 7) || (l->height & 3))) {
return false;
}
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 10/12] hsw hiz: Remove x/y offset restriction for hiz
This restriction was related to programming the offset fields
of the depth buffer packet. We are now setting these offsets
to 0 now, so this restriction should no longer be required.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 24
1 file changed, 24 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index d6988e0..900e1c2 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1244,31 +1244,7 @@ intel_miptree_slice_enable_hiz(struct brw_context *brw,
assert(mt->hiz_mt);
if (brw->is_haswell) {
- /* Disable HiZ for some slices to work around a hardware bug.
- *
- * Haswell hardware fails to respect
- * 3DSTATE_DEPTH_BUFFER.Depth_Coordinate_Offset_X/Y when during HiZ
- * ambiguate operations. The failure is inconsistent and affected by
- * other GPU contexts. Running a heavy GPU workload in a separate
- * process causes the failure rate to drop to nearly 0.
- *
- * To workaround the bug, we enable HiZ only when we can guarantee that
- * the Depth Coordinate Offset fields will be set to 0. The function
- * brw_get_depthstencil_tile_masks() is used to calculate the fields,
- * and the function is sometimes called in such a way that the presence
- * of an attached stencil buffer changes the fuction's return value.
- *
- * The largest tile size considered by brw_get_depthstencil_tile_masks()
- * is that of the stencil buffer. Therefore, if this hiz slice's
- * corresponding depth slice has an offset that is aligned to the
- * stencil buffer tile size, 64x64 pixels, then
- * 3DSTATE_DEPTH_BUFFER.Depth_Coordinate_Offset_X/Y is set to 0.
- */
const struct intel_mipmap_level *l = &mt->level[level];
- const struct intel_mipmap_slice *s = &l->slice[layer];
- if ((s->x_offset & 63) || (s->y_offset & 63)) {
- return false;
- }
/* Disable HiZ for LOD > 0 unless the width is 8 aligned
* and the height is 4 aligned. This allows our HiZ support
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 09/12] gen7 depth surface: program 3DSTATE_DEPTH_BUFFER to top of surface
Previously we would always find the 2D sub-surface of interest,
and then program the surface to this location. Now we always
program the 3DSTATE_DEPTH_BUFFER at the start of the surface.
To select the lod/slice, we utilize the lod & minimum array
element fields.
As part of this change, we must revert 1f112ccf:
Revert "i965/gen7: Align all depth miplevels to 8 in the X direction."
We also must disable brw_workaround_depthstencil_alignment for
gen >= 7. Now the hardware will handle alignment when rendering
to additional slices/LODs.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_misc_state.c |6 +++
src/mesa/drivers/dri/i965/brw_tex_layout.c | 10 +
src/mesa/drivers/dri/i965/gen7_blorp.cpp| 58 +--
src/mesa/drivers/dri/i965/gen7_misc_state.c | 35
4 files changed, 43 insertions(+), 66 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 1e31ad8..3bf37b9 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -355,6 +355,12 @@ brw_workaround_depthstencil_alignment(struct brw_context
*brw,
if (stencil_irb)
brw->depthstencil.stencil_mt = get_stencil_miptree(stencil_irb);
+ /* Gen7+ doesn't require the workarounds, since we always program the
+* surface state at the start of the whole surface.
+*/
+ if (brw->gen >= 7)
+ return;
+
/* Check if depth buffer is in depth/stencil format. If so, then it's only
* safe to invalidate it if we're also clearing stencil, and both depth_irb
* and stencil_irb point to the same miptree.
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index ebc67b1..e4e66b4 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -78,15 +78,7 @@ intel_horizontal_texture_alignment_unit(struct brw_context
*brw,
if (format == MESA_FORMAT_S8)
return 8;
- /* The depth alignment requirements in the table above are for rendering to
-* depth miplevels using the LOD control fields. We don't use LOD control
-* fields, and instead use page offsets plus intra-tile x/y offsets, which
-* require that the low 3 bits are zero. To reduce the number of x/y
-* offset workaround blits we do, align the X to 8, which depth texturing
-* can handle (sadly, it can't handle 8 in the Y direction).
-*/
- if (brw->gen >= 7 &&
- _mesa_get_format_base_format(format) == GL_DEPTH_COMPONENT)
+ if (brw->gen >= 7 && format == MESA_FORMAT_Z16)
return 8;
return 4;
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index a5863f8..6543a93 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -653,10 +653,6 @@ static void
gen7_blorp_emit_depth_stencil_config(struct brw_context *brw,
const brw_blorp_params *params)
{
- struct gl_context *ctx = &brw->ctx;
- uint32_t draw_x = params->depth.x_offset;
- uint32_t draw_y = params->depth.y_offset;
- uint32_t tile_mask_x, tile_mask_y;
uint32_t surfwidth, surfheight;
uint32_t surftype;
int depth = MAX2(params->depth.mt->logical_depth0, 1);
@@ -664,11 +660,6 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
GLenum gl_target = params->depth.mt->target;
int lod;
- brw_get_depthstencil_tile_masks(params->depth.mt,
- params->depth.level,
- params->depth.layer,
- NULL,
- &tile_mask_x, &tile_mask_y);
switch (gl_target) {
case GL_TEXTURE_CUBE_MAP_ARRAY:
case GL_TEXTURE_CUBE_MAP:
@@ -701,34 +692,6 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
/* 3DSTATE_DEPTH_BUFFER */
{
- uint32_t tile_x = draw_x & tile_mask_x;
- uint32_t tile_y = draw_y & tile_mask_y;
- uint32_t offset =
- intel_region_get_aligned_offset(params->depth.mt->region,
- draw_x & ~tile_mask_x,
- draw_y & ~tile_mask_y, false);
-
- /* According to the Sandy Bridge PRM, volume 2 part 1, pp326-327
- * (3DSTATE_DEPTH_BUFFER dw5), in the documentation for "Depth
- * Coordinate Offset X/Y":
- *
- * "The 3 LSBs of both offsets must be zero to ensure correct
- * alignment"
- *
- * We have no guarantee that tile_x and tile_y are correctly aligned,
- * since they are determined by the mipmap layout, which is only aligned
- * to multiples of 4.
- *
- * So, to avoid hanging the GPU, just smash the low order 3 bits of
- * tile_x and tile_y to 0. This is a temporary workaround until we come
- * up with
[Mesa-dev] [RFC PATCH 12/12] intel: enable GL_AMD_vertex_shader_layer extension for gen7+
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_extensions.c |4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 1e762ef..2db7cb4 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -129,6 +129,10 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Const.GLSLVersion = 120;
_mesa_override_glsl_version(ctx);
+ if (brw->gen >= 7) {
+ ctx->Extensions.AMD_vertex_shader_layer = true;
+ }
+
if (brw->gen >= 6) {
uint64_t dummy;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 11/12] i965 gen7: don't set FORCE_ZERO_RTAINDEX in clip state
We now also need to stop setting the FORCE_ZERO_RTAINDEX bit in the clip date so render target array values other than zero can be used. Signed-off-by: Jordan Justen --- src/mesa/drivers/dri/i965/gen7_clip_state.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/gen7_clip_state.c b/src/mesa/drivers/dri/i965/gen7_clip_state.c index 36a793c..e0ed882 100644 --- a/src/mesa/drivers/dri/i965/gen7_clip_state.c +++ b/src/mesa/drivers/dri/i965/gen7_clip_state.c @@ -117,8 +117,7 @@ upload_clip_state(struct brw_context *brw) GEN6_CLIP_XY_TEST | dw2); OUT_BATCH(U_FIXED(0.125, 3) << GEN6_CLIP_MIN_POINT_WIDTH_SHIFT | - U_FIXED(255.875, 3) << GEN6_CLIP_MAX_POINT_WIDTH_SHIFT | - GEN6_CLIP_FORCE_ZERO_RTAINDEX); + U_FIXED(255.875, 3) << GEN6_CLIP_MAX_POINT_WIDTH_SHIFT); ADVANCE_BATCH(); } -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66931] Can't specify local buffer size using clSetKernelArg
https://bugs.freedesktop.org/show_bug.cgi?id=66931 --- Comment #2 from Tom Stellard --- (In reply to comment #1) > Created attachment 82462 [details] > Addess spaces support for kernel arguments > > Use the data from getAddressSpaceMap to determine the correct type of the > kernel arguments. This patch looks good to me, can you send it to mesa-dev@lists.freedesktop.org. I think for r600g to work correctly, you will also need to make sure we are writing the correct lds size to the SQ_LDS_ALLOC register. I think what we want is the size reported by clover plus the size reported by the compiler. -- 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] [PATCH 00/14] Qualifier ordering for 420pack
Hello! The GL_ARB_shading_language_420pack allows qualifiers to be specified in a flexible order, which is nice now that there are so many different qualifiers. Yet, we still need to support the old language semantics which enforce a particular ordering as well. Previously, we handled the ordering requirements using the GLSL 1.50 grammar rules. This obviously can't handle the flexible ordering, so so I had to rewrite the grammar to allow qualifiers in any order, then add C code to enforce the pre-4.20 ordering restrictions. No regressions observed on Piglit or ES3, though we need a bunch more tests. A few extra are in the 'qualifiers' branch of ~kwg/piglit, though I believe Matt is writing more. I'm hoping to land this before Thursday. With one more tiny feature, we can enable 420pack for 9.2... Please review...sooner rather than later :) The series is available as the 'qualifiers' branch of ~kwg/mesa; if applying from the mailing list, apply these first: glsl: Silence the last shift/reduce conflict warning in the grammar. glsl: Fail the build if the grammar contains shift/reduce errors. glsl: Fix absurd whitespace conventions in the parser. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/14] glsl: Add a new ast_type_qualifier::has_layout() method.
This makes it easy to check if any layout qualifiers are set.
Signed-off-by: Kenneth Graunke
---
src/glsl/ast.h| 5 +
src/glsl/ast_type.cpp | 18 ++
2 files changed, 23 insertions(+)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index c0350e7..441b389 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -458,6 +458,11 @@ struct ast_type_qualifier {
bool has_interpolation() const;
/**
+* Return whether a layout qualifier is present.
+*/
+ bool has_layout() const;
+
+ /**
* \brief Return string representation of interpolation qualifier.
*
* If an interpolation qualifier is present, then return that qualifier's
diff --git a/src/glsl/ast_type.cpp b/src/glsl/ast_type.cpp
index be84550..4e870a7 100644
--- a/src/glsl/ast_type.cpp
+++ b/src/glsl/ast_type.cpp
@@ -56,6 +56,24 @@ bool ast_type_qualifier::has_interpolation() const
|| this->flags.q.noperspective;
}
+bool
+ast_type_qualifier::has_layout() const
+{
+ return this->flags.q.origin_upper_left
+ || this->flags.q.pixel_center_integer
+ || this->flags.q.depth_any
+ || this->flags.q.depth_greater
+ || this->flags.q.depth_less
+ || this->flags.q.depth_unchanged
+ || this->flags.q.std140
+ || this->flags.q.shared
+ || this->flags.q.column_major
+ || this->flags.q.row_major
+ || this->flags.q.packed
+ || this->flags.q.explicit_location
+ || this->flags.q.explicit_index;
+}
+
const char*
ast_type_qualifier::interpolation_string() const
{
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/14] glsl: Add a new ast_type_qualifier::has_auxiliary_storage() method.
"Auxiliary storage qualifiers" is the new term given to "centroid",
"patch", and "sample" by GLSL 4.20/GL_ARB_shading_language_420pack.
Even though we only support "centroid", it's useful to add this now
so that all auxiliary storage qualifiers get handled in the right places
once they're eventually supported.
Signed-off-by: Kenneth Graunke
---
src/glsl/ast.h| 5 +
src/glsl/ast_type.cpp | 6 ++
2 files changed, 11 insertions(+)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 78d24ae..816d5fc 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -468,6 +468,11 @@ struct ast_type_qualifier {
bool has_storage() const;
/**
+* Return whether an auxiliary storage qualifier is present.
+*/
+ bool has_auxiliary_storage() const;
+
+ /**
* \brief Return string representation of interpolation qualifier.
*
* If an interpolation qualifier is present, then return that qualifier's
diff --git a/src/glsl/ast_type.cpp b/src/glsl/ast_type.cpp
index 71bab99..dc03cca 100644
--- a/src/glsl/ast_type.cpp
+++ b/src/glsl/ast_type.cpp
@@ -86,6 +86,12 @@ ast_type_qualifier::has_storage() const
|| this->flags.q.uniform;
}
+bool
+ast_type_qualifier::has_auxiliary_storage() const
+{
+ return this->flags.q.centroid;
+}
+
const char*
ast_type_qualifier::interpolation_string() const
{
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/14] glsl: Add a new ast_type_qualifier::has_storage() method.
This makes it easy to check if any storage qualifiers are set.
XXX: I'm not sure if centroid should be in this or not
Signed-off-by: Kenneth Graunke
---
src/glsl/ast.h| 5 +
src/glsl/ast_type.cpp | 12
2 files changed, 17 insertions(+)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 441b389..78d24ae 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -463,6 +463,11 @@ struct ast_type_qualifier {
bool has_layout() const;
/**
+* Return whether a storage qualifier is present.
+*/
+ bool has_storage() const;
+
+ /**
* \brief Return string representation of interpolation qualifier.
*
* If an interpolation qualifier is present, then return that qualifier's
diff --git a/src/glsl/ast_type.cpp b/src/glsl/ast_type.cpp
index 4e870a7..71bab99 100644
--- a/src/glsl/ast_type.cpp
+++ b/src/glsl/ast_type.cpp
@@ -74,6 +74,18 @@ ast_type_qualifier::has_layout() const
|| this->flags.q.explicit_index;
}
+bool
+ast_type_qualifier::has_storage() const
+{
+ return this->flags.q.constant
+ || this->flags.q.attribute
+ || this->flags.q.varying
+ || this->flags.q.centroid
+ || this->flags.q.in
+ || this->flags.q.out
+ || this->flags.q.uniform;
+}
+
const char*
ast_type_qualifier::interpolation_string() const
{
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/14] glsl: Handle most qualifier ordering in C code rather than the grammar.
The GL_ARB_shading_language_420pack extension/GLSL 4.20 allow qualifiers
to be specified in (basically) any order. In order to support this, we
can't hardcode the ordering restrictions in the grammar.
This patch alters the grammar to accept invariant, storage, layout, and
interpolation qualifiers in any order, but adds C code to enforce the
ordering requirements. In the 420pack case, we should be able to simply
skip the error checks.
As a bonus, this also lets us generate decent error messages, rather
than Bison's awful "unexpected TOKEN" errors.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 110
1 file changed, 92 insertions(+), 18 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index b8f3df9..72bf560 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1314,34 +1314,108 @@ parameter_type_qualifier:
;
type_qualifier:
- storage_qualifier
- | layout_qualifier
- | layout_qualifier storage_qualifier
+ /* Single qualifiers */
+ INVARIANT
{
- $$ = $1;
- $$.flags.i |= $2.flags.i;
+ memset(& $$, 0, sizeof($$));
+ $$.flags.q.invariant = 1;
}
+ | storage_qualifier
| interpolation_qualifier
- | interpolation_qualifier storage_qualifier
- {
- $$ = $1;
- $$.flags.i |= $2.flags.i;
- }
- | INVARIANT storage_qualifier
+ | layout_qualifier
+
+ /* Multiple qualifiers:
+* In GLSL 4.20, these can be specified in any order. In earlier versions,
+* they appear in this order (see GLSL 1.50 section 4.7 & comments below):
+*
+*invariant interpolation storage precision ...or...
+*layout storage precision
+*
+* Each qualifier's rule ensures that the accumulated qualifiers on the
right
+* side don't contain any that must appear on the left hand side.
+* For example, when processing a storage qualifier, we check that there are
+* no interpolation, layout, or invariant qualifiers to the right.
+*/
+ | INVARIANT type_qualifier
{
+ if ($2.flags.q.invariant)
+ _mesa_glsl_error(&@1, state, "Duplicate \"invariant\" qualifier.\n");
+
+ if ($2.has_layout()) {
+ _mesa_glsl_error(&@1, state,
+ "\"invariant\" cannot be used with layout(...).\n");
+ }
+
$$ = $2;
$$.flags.q.invariant = 1;
}
- | INVARIANT interpolation_qualifier storage_qualifier
+ | interpolation_qualifier type_qualifier
+ {
+ /* Section 4.3 of the GLSL 1.40 specification states:
+ * "...qualified with one of these interpolation qualifiers"
+ *
+ * GLSL 1.30 claims to allow "one or more", but insists that:
+ * "These interpolation qualifiers may only precede the qualifiers in,
+ * centroid in, out, or centroid out in a declaration."
+ *
+ * ...which means that e.g. smooth can't precede smooth, so there can be
+ * only one after all, and the 1.40 text is a clarification, not a
change.
+ */
+ if ($2.has_interpolation())
+ _mesa_glsl_error(&@1, state, "Duplicate interpolation qualifier.\n");
+
+ if ($2.has_layout()) {
+ _mesa_glsl_error(&@1, state, "Interpolation qualifiers cannot be used
"
+ "with layout(...).\n");
+ }
+
+ if ($2.flags.q.invariant) {
+ _mesa_glsl_error(&@1, state, "Interpolation qualifiers must come "
+ "after \"invariant\".\n");
+ }
+
+ $$ = $1;
+ $$.flags.i |= $2.flags.i;
+ }
+ | layout_qualifier type_qualifier
{
- $$ = $2;
- $$.flags.i |= $3.flags.i;
- $$.flags.q.invariant = 1;
+ /* The GLSL 1.50 grammar indicates that a layout(...) declaration can be
+ * used standalone or immediately before a storage qualifier. It cannot
+ * be used with interpolation qualifiers or invariant. There does not
+ * appear to be any text indicating that it must come before the storage
+ * qualifier, but always seems to in examples.
+ */
+ if ($2.has_layout())
+ _mesa_glsl_error(&@1, state, "Duplicate layout(...) qualifiers.\n");
+
+ if ($2.flags.q.invariant)
+ _mesa_glsl_error(&@1, state, "layout(...) cannot be used with "
+ "the \"invariant\" qualifier\n");
+
+ if ($2.has_interpolation()) {
+ _mesa_glsl_error(&@1, state, "layout(...) cannot be used with "
+ "interpolation qualifiers.\n");
+ }
+
+ $$ = $1;
+ $$.flags.i |= $2.flags.i;
}
- | INVARIANT
+ | storage_qualifier type_qualifier
{
- memset(& $$, 0, sizeof($$));
- $$.flags.q.invariant = 1;
+ /* Section 4.3 of the GLSL 1.20 specification states:
+ * "Variable declarations may have a storage qualifier specified..."
+ * 1.30 clarifies this to "may have one storage qualifier".
+ */
+ if ($2.has_storage())
+ _mesa_glsl
[Mesa-dev] [PATCH 07/14] glsl: Refactor parameter qualifier handling.
"Parameter direction qualifier" is a new term I invented just now; it's
not part of any GLSL specification.
This paves the way handling multiple parameter qualifiers, in any order,
as required by GLSL 4.20/ARB_shading_language_420pack.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index e8d2879..c4b3b4f 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -180,6 +180,7 @@ static void yyerror(YYLTYPE *loc, _mesa_glsl_parse_state
*st, const char *msg)
%type parameter_declarator
%type parameter_declaration
%type parameter_qualifier
+%type parameter_direction_qualifier
%type parameter_type_qualifier
%type parameter_type_specifier
%type function_definition
@@ -903,7 +904,17 @@ parameter_qualifier:
{
memset(& $$, 0, sizeof($$));
}
- | IN_TOK
+ | parameter_direction_qualifier parameter_qualifier
+ {
+ if (($1.flags.q.in || $1.flags.q.out) && ($2.flags.q.in ||
$2.flags.q.out))
+ _mesa_glsl_error(&@1, state, "duplicate in/out/inout qualifier");
+
+ $$ = $1;
+ $$.merge_qualifier(&@1, state, $2);
+ }
+
+parameter_direction_qualifier:
+ IN_TOK
{
memset(& $$, 0, sizeof($$));
$$.flags.q.in = 1;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/14] glsl: Disable ordering checks on most qualifiers for 420pack.
This makes the compiler accept invariant, storage, layout, and
interpolation qualifiers in any order when ARB_shading_language_420pack
is enabled.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 72bf560..c31f5e2 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1369,7 +1369,7 @@ type_qualifier:
"with layout(...).\n");
}
- if ($2.flags.q.invariant) {
+ if (!state->ARB_shading_language_420pack_enable && $2.flags.q.invariant)
{
_mesa_glsl_error(&@1, state, "Interpolation qualifiers must come "
"after \"invariant\".\n");
}
@@ -1409,7 +1409,8 @@ type_qualifier:
if ($2.has_storage())
_mesa_glsl_error(&@1, state, "Duplicate storage qualifier.\n");
- if ($2.flags.q.invariant || $2.has_interpolation() || $2.has_layout()) {
+ if (!state->ARB_shading_language_420pack_enable &&
+ ($2.flags.q.invariant || $2.has_interpolation() || $2.has_layout()))
{
_mesa_glsl_error(&@1, state, "Storage qualifiers must come after "
"invariant, interpolation, and layout
qualifiers.\n");
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/14] glsl: Handle "const" as a parameter qualifier.
This will make it easy to support both "const in" and "in const", as
required by GLSL 4.20/ARB_shading_language_420pack.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 43 ++-
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index c4b3b4f..a4ab5a4 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -181,7 +181,6 @@ static void yyerror(YYLTYPE *loc, _mesa_glsl_parse_state
*st, const char *msg)
%type parameter_declaration
%type parameter_qualifier
%type parameter_direction_qualifier
-%type parameter_type_qualifier
%type parameter_type_specifier
%type function_definition
%type compound_statement_no_new_scope
@@ -865,29 +864,11 @@ parameter_declarator:
;
parameter_declaration:
- parameter_type_qualifier parameter_qualifier parameter_declarator
- {
- $1.flags.i |= $2.flags.i;
-
- $$ = $3;
- $$->type->qualifier = $1;
- }
- | parameter_qualifier parameter_declarator
+ parameter_qualifier parameter_declarator
{
$$ = $2;
$$->type->qualifier = $1;
}
- | parameter_type_qualifier parameter_qualifier parameter_type_specifier
- {
- void *ctx = state;
- $1.flags.i |= $2.flags.i;
-
- $$ = new(ctx) ast_parameter_declarator();
- $$->set_location(yylloc);
- $$->type = new(ctx) ast_fully_specified_type();
- $$->type->qualifier = $1;
- $$->type->specifier = $3;
- }
| parameter_qualifier parameter_type_specifier
{
void *ctx = state;
@@ -904,10 +885,22 @@ parameter_qualifier:
{
memset(& $$, 0, sizeof($$));
}
+ | CONST_TOK parameter_qualifier
+ {
+ if ($2.flags.q.constant)
+ _mesa_glsl_error(&@1, state, "duplicate const qualifier.\n");
+
+ $$ = $2;
+ $$.flags.q.constant = 1;
+ }
| parameter_direction_qualifier parameter_qualifier
{
if (($1.flags.q.in || $1.flags.q.out) && ($2.flags.q.in ||
$2.flags.q.out))
- _mesa_glsl_error(&@1, state, "duplicate in/out/inout qualifier");
+ _mesa_glsl_error(&@1, state, "duplicate in/out/inout qualifier\n");
+
+ if ($2.flags.q.constant)
+ _mesa_glsl_error(&@1, state, "const must be specified before "
+ "in/out/inout.\n");
$$ = $1;
$$.merge_qualifier(&@1, state, $2);
@@ -1316,14 +1309,6 @@ interpolation_qualifier:
}
;
-parameter_type_qualifier:
- CONST_TOK
- {
- memset(& $$, 0, sizeof($$));
- $$.flags.q.constant = 1;
- }
- ;
-
type_qualifier:
/* Single qualifiers */
INVARIANT
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/14] glsl: Disable ordering checks for const parameters with 420pack.
This makes the complier accept both "const in" and "in const". Signed-off-by: Kenneth Graunke --- src/glsl/glsl_parser.yy | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index a4ab5a4..97ed6b1 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -898,7 +898,7 @@ parameter_qualifier: if (($1.flags.q.in || $1.flags.q.out) && ($2.flags.q.in || $2.flags.q.out)) _mesa_glsl_error(&@1, state, "duplicate in/out/inout qualifier\n"); - if ($2.flags.q.constant) + if (!state->ARB_shading_language_420pack_enable && $2.flags.q.constant) _mesa_glsl_error(&@1, state, "const must be specified before " "in/out/inout.\n"); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/14] glsl: Change is_precision_statement to default_precision != none.
Currently, we store precision in ast_type_specifier, rather than
ast_type_qualifier. This works because precision is the last qualifier,
and immediately adjacent to the type.
Default precision statements (such as "precision highp float") are
represented as ast_type_specifier objects, with a boolean to indicate
that it's a default precision statement rather than an ordinary type.
ast_type_specifier::precision will be moving to ast_type_qualifier soon,
in order to support arbitrary qualifier ordering. However, we still
need to store a "this is a precision statement" flag /and/ the default
precision in ast_type_specifier.
This patch changes the boolean into a new field, default_precision.
If default_precision != ast_precision_none, it's a precision statement
with the specified precision. Otherwise, it's an ordinary type.
Signed-off-by: Kenneth Graunke
---
src/glsl/ast.h | 9 +
src/glsl/ast_to_hir.cpp | 4 ++--
src/glsl/glsl_parser.yy | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 816d5fc..1208704 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -534,7 +534,7 @@ public:
ast_expression *array_size)
: ast_node(), type_name(that->type_name), structure(that->structure),
is_array(is_array), array_size(array_size), precision(that->precision),
-is_precision_statement(that->is_precision_statement)
+default_precision(that->default_precision)
{
/* empty */
}
@@ -543,7 +543,7 @@ public:
ast_type_specifier(const char *name)
: type_name(name), structure(NULL),
is_array(false), array_size(NULL), precision(ast_precision_none),
- is_precision_statement(false)
+ default_precision(ast_precision_none)
{
/* empty */
}
@@ -552,7 +552,7 @@ public:
ast_type_specifier(ast_struct_specifier *s)
: type_name(s->name), structure(s),
is_array(false), array_size(NULL), precision(ast_precision_none),
- is_precision_statement(false)
+ default_precision(ast_precision_none)
{
/* empty */
}
@@ -573,7 +573,8 @@ public:
unsigned precision:2;
- bool is_precision_statement;
+ /** For precision statements, this is the given precision; otherwise none.
*/
+ unsigned default_precision:2;
};
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 0120313..483281d 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3958,7 +3958,7 @@ ir_rvalue *
ast_type_specifier::hir(exec_list *instructions,
struct _mesa_glsl_parse_state *state)
{
- if (!this->is_precision_statement && this->structure == NULL)
+ if (this->default_precision == ast_precision_none && this->structure ==
NULL)
return NULL;
YYLTYPE loc = this->get_location();
@@ -3984,7 +3984,7 @@ ast_type_specifier::hir(exec_list *instructions,
*field can be either int or float [...]. Any other types or
*qualifiers will result in an error.
*/
- if (this->is_precision_statement) {
+ if (this->default_precision != ast_precision_none) {
assert(this->precision != ast_precision_none);
assert(this->structure == NULL); /* The check for structures was
* performed above. */
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 97ed6b1..865b59c 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -793,7 +793,7 @@ declaration:
| PRECISION precision_qualifier type_specifier_no_prec ';'
{
$3->precision = $2;
- $3->is_precision_statement = true;
+ $3->default_precision = $2;
$$ = $3;
}
| interface_block
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/14] glsl: Move precision handling to be part of qualifier handling.
This is necessary for the parser to be able to accept precision
qualifiers not immediately adjacent to the type, such as "const highp
inout float foo".
Signed-off-by: Kenneth Graunke
---
src/glsl/ast.h | 11 ++-
src/glsl/ast_to_hir.cpp | 34 ++
src/glsl/glsl_parser.yy | 43 ---
3 files changed, 52 insertions(+), 36 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 1208704..6aede00 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -437,6 +437,9 @@ struct ast_type_qualifier {
unsigned i;
} flags;
+ /** Precision of the type (highp/medium/lowp). */
+ unsigned precision:2;
+
/**
* Location specified via GL_ARB_explicit_attrib_location layout
*
@@ -533,7 +536,7 @@ public:
ast_type_specifier(const ast_type_specifier *that, bool is_array,
ast_expression *array_size)
: ast_node(), type_name(that->type_name), structure(that->structure),
-is_array(is_array), array_size(array_size), precision(that->precision),
+is_array(is_array), array_size(array_size),
default_precision(that->default_precision)
{
/* empty */
@@ -542,7 +545,7 @@ public:
/** Construct a type specifier from a type name */
ast_type_specifier(const char *name)
: type_name(name), structure(NULL),
- is_array(false), array_size(NULL), precision(ast_precision_none),
+ is_array(false), array_size(NULL),
default_precision(ast_precision_none)
{
/* empty */
@@ -551,7 +554,7 @@ public:
/** Construct a type specifier from a structure definition */
ast_type_specifier(ast_struct_specifier *s)
: type_name(s->name), structure(s),
- is_array(false), array_size(NULL), precision(ast_precision_none),
+ is_array(false), array_size(NULL),
default_precision(ast_precision_none)
{
/* empty */
@@ -571,8 +574,6 @@ public:
bool is_array;
ast_expression *array_size;
- unsigned precision:2;
-
/** For precision statements, this is the given precision; otherwise none.
*/
unsigned default_precision:2;
};
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 483281d..dfe3b6e 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2544,6 +2544,12 @@ ast_declarator_list::hir(exec_list *instructions,
type_name);
}
}
+
+ if (this->type->qualifier.precision != ast_precision_none &&
+ this->type->specifier->structure != NULL) {
+ _mesa_glsl_error(&loc, state, "Precision qualifiers can't be applied "
+ "to structures.\n");
+ }
}
foreach_list_typed (ast_declaration, decl, link, &this->declarations) {
@@ -2846,7 +2852,7 @@ ast_declarator_list::hir(exec_list *instructions,
/* Precision qualifiers exists only in GLSL versions 1.00 and >= 1.30.
*/
- if (this->type->specifier->precision != ast_precision_none) {
+ if (this->type->qualifier.precision != ast_precision_none) {
state->check_precision_qualifiers_allowed(&loc);
}
@@ -2864,9 +2870,10 @@ ast_declarator_list::hir(exec_list *instructions,
* From page 87 of the GLSL ES spec:
*"RESOLUTION: Allow sampler types to take a precision qualifier."
*/
- if (this->type->specifier->precision != ast_precision_none
+ if (this->type->qualifier.precision != ast_precision_none
&& !var->type->is_float()
&& !var->type->is_integer()
+ && !var->type->is_record()
&& !(var->type->is_sampler() && state->es_shader)
&& !(var->type->is_array()
&& (var->type->fields.array->is_float()
@@ -3963,17 +3970,6 @@ ast_type_specifier::hir(exec_list *instructions,
YYLTYPE loc = this->get_location();
- if (this->precision != ast_precision_none
- && !state->check_precision_qualifiers_allowed(&loc)) {
- return NULL;
- }
- if (this->precision != ast_precision_none
- && this->structure != NULL) {
- _mesa_glsl_error(&loc, state,
- "precision qualifiers do not apply to structures");
- return NULL;
- }
-
/* If this is a precision statement, check that the type to which it is
* applied is either float or int.
*
@@ -3985,9 +3981,15 @@ ast_type_specifier::hir(exec_list *instructions,
*qualifiers will result in an error.
*/
if (this->default_precision != ast_precision_none) {
- assert(this->precision != ast_precision_none);
- assert(this->structure == NULL); /* The check for structures was
-* performed above. */
+ if (!state->check_precision_qualifiers_allowed(&loc))
+ return NULL;
+
+ if (this->structure != NULL) {
+ _mesa_glsl_error(&loc, state,
+ "precision qualifiers do not apply to struct
[Mesa-dev] [PATCH 12/14] glsl: Allow precision qualifiers to be flexibly ordered with 420pack.
Signed-off-by: Kenneth Graunke --- src/glsl/glsl_parser.yy | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index e2edacf..f0299fc 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -908,7 +908,7 @@ parameter_qualifier: if ($2.precision != ast_precision_none) _mesa_glsl_error(&@1, state, "Duplicate precision qualifier.\n"); - if ($2.flags.i != 0) + if (!state->ARB_shading_language_420pack_enable && $2.flags.i != 0) _mesa_glsl_error(&@1, state, "Precision qualifiers must come last.\n"); $$ = $2; @@ -1433,7 +1433,7 @@ type_qualifier: if ($2.precision != ast_precision_none) _mesa_glsl_error(&@1, state, "Duplicate precision qualifier.\n"); - if ($2.flags.i != 0) + if (!state->ARB_shading_language_420pack_enable && $2.flags.i != 0) _mesa_glsl_error(&@1, state, "Precision qualifiers must come last.\n"); $$ = $2; -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/14] glsl: Use merge_qualifier() when processing qualifier lists.
Most of ast_type_qualifier is simply a bitfield (represented as a
structure of unsigned:1 bits in a union with an unsigned). However, it
also contains ARB_explicit_attrib_location's location/index fields.
In the past, this has worked by simply returning the layout qualifier's
ast_type_qualifier and merging the other bits into it. However, that's
not obvious until you break it by switching $1 and $2.
Using merge_qualifier() copies them appropriately, and also properly
overrides layout qualifiers. It also checks for duplicate qualifiers,
which renders some of the checks in the previous patch unnecessary.
However, those checks provide better error messages, such as "Duplicate
interpolation qualifier", rather than just "duplicate qualifier".
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index c31f5e2..e8d2879 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1375,7 +1375,7 @@ type_qualifier:
}
$$ = $1;
- $$.flags.i |= $2.flags.i;
+ $$.merge_qualifier(&@1, state, $2);
}
| layout_qualifier type_qualifier
{
@@ -1398,7 +1398,7 @@ type_qualifier:
}
$$ = $1;
- $$.flags.i |= $2.flags.i;
+ $$.merge_qualifier(&@1, state, $2);
}
| storage_qualifier type_qualifier
{
@@ -1416,7 +1416,7 @@ type_qualifier:
}
$$ = $1;
- $$.flags.i |= $2.flags.i;
+ $$.merge_qualifier(&@1, state, $2);
}
;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/14] glsl: Handle centroid qualifier ordering in C code, not the parser.
The GL_ARB_shading_language_420pack extension/GLSL 4.20 split centroid
off into a new category, "auxiliary storage qualifiers," and allow these
to be placed anywhere in the series. So we have to stop recognizing
"centroid in"/"centroid out"/"centroid varying" in the grammar and get
more creative.
The same approach used before works here, too.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 50 +
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index f0299fc..e6b82b0 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -162,6 +162,7 @@ static void yyerror(YYLTYPE *loc, _mesa_glsl_parse_state
*st, const char *msg)
%type simple_statement
%type precision_qualifier
%type type_qualifier
+%type auxiliary_storage_qualifier
%type storage_qualifier
%type interpolation_qualifier
%type layout_qualifier
@@ -1325,6 +1326,7 @@ type_qualifier:
memset(& $$, 0, sizeof($$));
$$.flags.q.invariant = 1;
}
+ | auxiliary_storage_qualifier
| storage_qualifier
| interpolation_qualifier
| layout_qualifier
@@ -1338,13 +1340,13 @@ type_qualifier:
* In GLSL 4.20, these can be specified in any order. In earlier versions,
* they appear in this order (see GLSL 1.50 section 4.7 & comments below):
*
-*invariant interpolation storage precision ...or...
+*invariant interpolation auxiliary storage precision ...or...
*layout storage precision
*
* Each qualifier's rule ensures that the accumulated qualifiers on the
right
* side don't contain any that must appear on the left hand side.
* For example, when processing a storage qualifier, we check that there are
-* no interpolation, layout, or invariant qualifiers to the right.
+* no auxiliary, interpolation, layout, or invariant qualifiers to the
right.
*/
| INVARIANT type_qualifier
{
@@ -1410,6 +1412,20 @@ type_qualifier:
$$ = $1;
$$.merge_qualifier(&@1, state, $2);
}
+ | auxiliary_storage_qualifier type_qualifier
+ {
+ if ($2.has_auxiliary_storage()) {
+ _mesa_glsl_error(&@1, state,
+ "Duplicate auxiliary storage qualifier
(centroid).\n");
+ }
+
+ if ($2.flags.q.invariant || $2.has_interpolation() || $2.has_layout()) {
+ _mesa_glsl_error(&@1, state, "Auxiliary storage qualifiers must come "
+ "just before storage qualifiers.\n");
+ }
+ $$ = $1;
+ $$.flags.i |= $2.flags.i;
+ }
| storage_qualifier type_qualifier
{
/* Section 4.3 of the GLSL 1.20 specification states:
@@ -1420,9 +1436,11 @@ type_qualifier:
_mesa_glsl_error(&@1, state, "Duplicate storage qualifier.\n");
if (!state->ARB_shading_language_420pack_enable &&
- ($2.flags.q.invariant || $2.has_interpolation() || $2.has_layout()))
{
+ ($2.flags.q.invariant || $2.has_interpolation() || $2.has_layout() ||
+ $2.has_auxiliary_storage())) {
_mesa_glsl_error(&@1, state, "Storage qualifiers must come after "
- "invariant, interpolation, and layout
qualifiers.\n");
+ "invariant, interpolation, layout and auxiliary "
+ "storage qualifiers.\n");
}
$$ = $1;
@@ -1441,6 +1459,14 @@ type_qualifier:
}
;
+auxiliary_storage_qualifier:
+ CENTROID
+ {
+ memset(& $$, 0, sizeof($$));
+ $$.flags.q.centroid = 1;
+ }
+ /* TODO: "sample" and "patch" also go here someday. */
+
storage_qualifier:
CONST_TOK
{
@@ -1457,12 +1483,6 @@ storage_qualifier:
memset(& $$, 0, sizeof($$));
$$.flags.q.varying = 1;
}
- | CENTROID VARYING
- {
- memset(& $$, 0, sizeof($$));
- $$.flags.q.centroid = 1;
- $$.flags.q.varying = 1;
- }
| IN_TOK
{
memset(& $$, 0, sizeof($$));
@@ -1473,16 +1493,6 @@ storage_qualifier:
memset(& $$, 0, sizeof($$));
$$.flags.q.out = 1;
}
- | CENTROID IN_TOK
- {
- memset(& $$, 0, sizeof($$));
- $$.flags.q.centroid = 1; $$.flags.q.in = 1;
- }
- | CENTROID OUT_TOK
- {
- memset(& $$, 0, sizeof($$));
- $$.flags.q.centroid = 1; $$.flags.q.out = 1;
- }
| UNIFORM
{
memset(& $$, 0, sizeof($$));
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/14] glsl: Relax auxiliary storage ordering requirements with 420pack.
These were already semi-relaxed, since the storage qualifier rule
already skipped when 420pack was enabled.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index e6b82b0..3867cf8 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1419,7 +1419,8 @@ type_qualifier:
"Duplicate auxiliary storage qualifier
(centroid).\n");
}
- if ($2.flags.q.invariant || $2.has_interpolation() || $2.has_layout()) {
+ if (!state->ARB_shading_language_420pack_enable &&
+ ($2.flags.q.invariant || $2.has_interpolation() || $2.has_layout()))
{
_mesa_glsl_error(&@1, state, "Auxiliary storage qualifiers must come "
"just before storage qualifiers.\n");
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/8] Support of RENDER_TYPE property [1/6] Correct handling of RENDER_TYPE property.
On 07/15/2013 01:41 PM, Ian Romanick wrote: On 07/15/2013 07:28 AM, Tomasz Lis wrote: The change is to correctly handle the value of renderType in both fbconfig and context. Uses of renderType are commented, where needed, to avoid confusion between the two types. The fact that float configs can be only used for pbuffers is correctly addressed. These commit messages are not so good. The first line should be a short description of the change. The remainder should be additional information (details or supporting evidence) of the change. For this patch, I would suggest: Correctly handle the value of renderType in both fbconfig and context. Uses of renderType are commented, where needed, to avoid confusion between the two types. The fact that float configs can be only used for pbuffers is correctly addressed. Also, commit messages for the glx code should start with the "glx:" prefix, i.e. glx: Correctly handle renderType in both fbconfig and context. In general, to figure out the prefix for a particular directory, run git log on a file you edited and see what other people have picked. Patches 1-3 look reasonable to me; I didn't get a chance to look at the rest of the series, but I trust Ian's review. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [benjamin.widaw...@intel.com: intel_gpu_top broken for HSW. Ideas needed]
Ben Widawsky writes: > FWD'd from our internal list now that we have more insight. > - Forwarded message from Ben Widawsky - > > Date: Thu, 11 Jul 2013 10:32:03 -0700 > From: Ben Widawsky > To: linux-...@linux.intel.com > Subject: intel_gpu_top broken for HSW. Ideas needed > Message-ID: <20130711173202.gb8...@intel.com> > > Hi everybody. > > While investigating a hard hang on Haswell. Eero noticed that > intel_gpu_top helped to invoke the hang faster. I used this in my test > case to validation, and they are suspecting it is a known issue which we > have not yet worked around (and cannot reasonably workaround). > > [internal bug sighting redacted] > > To sum up, we cannot concurrently access registers within the same > cacheline. It has the potential to hit a known bug. > > I see some choices: > 1. Don't do anything. > 2. Try to eliminate shared registers as much as possible. Instdone is >used by the hangcheck, and we can eliminate hangcheck with a >module parameter. Eero, can you try this as a workaround, btw? Commit: 92cab7345131db7af18f630a799ce6b2e8e624c5 gets rid of instdone on hangcheck. -Mika > 3. Somehow make the kernel collect the top data and serialize access >there. > > Anyone else have input? I personally do not use top very much, so I > won't be volunteering to do any of these. > > - End forwarded message - > > -- > Ben Widawsky, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/8] Support of RENDER_TYPE property [3/6] Changes to visual configs initialization.
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
The change is to correctly handle the value of renderType and
drawableType in fbconfig. This part modifies glXInitializeVisualConfigFromTags
to read the parameter value, or detect it if it's not there.
---
src/glx/glxext.c | 35 +++
src/mesa/drivers/x11/fakeglx.c |7 ++-
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index ef1e7ad..83580d4 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -337,6 +337,7 @@ __glXInitializeVisualConfigFromTags(struct glx_config *
config, int count,
Bool fbconfig_style_tags)
{
int i;
+ GLint renderType = 0;
if (!tagged_only) {
/* Copy in the first set of properties */
@@ -471,8 +472,8 @@ __glXInitializeVisualConfigFromTags(struct glx_config *
config, int count,
config->drawableType |= GLX_WINDOW_BIT | GLX_PIXMAP_BIT |
GLX_PBUFFER_BIT;
#endif
break;
- case GLX_RENDER_TYPE:
- config->renderType = *bp++;
+ case GLX_RENDER_TYPE: /* fbconfig render type bits */
+ renderType = *bp++;
break;
case GLX_X_RENDERABLE:
config->xRenderable = *bp++;
@@ -555,8 +556,34 @@ __glXInitializeVisualConfigFromTags(struct glx_config *
config, int count,
}
}
- config->renderType =
- (config->rgbMode) ? GLX_RGBA_BIT : GLX_COLOR_INDEX_BIT;
+ if (renderType) {
+ config->renderType = renderType;
+ config->floatMode = (renderType &
+ (GLX_RGBA_FLOAT_BIT_ARB|GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT)) ?
+ GL_TRUE : GL_FALSE;
This should be (ignoring the horrible line-wrapping that Thunderbird
forces on me):
config->floatMode = (renderType &
(GLX_RGBA_FLOAT_BIT_ARB|GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT)) != 0;
+ } else if (!tagged_only) {
+ /* If there wasn't GLX_RENDER_TYPE property, set it based on
config->*Mode
+* It is not always explicit, but we have no other choice. We will not
know
+* if the float mode should be signed or unsigned, and we won't know if
+* the mode supports both integer and float RGBA. */
+ config->renderType =
+ ((config->floatMode==GL_TRUE) ? GLX_RGBA_FLOAT_BIT_ARB : 0) |
+ ((config->rgbMode==GL_TRUE && config->floatMode!=GL_TRUE) ?
GLX_RGBA_BIT : 0) |
+ ((config->rgbMode!=GL_TRUE) ? GLX_COLOR_INDEX_BIT : 0);
Ugh. Don't compare with logic values either.
config->renderType =
(config->floatMode ? GLX_RGBA_FLOAT_BIT_ARB : 0) |
((config->rgbMode && !config->floatMode) ? GLX_RGBA_BIT : 0) |
(!config->rgbMode ? GLX_COLOR_INDEX_BIT : 0);
Since these are all mutually exclusive values, this would probably be
better as a series of if-else statements anyway. I think the following
is much more clear:
if (config->floatMode) {
config->renderType = GLX_RGBA_FLOAT_BIT_ARB;
} else if (config->rgbMode) {
config->renderType = GLX_RGBA_BIT;
} else {
config->renderType = GLX_COLOR_INDEX_BIT;
}
+ } else {
+ /* If there wasn't such property and we should return fbconfig with
only part of
+* properties set, then don't change (allow zero) renderType. This will
allow matching
+* the generated fbconfig with fbconfigs_compatible(), no matter which
flags are set
+* in the fbconfig being compared. */
I think clang (or maybe some static analysis tools) may generate a
warning for an empty block like this. Can someone else confirm that for me?
+ }
+ /* cannot create window out of float fbconfigs, these are offscreen only */
+ if (config->floatMode == GL_TRUE) {
+ /* GLX_ARB_fbconfig_float specs:
+* Note that floating point rendering is only supported for
+* GLXPbuffer drawables.
+*/
+ config->drawableType &= ~(GLX_WINDOW_BIT|GLX_PIXMAP_BIT);
+ }
}
static struct glx_config *
diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c
index 969ee7d..7a2cfbe 100644
--- a/src/mesa/drivers/x11/fakeglx.c
+++ b/src/mesa/drivers/x11/fakeglx.c
I'm not sure these last two hunks are necessary. I don't think the
fakeglx patch can ever see float configs. Brian knows that code much
better than I do.
@@ -1090,6 +1090,9 @@ choose_visual( Display *dpy, int screen, const int *list,
GLboolean fbConfig )
else if (*parselist & GLX_COLOR_INDEX_BIT) {
rgb_flag = GL_FALSE;
}
+else if (*parselist &
(GLX_RGBA_FLOAT_BIT_ARB|GLX_RGBA_UNSIGNED_FLOAT_BIT_EXT)) {
+ rgb_flag = GL_TRUE;
+}
else if (*parselist == 0) {
rgb_flag = GL_TRUE;
}
@@ -1761,7 +1764,9 @@ get_config( XMesaVisual xmvis, int attrib, int *value,
GLboolean fbconfig )
case GLX_RENDER_TYPE_SGIX:
if (!fbconfig)
Re: [Mesa-dev] [PATCH 6/8] Support of RENDER_TYPE property [6/6] Verification of the RENDER_TYPE value.
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
The change is to correctly handle the value of renderType in GLX context.
In case of the value being incorrect, context creation fails.
---
src/glx/dri2_glx.c | 11 +++
src/glx/dri_glx.c |6 ++
src/glx/drisw_glx.c| 12
src/glx/glxclient.h|2 ++
src/glx/glxcmds.c | 25 +
src/glx/indirect_glx.c |6 ++
src/mesa/drivers/x11/fakeglx.c |5 -
7 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index d60c675..539e7f1 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -205,6 +205,12 @@ dri2_create_context(struct glx_screen *base,
__GLXDRIconfigPrivate *config = (__GLXDRIconfigPrivate *) config_base;
__DRIcontext *shared = NULL;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType) {
+ return NULL;
+ }
+
Every place that uses verifyConextRenderTypeGLX should be:
if (!verifyContextRenderTypeGLX(config_base, renderType))
return NULL;
And see blow.
if (shareList) {
/* If the shareList context is not a DRI2 context, we cannot possibly
* create a DRI2 context that shares it.
@@ -277,6 +283,11 @@ dri2_create_context_attribs(struct glx_screen *base,
error))
goto error_exit;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType)
+ goto error_exit;
+
if (shareList) {
pcp_shared = (struct dri2_context *) shareList;
shared = pcp_shared->driContext;
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index cc45734..de44451 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -581,6 +581,12 @@ dri_create_context(struct glx_screen *base,
if (!psc->base.driScreen)
return NULL;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType) {
+ return NULL;
+ }
+
if (shareList) {
/* If the shareList context is not a DRI context, we cannot possibly
* create a DRI context that shares it.
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index ef0e52b..0e45607 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -380,6 +380,12 @@ drisw_create_context(struct glx_screen *base,
if (!psc->base.driScreen)
return NULL;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType) {
+ return NULL;
+ }
+
if (shareList) {
/* If the shareList context is not a DRISW context, we cannot possibly
* create a DRISW context that shares it.
@@ -451,6 +457,12 @@ drisw_create_context_attribs(struct glx_screen *base,
error))
return NULL;
+ /* Check the renderType value */
+ renderType = verifyContextRenderTypeGLX(config_base, renderType);
+ if (!renderType) {
+ return NULL;
+ }
+
if (reset != __DRI_CTX_RESET_NO_NOTIFICATION)
return NULL;
diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index fc8f31c..0e78584 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -803,6 +803,8 @@ extern int
applegl_create_display(struct glx_display *display);
#endif
+extern int verifyContextRenderTypeGLX(const struct glx_config *config, int
renderType);
+
extern struct glx_drawable *GetGLXDrawable(Display *dpy, GLXDrawable
drawable);
extern int InitGLXDrawable(Display *dpy, struct glx_drawable *glxDraw,
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 99b0218..e5ae7f8 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -224,6 +224,31 @@ ValidateGLXFBConfig(Display * dpy, GLXFBConfig fbconfig)
return NULL;
}
+/**
+ * Verifies context's GLX_RENDER_TYPE value with config.
+ * \param config GLX FBConfig which will support the returned renderType.
+ * \param renderType The context render type to be verified.
+ * \return Gives the approved value of context renderType, or 0 if no valid
value was found.
+ */
The users of this function only care that it returns 0 or non-0. Have
it return type Bool instead.
I also think this function could use a better name.
validate_renderType_against_config seems more descriptive.
+int
+verifyContextRenderTypeGLX(const struct glx_config *config, int renderType)
+{
+switch (renderType)
+{
Opening curly brace should be on the same line with the switch.
+case GLX_RGBA_TYPE:
+return (config->renderType & GLX_RGBA_BIT) ? GLX_RGBA_TYPE : 0;
return (config->renderType & GLX_RGBA_BIT) != 0;
etc.
+case GLX_COLOR_INDEX_TYPE:
+return (config->renderType & GLX_COLOR_INDEX_BIT) ?
GLX_COLOR_INDEX_TYPE : 0;
+case GLX_RGB
Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes
Carl Worth writes:
> Thanks. I'm happy to help here. So I'll plan to release 9.1.5 on July
> 15, (just 1.5 weeks away now).
Well, I was hoping to have my first release be on time, but I didn't
quite make it.
I have assembled a candidate branch for release, and I've pushed it to
the "9.1" branch in the mesa repository. In my limited testing, (a
piglit run on one architecture---my Intel Sandybridge laptop), I've
found no regressions.
I plan to perform a stable release with this code in two days
(2013-07-17) unless anyone objects. So please review the commits in this
branch, test it out, and let me know if you see any problems.
-Carl
Here are the commits on the "9.1" branch since the 9.1.4 release:
commit e292c4656af6a8b3cd6bfc584cf09b2d0cee9917
Author: Paul Berry
glsl ES: Fix magnitude of gl_MaxVertexUniformVectors.
commit 8bb40f7b2bf03bef0b98c00663e0871699c6dcf9
Author: Carl Worth
cherry-ignore: Drop two patches which we've decided not to include
commit 083f5f08485845246356b15059d84ca2813a4221
Author: Carl Worth
cherry-ignore: Ignore previously backported patch
commit f4cf23e35081205f25e78f90437ead15cbec7792
Author: Christoph Bumiller
r600g: x/y coordinates must be divided by block dim in dma blit
commit 6a2df5a0302c0ae5ad86e3164d1227fc079d7110
Author: Chris Forbes
i965: fix alpha test for MRT
commit 330203c267761590d22e75710677b6f0b9cfbd09
Author: Kenneth Graunke
glsl/builtins: Fix ARB_texture_cube_map_array built-in availability.
commit cc01cfe073f865c16a0ed2333f1f76bde5a8a94a
Author: Anuj Phogat
mesa: Return ZeroVec/dummyReg instead of NULL pointer
commit e8af0576a5cf3cb0bf49d02449042489291c5b2c
Author: Ian Romanick
glsl: Move all var decls to the front of the IR list in reverse order
commit ba1d24f06ad4cfc3c984cad8bd278bf297d1ed6a
Author: Ian Romanick
i965: Be more careful with the interleaved user array upload optimization
commit d3ab091433393a2823a68bc97ff7437e8b64d7ef
Author: Eric Anholt
ra: Fix register spilling.
commit ff4f5c340f15bb68287f62dbc5b5245dac3acc43
Author: Matt Turner
register_allocate: Fix the type of best_benefit.
commit 26f802d0635fc247bbc3ebf6f7e9bf126b6b5e69
Author: Brian Paul
svga: check for NaN shader immediates
commit cda92f5191cd2ed4782dbdd41143d520857861c9
Author: Richard Sandiford
st/dri/sw: Fix pitch calculation in drisw_update_tex_buffer
commit 5412ae63dca1b1a6c43fccb5bafe56a0cd9c9a88
Author: Kristian Høgsberg
wayland: Handle global_remove event as well
commit 8ed60f7f7fb060ccf939328bb03c9714b207236f
Author: Richard Sandiford
st/xlib: Fix XImage stride calculation
commit 2cfc0072a80cfd9503be7e57a1d8375d64d7eb98
Author: Richard Sandiford
st/xlib Fix XIMage bytes-per-pixel calculation
commit 307a703c759263bb37285b0919721ff2c413fc56
Author: Ian Romanick
glsl: Generate smaller values for uniform locations
commit 4d12a9c67c850ff2c92f301317bc3fae0bcb448a
Author: Ian Romanick
glsl: Add gl_shader_program::UniformLocationBaseScale
commit ab159327a7dc2dd41f9887d053d4abb3de69d195
Author: Ian Romanick
glsl: Add a gl_shader_program parameter to
_mesa_uniform_{merge,split}_location_offset
commit e94a89de4deeabd0f8347795385b2f098aa35365
Author: Vinson Lee
swrast: Fix memory leak.
commit 6194644a49f841488e23ce021e7817ec02927eef
Author: Ian Romanick
docs: Add 9.1.4 release md5sums
pgpxdICKILHRX.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl: Silence the last shift/reduce conflict warning in the grammar.
For the series: Reviewed-by: Chris Forbes ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
