[Mesa-dev] [RFC] [PATCH 0/4] New coordinate normalization patches with bind flags
This is a new approach to the coordinate normalization issue. I only compile tested this, and posted it to find out if I'm on the right track, and will do more testing if so. On the state tracker -> driver front, I no longer have any resource flags and instead split PIPE_BIND_SAMPLER_VIEW into 4 separate flags. Those are: PIPE_BIND_SAMPLER_VIEW_ANY: asks for a normalization of the driver's choice PIPE_BIND_SAMPLER_VIEW_NORMALIZED: asks for normalized, any wrap mode PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP: asks for unnormalized, clamp mode PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_NON_CLAMP: asks for unnormalized, non-clamp And PIPE_BIND_SAMPLER_VIEW_ALL which is an OR of them all. All of these imply PIPE_BIND_SAMPLER_VIEW_ANY. I think this is the conceptually cleanest approach, even though it requires to modify all instances of PIPE_BIND_SAMPLER_VIEW (hence the long diffstat). On the driver -> state tracker front, I split the flag into two flags. This allows the driver to either express no preference, or express any of the two preferences. I haven't (yet?) replaced them with a query, since Keith hasn't elaborated on his idea yet, and I don't like all the ways of adding a query I can think of myself very much (less CPU-efficient, more driver code, no apparent gain). What do you think? Is this the right thing? Luca Barbieri (4): gallium: add resource normalization flags (v3) gallium: only use PIPE_BIND_SAMPLER_VIEW_* flags actually needed gallium: use unnormalized coords internally if the driver asks for them (v5) st/mesa: use PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP for GL_TEXTURE_RECTANGLE (v2) src/gallium/auxiliary/draw/draw_pipe_aaline.c |2 +- src/gallium/auxiliary/draw/draw_pipe_pstipple.c|2 +- src/gallium/auxiliary/util/u_blit.c| 59 +++ src/gallium/auxiliary/util/u_blitter.c | 50 - src/gallium/auxiliary/util/u_caps.c|2 +- src/gallium/auxiliary/util/u_debug.c |3 +- src/gallium/drivers/nouveau/nouveau_screen.c |2 +- src/gallium/drivers/nv50/nv50_screen.c |2 +- src/gallium/drivers/nvfx/nvfx_miptree.c|2 +- src/gallium/drivers/nvfx/nvfx_screen.c |2 +- src/gallium/drivers/r300/r300_blit.c |2 +- src/gallium/drivers/r300/r300_context.c|2 +- src/gallium/drivers/r300/r300_screen.c |4 +- src/gallium/drivers/r300/r300_transfer.c |4 +- src/gallium/drivers/r600/r600_buffer.c |2 +- src/gallium/drivers/r600/r600_screen.c |4 +- src/gallium/drivers/svga/svga_pipe_blit.c |2 +- src/gallium/drivers/svga/svga_resource_texture.c |2 +- src/gallium/drivers/svga/svga_screen.c |2 +- src/gallium/include/pipe/p_defines.h | 77 ++-- .../state_trackers/dri/common/dri_drawable.c |2 +- src/gallium/state_trackers/dri/drm/dri2.c |2 +- src/gallium/state_trackers/egl/gdi/native_gdi.c|2 +- src/gallium/state_trackers/egl/kms/native_kms.c|2 +- src/gallium/state_trackers/egl/x11/native_ximage.c |2 +- src/gallium/state_trackers/python/st_device.c |2 +- src/gallium/state_trackers/vega/api_filters.c |2 +- src/gallium/state_trackers/vega/image.c|4 +- src/gallium/state_trackers/vega/mask.c |2 +- src/gallium/state_trackers/vega/paint.c|2 +- src/gallium/state_trackers/vega/renderer.c |6 +- src/gallium/state_trackers/vega/vg_manager.c |2 +- src/gallium/state_trackers/xorg/xorg_exa.c |6 +- src/gallium/state_trackers/xorg/xorg_renderer.c|4 +- src/gallium/state_trackers/xorg/xorg_xv.c |2 +- src/gallium/tests/graw/fs-test.c |2 +- src/gallium/tests/graw/gs-test.c |2 +- src/gallium/tests/graw/quad-tex.c |2 +- src/gallium/tests/graw/vs-test.c |2 +- src/gallium/tests/python/tests/surface_copy.py |5 +- src/gallium/tests/python/tests/texture_blit.py |6 +- src/gallium/tests/python/tests/texture_render.py |4 +- src/gallium/tests/python/tests/texture_transfer.py |2 +- src/gallium/winsys/radeon/drm/radeon_r300.c|2 +- src/mesa/state_tracker/st_atom_pixeltransfer.c |4 +- src/mesa/state_tracker/st_cb_bitmap.c | 31 +--- src/mesa/state_tracker/st_cb_drawpixels.c | 38 ++ src/mesa/state_tracker/st_cb_eglimage.c|2 +- src/mesa/state_tracker/st_cb_texture.c | 26 --- src/mesa/state_tracker/st_context.h|2 +- src/mesa/state_tracker/st_extensions.c | 14 ++-- src/mesa/state_tracker/st_format.c | 21 -- src/mesa/state_tracker/st_texture.c|2 +-
[Mesa-dev] [PATCH 1/4] gallium: add resource normalization flags (v3)
Changes in v3:
- Rework to use multiple flags
Changes in v2:
- Add a much longer and better comment
This allows:
1. The state tracker to tell the driver which normalizations it needs
2. The driver to tell the state tracker which normalization it prefers
---
src/gallium/include/pipe/p_defines.h | 80 ++---
1 files changed, 72 insertions(+), 8 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 00aa207..1acb54e 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -281,14 +281,51 @@ enum pipe_transfer_usage {
*/
#define PIPE_BIND_DEPTH_STENCIL(1 << 0) /* get_tex_surface */
#define PIPE_BIND_RENDER_TARGET(1 << 1) /* get_tex_surface */
-#define PIPE_BIND_SAMPLER_VIEW (1 << 2) /* get_sampler_view */
-#define PIPE_BIND_VERTEX_BUFFER(1 << 3) /* set_vertex_buffers */
-#define PIPE_BIND_INDEX_BUFFER (1 << 4) /* draw_elements */
-#define PIPE_BIND_CONSTANT_BUFFER (1 << 5) /* set_constant_buffer */
-#define PIPE_BIND_DISPLAY_TARGET (1 << 8) /* flush_front_buffer */
-#define PIPE_BIND_TRANSFER_WRITE (1 << 9) /* get_transfer */
-#define PIPE_BIND_TRANSFER_READ(1 << 10) /* get_transfer */
-#define PIPE_BIND_STREAM_OUTPUT(1 << 11) /* set_stream_output_buffers
*/
+
+/* Sampler views can be created based on this texture. Only the
+ * normalization preferred by the driver can be used, unless the other
+ * flags below are set as well. Only clamp wrap modes are allowed. */
+#define PIPE_BIND_SAMPLER_VIEW_ANY (1 << 2) /* get_sampler_view */
+
+/* State trackers must set this flag if they/the user API need to be able to
use
+ * unnormalized coodinates with clamp, clamp-to-edge or clamp-to-border wrap
+ * mode with this resource when a sampler view based on it is bound.
+ *
+ * OpenCL and OpenGL TEXTURE_RECTANGLE textures will have this flag set.
+ */
+#define PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP ((1 << 2) | (1 << 3))
+
+/* State trackers must set this flag if they/the user API need to be able to
use
+ * unnormalized coordinates with non-clamp wrap modes with this resource
+ * when a sampler view based on it is bound.
+ *
+ * OpenCL textures will have this flag set.
+ */
+#define PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_NON_CLAMP ((1 << 2) | (1 << 4))
+
+/* State trackers must set this flag if they/the user API need to be able to
use
+ * normalized coordinates with any wrap mode with this resource
+ * when a sampler view based on it is bound.
+ *
+ * OpenCL, OpenGL TEXTURE_2D and D3D11 textures will have this flag set.
+ */
+#define PIPE_BIND_SAMPLER_VIEW_NORMALIZED ((1 << 2) | (1 << 5))
+
+#define PIPE_BIND_SAMPLER_VIEW_ALL \
+ (PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP \
+ | PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_NON_CLAMP \
+| PIPE_BIND_SAMPLER_VIEW_NORMALIZED)
+
+/* XXX: this will be removed in the next patch */
+#define PIPE_BIND_SAMPLER_VIEW PIPE_BIND_SAMPLER_VIEW_ALL
+
+#define PIPE_BIND_VERTEX_BUFFER(1 << 6) /* set_vertex_buffers */
+#define PIPE_BIND_INDEX_BUFFER (1 << 7) /* draw_elements */
+#define PIPE_BIND_CONSTANT_BUFFER (1 << 8) /* set_constant_buffer */
+#define PIPE_BIND_DISPLAY_TARGET (1 << 9) /* flush_front_buffer */
+#define PIPE_BIND_TRANSFER_WRITE (1 << 10) /* get_transfer */
+#define PIPE_BIND_TRANSFER_READ(1 << 11) /* get_transfer */
+#define PIPE_BIND_STREAM_OUTPUT(1 << 12) /* set_stream_output_buffers
*/
#define PIPE_BIND_CUSTOM (1 << 16) /* state-tracker/winsys
usages */
/* The first two flags above were previously part of the amorphous
@@ -313,6 +350,27 @@ enum pipe_transfer_usage {
/* Flags for the driver about resource behaviour:
*/
#define PIPE_RESOURCE_FLAG_GEN_MIPS(1 << 0) /* Driver performs autogen
mips */
+
+/* State trackers should support using either normalization in all internal
drawing
+ * code, using these flag to tell which one to use.
+ *
+ * If they do not have such support, then they should indicate the
+ * normalization needed using the bind flags, but they should be aware
+ * that if it is different than the API-needed one, some drivers may
+ * fail creation because they only support one normalization at once.
+ *
+ * State trackers must not set these flags.
+ *
+ * Drivers should set these flags to inform the state tracker of the
normalization
+ * it should use in internal drawing code, if they prefer any.
+ *
+ * Drivers who need to always have the same normalization used for a given
+ * resource must set these flags according to the bind flags above, and refuse
+ * creation if too many normalization bind flags are set.
+ */
+#define PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS (1 << 1)
+#define PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS (1 << 2)
+
#define PIPE_RESOURCE_FLAG_DRV_PRIV(1 << 16) /* driver/winsys private */
#define PIPE_RESOUR
[Mesa-dev] [PATCH 3/4] gallium: use unnormalized coords internally if the driver asks for them (v5)
Changes in v5:
- Use the new flags
Changes in v4:
- Modify st_Bitmap to use unnormalized coordinates if the driver wants it to
Changes in v3:
- Updated comment
Changes in v2:
- u_blit no longer sets the unnormalized hint flag for NPOT textures:
the driver should do that if it wants to
Currently Gallium internals always use normalized coordinates to
access textures.
However, for NPOT textures on hardware without ARB_texture_non_power_of_two
support (e.g. nv30) this can trigger a software fallback or even not be
supported at all.
Hence, this change adds support for both kinds of normalization, depending
on what the driver asks.
---
src/gallium/auxiliary/util/u_blit.c | 59 +
src/gallium/auxiliary/util/u_blitter.c| 48 +++
src/mesa/state_tracker/st_cb_bitmap.c | 21 +++---
src/mesa/state_tracker/st_cb_drawpixels.c | 38 +++---
src/mesa/state_tracker/st_context.h |2 +-
5 files changed, 96 insertions(+), 72 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blit.c
b/src/gallium/auxiliary/util/u_blit.c
index a86806c..47d0174 100644
--- a/src/gallium/auxiliary/util/u_blit.c
+++ b/src/gallium/auxiliary/util/u_blit.c
@@ -110,7 +110,6 @@ util_create_blit(struct pipe_context *pipe, struct
cso_context *cso)
ctx->sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NONE;
ctx->sampler.min_img_filter = 0; /* set later */
ctx->sampler.mag_img_filter = 0; /* set later */
- ctx->sampler.normalized_coords = 1;
/* vertex elements state */
memset(&ctx->velem[0], 0, sizeof(ctx->velem[0]) * 2);
@@ -296,6 +295,7 @@ util_blit_pixels_writemask(struct blit_state *ctx,
unsigned offset;
boolean overlap;
float s0, t0, s1, t1;
+ boolean normalized;
assert(filter == PIPE_TEX_MIPFILTER_NEAREST ||
filter == PIPE_TEX_MIPFILTER_LINEAR);
@@ -335,7 +335,6 @@ util_blit_pixels_writemask(struct blit_state *ctx,
return;
}
-
/* Create a temporary texture when src and dest alias or when src
* is anything other than a 2d texture.
* XXX should just use appropriate shader to access 1d / 3d slice / cube
face,
@@ -378,7 +377,7 @@ util_blit_pixels_writemask(struct blit_state *ctx,
texTemp.width0 = srcW;
texTemp.height0 = srcH;
texTemp.depth0 = 1;
- texTemp.bind = PIPE_BIND_SAMPLER_VIEW_NORMALIZED;
+ texTemp.bind = PIPE_BIND_SAMPLER_VIEW_ANY;
tex = screen->resource_create(screen, &texTemp);
if (!tex)
@@ -392,10 +391,19 @@ util_blit_pixels_writemask(struct blit_state *ctx,
src_tex, srcsub, srcLeft, srcTop, srcZ0, /*
src */
srcW, srcH); /* size */
- s0 = 0.0f;
- s1 = 1.0f;
- t0 = 0.0f;
- t1 = 1.0f;
+ normalized = !(tex->flags &
PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS);
+ if(normalized) {
+ s0 = 0.0f;
+ s1 = 1.0f;
+ t0 = 0.0f;
+ t1 = 1.0f;
+ }
+ else {
+ s0 = 0;
+ s1 = srcW;
+ t0 = 0;
+ t1 = srcH;
+ }
u_sampler_view_default_template(&sv_templ, tex, tex->format);
sampler_view = pipe->create_sampler_view(pipe, tex, &sv_templ);
@@ -415,16 +423,24 @@ util_blit_pixels_writemask(struct blit_state *ctx,
return;
}
- s0 = srcX0 / (float)(u_minify(sampler_view->texture->width0,
srcsub.level));
- s1 = srcX1 / (float)(u_minify(sampler_view->texture->width0,
srcsub.level));
- t0 = srcY0 / (float)(u_minify(sampler_view->texture->height0,
srcsub.level));
- t1 = srcY1 / (float)(u_minify(sampler_view->texture->height0,
srcsub.level));
+ s0 = srcX0;
+ s1 = srcX1;
+ t0 = srcY0;
+ t1 = srcY1;
+ normalized = !!(sampler_view->texture->flags &
PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS);
+ if(normalized)
+ {
+ s0 /= (float)(u_minify(sampler_view->texture->width0, srcsub.level));
+ s1 /= (float)(u_minify(sampler_view->texture->width0, srcsub.level));
+ t0 /= (float)(u_minify(sampler_view->texture->height0, srcsub.level));
+ t1 /= (float)(u_minify(sampler_view->texture->height0, srcsub.level));
+ }
}
assert(screen->is_format_supported(screen, sampler_view->format,
PIPE_TEXTURE_2D,
sampler_view->texture->nr_samples,
- PIPE_BIND_SAMPLER_VIEW_NORMALIZED, 0));
+ PIPE_BIND_SAMPLER_VIEW_ANY, 0));
assert(screen->is_format_supported(screen, dst->format, PIPE_TEXTURE_2D,
dst->texture->nr_samples,
PIPE_BIND_RENDER_TARGET, 0));
@@ -450,6 +466,7 @@ util_blit_pixels_writemask(struct blit_state *ctx,
cso_set_vertex_elements(ctx->cso, 2, ctx->velem);
/* sampler */
+ ctx->sampler.normalized_coords = normalized;
ctx->sampler.min_img
[Mesa-dev] [PATCH 4/4] st/mesa: use PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP for GL_TEXTURE_RECTANGLE (v2)
Changes in v3:
- Rework to use the bind flags
Changes in v2:
- No longer set the flag in compress_with_blit depending on NPOT, let the
driver do that if needed
Allow to pass flags to st_texture_create and take advantage of that
to tell the pipe driver that a texture is going to be used with unnormalized
coordinates.
This is useful for hardware with no mipmapped NPOT support that needs to
allocate texture rectangles in a special way (e.g. nv30).
---
src/mesa/state_tracker/st_cb_texture.c | 22 ++
src/mesa/state_tracker/st_format.c | 15 ++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index bc0af17..aa20131 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -209,22 +209,28 @@ do_memcpy(void *dest, const void *src, size_t n)
* Return default texture resource binding bitmask for the given format.
*/
static GLuint
-default_bindings(struct st_context *st, enum pipe_format format)
+default_bindings(struct st_context *st, GLenum target, enum pipe_format format)
{
struct pipe_screen *screen = st->pipe->screen;
- const unsigned target = PIPE_TEXTURE_2D;
const unsigned geom = 0x0;
unsigned bindings;
+ unsigned sampler_view_binding;
if (util_format_is_depth_or_stencil(format))
- bindings = PIPE_BIND_SAMPLER_VIEW_ALL | PIPE_BIND_DEPTH_STENCIL;
+ bindings = PIPE_BIND_DEPTH_STENCIL;
else
- bindings = PIPE_BIND_SAMPLER_VIEW_ALL | PIPE_BIND_RENDER_TARGET;
+ bindings = PIPE_BIND_RENDER_TARGET;
- if (screen->is_format_supported(screen, format, target, 0, bindings, geom))
+ if(target == GL_TEXTURE_RECTANGLE)
+ sampler_view_binding = PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP;
+ else
+ sampler_view_binding = PIPE_BIND_SAMPLER_VIEW_NORMALIZED;
+ bindings |= sampler_view_binding;
+
+ if (screen->is_format_supported(screen, format, PIPE_TEXTURE_2D, 0,
bindings, geom))
return bindings;
else
- return PIPE_BIND_SAMPLER_VIEW_ALL;
+ return sampler_view_binding;
}
@@ -341,7 +347,7 @@ guess_and_alloc_texture(struct st_context *st,
fmt = st_mesa_format_to_pipe_format(stImage->base.TexFormat);
- bindings = default_bindings(st, fmt);
+ bindings = default_bindings(st, stObj->base.Target, fmt);
stObj->pt = st_texture_create(st,
gl_target_to_pipe(stObj->base.Target),
@@ -1866,7 +1872,7 @@ st_finalize_texture(GLcontext *ctx,
/* May need to create a new gallium texture:
*/
if (!stObj->pt) {
- GLuint bindings = default_bindings(st, firstImageFormat);
+ GLuint bindings = default_bindings(st, stObj->base.Target,
firstImageFormat);
stObj->pt = st_texture_create(st,
gl_target_to_pipe(stObj->base.Target),
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index e2ba006..ed53439 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -717,19 +717,24 @@ st_ChooseTextureFormat(GLcontext *ctx, GLint
internalFormat,
{
struct pipe_screen *screen = st_context(ctx)->pipe->screen;
enum pipe_format pFormat;
- uint bindings;
+ uint bindings, sampler_view_binding;
(void) format;
- (void) type;
/* GL textures may wind up being render targets, but we don't know
* that in advance. Specify potential render target flags now.
*/
if (_mesa_is_depth_format(internalFormat) ||
_mesa_is_depthstencil_format(internalFormat))
- bindings = PIPE_BIND_SAMPLER_VIEW_ALL | PIPE_BIND_DEPTH_STENCIL;
+ bindings = PIPE_BIND_DEPTH_STENCIL;
else
- bindings = PIPE_BIND_SAMPLER_VIEW_ALL | PIPE_BIND_RENDER_TARGET;
+ bindings = PIPE_BIND_RENDER_TARGET;
+
+ if(type == GL_TEXTURE_RECTANGLE)
+ sampler_view_binding = PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP;
+ else
+ sampler_view_binding = PIPE_BIND_SAMPLER_VIEW_NORMALIZED;
+ bindings |= sampler_view_binding;
pFormat = st_choose_format(screen, internalFormat,
PIPE_TEXTURE_2D, 0, bindings);
@@ -737,7 +742,7 @@ st_ChooseTextureFormat(GLcontext *ctx, GLint internalFormat,
if (pFormat == PIPE_FORMAT_NONE) {
/* try choosing format again, this time without render target bindings */
pFormat = st_choose_format(screen, internalFormat,
- PIPE_TEXTURE_2D, 0,
PIPE_BIND_SAMPLER_VIEW_ALL);
+ PIPE_TEXTURE_2D, 0, sampler_view_binding);
}
if (pFormat == PIPE_FORMAT_NONE) {
--
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] gallium: only use PIPE_BIND_SAMPLER_VIEW_* flags actually needed
This changes the whole codebase to specify precisely which sampling capabilities they actually need. It also removes PIPE_BIND_SAMPLER_VIEW since all users are moved to either more specific flags, or PIPE_BIND_SAMPLER_VIEW_ALL. This prevents accidentally specifying PIPE_SAMPLER_VIEW incorrectly. --- src/gallium/auxiliary/draw/draw_pipe_aaline.c |2 +- src/gallium/auxiliary/draw/draw_pipe_pstipple.c|2 +- src/gallium/auxiliary/util/u_blit.c|4 ++-- src/gallium/auxiliary/util/u_blitter.c |2 +- src/gallium/auxiliary/util/u_caps.c|2 +- src/gallium/auxiliary/util/u_debug.c |3 +-- src/gallium/drivers/nouveau/nouveau_screen.c |2 +- src/gallium/drivers/nv50/nv50_screen.c |2 +- src/gallium/drivers/nvfx/nvfx_miptree.c|2 +- src/gallium/drivers/nvfx/nvfx_screen.c |2 +- src/gallium/drivers/r300/r300_blit.c |2 +- src/gallium/drivers/r300/r300_context.c|2 +- src/gallium/drivers/r300/r300_screen.c |4 ++-- src/gallium/drivers/r300/r300_transfer.c |4 ++-- src/gallium/drivers/r600/r600_buffer.c |2 +- src/gallium/drivers/r600/r600_screen.c |4 ++-- src/gallium/drivers/svga/svga_pipe_blit.c |2 +- src/gallium/drivers/svga/svga_resource_texture.c |2 +- src/gallium/drivers/svga/svga_screen.c |2 +- src/gallium/include/pipe/p_defines.h |3 --- .../state_trackers/dri/common/dri_drawable.c |2 +- src/gallium/state_trackers/dri/drm/dri2.c |2 +- src/gallium/state_trackers/egl/gdi/native_gdi.c|2 +- src/gallium/state_trackers/egl/kms/native_kms.c|2 +- src/gallium/state_trackers/egl/x11/native_ximage.c |2 +- src/gallium/state_trackers/python/st_device.c |2 +- src/gallium/state_trackers/vega/api_filters.c |2 +- src/gallium/state_trackers/vega/image.c|4 ++-- src/gallium/state_trackers/vega/mask.c |2 +- src/gallium/state_trackers/vega/paint.c|2 +- src/gallium/state_trackers/vega/renderer.c |6 +++--- src/gallium/state_trackers/vega/vg_manager.c |2 +- src/gallium/state_trackers/xorg/xorg_exa.c |6 +++--- src/gallium/state_trackers/xorg/xorg_renderer.c|4 ++-- src/gallium/state_trackers/xorg/xorg_xv.c |2 +- src/gallium/tests/graw/fs-test.c |2 +- src/gallium/tests/graw/gs-test.c |2 +- src/gallium/tests/graw/quad-tex.c |2 +- src/gallium/tests/graw/vs-test.c |2 +- src/gallium/tests/python/tests/surface_copy.py |5 +++-- src/gallium/tests/python/tests/texture_blit.py |6 +++--- src/gallium/tests/python/tests/texture_render.py |4 ++-- src/gallium/tests/python/tests/texture_transfer.py |2 +- src/gallium/winsys/radeon/drm/radeon_r300.c|2 +- src/mesa/state_tracker/st_atom_pixeltransfer.c |4 ++-- src/mesa/state_tracker/st_cb_bitmap.c | 10 +- src/mesa/state_tracker/st_cb_drawpixels.c |6 +++--- src/mesa/state_tracker/st_cb_eglimage.c|2 +- src/mesa/state_tracker/st_cb_texture.c | 10 +- src/mesa/state_tracker/st_extensions.c | 14 +++--- src/mesa/state_tracker/st_format.c | 12 ++-- src/mesa/state_tracker/st_texture.c|2 +- 52 files changed, 88 insertions(+), 91 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c b/src/gallium/auxiliary/draw/draw_pipe_aaline.c index c0135f5..5173d33 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c +++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c @@ -407,7 +407,7 @@ aaline_create_texture(struct aaline_stage *aaline) texTemp.width0 = 1 << MAX_TEXTURE_LEVEL; texTemp.height0 = 1 << MAX_TEXTURE_LEVEL; texTemp.depth0 = 1; - texTemp.bind = PIPE_BIND_SAMPLER_VIEW; + texTemp.bind = PIPE_BIND_SAMPLER_VIEW_NORMALIZED; aaline->texture = screen->resource_create(screen, &texTemp); if (!aaline->texture) diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c index ed9a53e..11b436e 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c +++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c @@ -440,7 +440,7 @@ pstip_create_texture(struct pstip_stage *pstip) texTemp.width0 = 32; texTemp.height0 = 32; texTemp.depth0 = 1; - texTemp.bind = PIPE_BIND_SAMPLER_VIEW; + texTemp.bind = PIPE_BIND_SAMPLER_VIEW_NORMALIZED; pstip->texture = screen->resource_create(screen, &texTemp); if (pstip->texture == NULL) diff --git a/src/gallium/auxiliary/util/u_blit.c b/src/gallium/auxiliary/util/u_blit.c index 97fa99e..a86806c 100644 --- a/src/gallium/a
[Mesa-dev] [Bug 29607] New: Global scope re-declarations regression after GLSL2 merge
https://bugs.freedesktop.org/show_bug.cgi?id=29607
Summary: Global scope re-declarations regression after GLSL2
merge
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: cedr...@neonux.com
Compiling the following testcase fail after GLSL2 merge :
--
const float exp = 1.0; // !!! error: `exp' redeclared
void main()
{
const float exp = 1.0; // works (as usual)
gl_Position = vec4(0.0);
}
--
This works if `exp' was redeclared as a function.
However this should work with a re-declaration as variable as well as it used
to be before the merge, the built-in functions scope (where 'exp' is declared)
being the outermost scope, distinct from the shader's global scope, and that
"All variable names, structure type names, and function names in a given scope
share the same name space." (GLSL spec section 4.2).
Other than this small issue, GLSL2 is awesome! :)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29608] New: Regression crash when a function return type is invalid (following GLSL2 merge)
https://bugs.freedesktop.org/show_bug.cgi?id=29608
Summary: Regression crash when a function return type is
invalid (following GLSL2 merge)
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: cedr...@neonux.com
When a function return type is unknown/invalid the GLSL compiler crashes
instead of issuing a proper "invalid type" error.
This only occurs when the invalid type is return type of a function, not when a
function parameter is an invalid type.
Testcase :
--
foo bar()
{
}
void main()
{
gl_Position = vec4(0.0);
}
--
Stacktrace :
#0 0xf6846a45 in ast_function_definition::hir(exec_list*,
_mesa_glsl_parse_state*) () from /usr/local/lib/dri/i965_dri.so
#1 0xf6847340 in _mesa_ast_to_hir(exec_list*, _mesa_glsl_parse_state*) () from
/usr/local/lib/dri/i965_dri.so
#2 0xf683c9fb in _mesa_glsl_compile_shader () from
/usr/local/lib/dri/i965_dri.so
#3 0xf67467c6 in _mesa_CompileShaderARB () from /usr/local/lib/dri/i965_dri.so
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: Fix and re-enable MMX-disabling code
On Mon, 2010-08-16 at 10:56 -0700, José Fonseca wrote:
> On Mon, 2010-08-16 at 10:30 -0700, nobled wrote:
> > I think this might be the problem that kept -disable-mmx from working;
> > can somebody test it? (attached)
> >
> > @@ -152,15 +151,13 @@ lp_set_target_options(void)
> > * See also:
> > * - http://llvm.org/bugs/show_bug.cgi?id=3287
> > * -
> > http://l4.me.uk/post/2009/06/07/llvm-wrinkle-3-configuration-what-configuration/
> > -*
> > -* XXX: Unfortunately this is not working.
> > */
> > - static boolean first = FALSE;
> > + static boolean first = TRUE;
> > if (first) {
> >static const char* options[] = {
> > "prog",
> > "-disable-mmx"
> >};
> >llvm::cl::ParseCommandLineOptions(2, const_cast(options));
> >first = FALSE;
> > }
>
> Lol. Quite likely!
I've tested and it fixed it. For example, doing
lp_test_format -v -v 2>&1 | grep '%mm[0-9]'
no longer shows any MMX register.
Thanks!
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl2: compile error on MSVC (string constant exceeds 65535 bytes)
Hi, Since commits 2f9ecc818d67 and a433cd286c60 (Add builtins profile for GLSL 1.30), GLSL2 does not compile on MSVC 2008: builtin_function.cpp(15821) : fatal error C1091: compiler limit: string exceeds 65535 bytes in length It does seem quite stupid to have 64k limit for strings in a 21st century compiler, but that's what MSVC has. Would it be possible to somehow split that string up? Or have it be generated in a more compact form? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29608] Regression crash when a function return type is invalid (following GLSL2 merge)
https://bugs.freedesktop.org/show_bug.cgi?id=29608 --- Comment #1 from Cedric Vivier 2010-08-17 05:10:14 PDT --- FWIW I forgot to add previous error for such error was pre-GLSL2 : "" Error: undeclared type name 'foo' "" -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] [PATCH 0/4] New coordinate normalization patches with bind flags
On 17.08.2010 09:09, Luca Barbieri wrote: > This is a new approach to the coordinate normalization issue. > I only compile tested this, and posted it to find out if I'm on the right > track, and will do more testing if so. > > On the state tracker -> driver front, I no longer have any resource flags and > instead split PIPE_BIND_SAMPLER_VIEW into 4 separate flags. > > Those are: > PIPE_BIND_SAMPLER_VIEW_ANY: asks for a normalization of the driver's choice > PIPE_BIND_SAMPLER_VIEW_NORMALIZED: asks for normalized, any wrap mode > PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP: asks for unnormalized, clamp mode > PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_NON_CLAMP: asks for unnormalized, > non-clamp > > And PIPE_BIND_SAMPLER_VIEW_ALL which is an OR of them all. > All of these imply PIPE_BIND_SAMPLER_VIEW_ANY. > > I think this is the conceptually cleanest approach, even though it requires > to modify all instances of PIPE_BIND_SAMPLER_VIEW (hence the long diffstat). > > > On the driver -> state tracker front, I split the flag into two flags. > This allows the driver to either express no preference, or express any of the > two preferences. > > I haven't (yet?) replaced them with a query, since Keith hasn't elaborated > on his idea yet, and I don't like all the ways of adding a query I can think > of myself very much (less CPU-efficient, more driver code, no apparent gain). > > What do you think? Is this the right thing? I don't like it, imho adds too much interface clutter with little gain (for most hardware). I liked the original idea much better, though I don't quite understood why you needed to change the hint in the driver. As for if the internal code should use normalized or unnormalized coords, wouldn't it be much easier to add a pipe query like "SUPPORTS_NPOT_NORMALIZED" and then use unnormalized based on that and the resource hint, otherwise just use always normalized? It seems there's no hardware which really prefers unnormalized (unless it can't do it at all) hence it seems just fine to me to always prefer normalized (i965 for instance doesn't support unnormalized coords at all for sampling instructions, these are just scaled in the fragment shader). Of course, that doesn't tell you if unnormalized and wrap modes work for instance. But there's no need for that currently, and if we have opencl support we just have to assume the driver can do it anyway (if it supports opencl). Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] [PATCH 0/4] New coordinate normalization patches with bind flags
> I don't like it, imho adds too much interface clutter with little gain > (for most hardware). There is a tradeoff here between a clean and general but intrusive approach (this one), and a minimal but conceptually imperfect approach (the previous one). Keith didn't seem to like the previous minimal patchset, so I proposed this one. > I liked the original idea much better, though I > don't quite understood why you needed to change the hint in the driver. For instance, r300 apparently always likes normalized coordinates, while nv30 needs unnormalized coords for NPOT, so the driver must provide some information to make this work. > As for if the internal code should use normalized or unnormalized > coords, wouldn't it be much easier to add a pipe query like > "SUPPORTS_NPOT_NORMALIZED" and then use unnormalized based on that and > the resource hint, otherwise just use always normalized? I'm not sure I understand this fully: you seem to propose to use _both_ a resource hint and a global cap. But if you have a resource hint, then why would you need a global cap as well? This patchset uses just a resource hint, or more precisely two bits of hint, so that all 3 states (prefer unnormalized, prefer normalized, no preference) can be represented. > It seems there's no hardware which really prefers unnormalized (unless > it can't do it at all) hence it seems just fine to me to always prefer > normalized (i965 for instance doesn't support unnormalized coords at all > for sampling instructions, these are just scaled in the fragment shader). nv30 apparently only supports unnormalized coordinates on NPOT textures (due to GL_TEXTURE_RECTANGLE), and thus must prefer unnormalized in the NPOT case. The same applies for POT textures with a linear layout. llvmpipe would probably prefer unnormalized coords at least in some cases since it saves a multiplication. > Of course, that doesn't tell you if unnormalized and wrap modes work for > instance. But there's no need for that currently, and if we have opencl > support we just have to assume the driver can do it anyway (if it > supports opencl). Yes, for this PIPE_CAP_NPOT_TEXTURES should be essentially OK for now, and we can add other caps when needed. This patchset however theoretically allows to use is_format_supported to formulate such queries, and allows to have different support depending on format. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium: add resource normalization flags (v3)
On Tue, 2010-08-17 at 00:09 -0700, Luca Barbieri wrote: > -#define PIPE_BIND_STREAM_OUTPUT(1 << 11) /* > set_stream_output_buffers */ > + > +/* Sampler views can be created based on this texture. Only the > + * normalization preferred by the driver can be used, unless the > other > + * flags below are set as well. Only clamp wrap modes are allowed. */ > +#define PIPE_BIND_SAMPLER_VIEW_ANY (1 << 2) /* get_sampler_view > */ I don't see the need for this "any" flag -- if this is an internally generated texture, the state tracker can query the driver, find out what normalization it prefers, and then use that explicitly. > +/* State trackers must set this flag if they/the user API need to be > able to use > + * unnormalized coodinates with clamp, clamp-to-edge or > clamp-to-border wrap > + * mode with this resource when a sampler view based on it is bound. > + * > + * OpenCL and OpenGL TEXTURE_RECTANGLE textures will have this flag > set. > + */ > +#define PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP ((1 << 2) | (1 << > 3)) > + > +/* State trackers must set this flag if they/the user API need to be > able to use > + * unnormalized coordinates with non-clamp wrap modes with this > resource > + * when a sampler view based on it is bound. > + * > + * OpenCL textures will have this flag set. > + */ > +#define PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_NON_CLAMP ((1 << 2) | (1 > << 4)) > + > +/* State trackers must set this flag if they/the user API need to be > able to use > + * normalized coordinates with any wrap mode with this resource > + * when a sampler view based on it is bound. > + * > + * OpenCL, OpenGL TEXTURE_2D and D3D11 textures will have this flag > set. > + */ > +#define PIPE_BIND_SAMPLER_VIEW_NORMALIZED ((1 << 2) | (1 << 5)) Is there a practical difference at the driver level between the two unnormalized versions? I know some hardware will support one and not the other, but that's something to be handled with queries. Once we get around to creating a texture, is it going to get layed out differently depending on whether it uses clamp vs wrap addressing? Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium: add resource normalization flags (v3)
On Tue, 2010-08-17 at 00:09 -0700, Luca Barbieri wrote: > + > +/* State trackers should support using either normalization in all > internal drawing > + * code, using these flag to tell which one to use. > + * > + * If they do not have such support, then they should indicate the > + * normalization needed using the bind flags, but they should be > aware > + * that if it is different than the API-needed one, some drivers may > + * fail creation because they only support one normalization at once. > + * > + * State trackers must not set these flags. > + * > + * Drivers should set these flags to inform the state tracker of the > normalization > + * it should use in internal drawing code, if they prefer any. > + * > + * Drivers who need to always have the same normalization used for a > given > + * resource must set these flags according to the bind flags above, > and refuse > + * creation if too many normalization bind flags are set. > + */ > +#define PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS (1 << 1) > +#define PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS (1 << 2) > + Again, I don't see why this needs to be per-resource information -- surely the hardware has a single preference that it keeps under all circumstances? Or even if it's more complex than that, it's hard to believe it is so random it needs to be handled per-resource. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] [PATCH 0/4] New coordinate normalization patches with bind flags
On 17.08.2010 16:12, Luca Barbieri wrote: >> I don't like it, imho adds too much interface clutter with little gain >> (for most hardware). > There is a tradeoff here between a clean and general but intrusive > approach (this one), and a minimal but conceptually imperfect approach > (the previous one). > Keith didn't seem to like the previous minimal patchset, so I proposed this > one. > >> I liked the original idea much better, though I >> don't quite understood why you needed to change the hint in the driver. > For instance, r300 apparently always likes normalized coordinates, > while nv30 needs unnormalized coords for NPOT, so the driver must > provide some information to make this work. > >> As for if the internal code should use normalized or unnormalized >> coords, wouldn't it be much easier to add a pipe query like >> "SUPPORTS_NPOT_NORMALIZED" and then use unnormalized based on that and >> the resource hint, otherwise just use always normalized? > I'm not sure I understand this fully: you seem to propose to use > _both_ a resource hint and a global cap. > But if you have a resource hint, then why would you need a global cap as well? > This patchset uses just a resource hint, or more precisely two bits of > hint, so that all 3 states (prefer unnormalized, prefer normalized, no > preference) can be represented. Well I don't like drivers changing the hints flag on their own, overwriting what the state tracker set. Hence the suggestion to just always use normalized coords unless the driver can't handle it (which can be a usual global query). > >> It seems there's no hardware which really prefers unnormalized (unless >> it can't do it at all) hence it seems just fine to me to always prefer >> normalized (i965 for instance doesn't support unnormalized coords at all >> for sampling instructions, these are just scaled in the fragment shader). > nv30 apparently only supports unnormalized coordinates on NPOT > textures (due to GL_TEXTURE_RECTANGLE), and thus must prefer > unnormalized in the NPOT case. > The same applies for POT textures with a linear layout. I think I'm missing for what such pot textures are used. Sounds weird that you have pot textures which need unnormalized coords (that case indeed couldn't be handled by my proposal, though I guess you could still do the "hack" that the driver changes the unnormalized hint). > > llvmpipe would probably prefer unnormalized coords at least in some > cases since it saves a multiplication. This is possible but I don't think we'd care enough. > >> Of course, that doesn't tell you if unnormalized and wrap modes work for >> instance. But there's no need for that currently, and if we have opencl >> support we just have to assume the driver can do it anyway (if it >> supports opencl). > Yes, for this PIPE_CAP_NPOT_TEXTURES should be essentially OK for now, > and we can add other caps when needed. > This patchset however theoretically allows to use is_format_supported > to formulate such queries, and allows to have different support > depending on format. Hmm yes that's right. I guess it would be possible some hw would for instance support unnormalized coords not for compressed formats or something like that but I don't know if that's really the case for any hw out there. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29613] New: OSMesa and GL cannot be linked together
https://bugs.freedesktop.org/show_bug.cgi?id=29613 Summary: OSMesa and GL cannot be linked together Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: hob...@ohiou.edu Before commit cbf30fce322506bd43692617de9d201533f41532 an application was required to link GL (xlib driver) in order to link OSMesa. The application could then do on-screen or off-screen software rendering. After cbf30fce322506bd43692617de9d201533f41532 an application can only link GL or OSMesa but not both. Applications that assume the old behaviour can not be built. The change was made because -fvisibility=hidden hid the internal mesa functions in GL from OSMesa. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging translate and unnormalized-coords-hint?
- In terms of the unnormalized change, I think I'd like to go over it one more time. It looks like there are a few things happening at once: a) The state tracker is informing the driver whether it will use normalized texcoords, unnormalized texcoords or both for a given texture. b) There is a query from the state tracker to the driver to find out which it prefers (normalized vs unnormalized) for a given texture. These two usages seem somewhat disjoint, and the mechanism for the query is via a new channel we haven't used for queries in the past - ie based on the driver modifying some of the values in the create-resource template. Is this a fair summary of the intentions of the change? -- On Mon, 2010-08-16 at 07:20 -0700, Luca Barbieri wrote: > > Is this a fair summary of the intentions of the change? > It's an excellent summary. (Just adding it back in...) What's wrong with addressing these needs respectively by: a) Adding a new pipe_texture_target enum PIPE_TEXTURE_RECT to capture the GL usage (unnormalized, clamp). Think about CL later. b) Adding a pipe cap to determine hardware preference for state-tracker generated rendering (prefer TEXTURE_RECT vs TEXTURE_2D). For API rendering (ie non-state-tracker-generated), pass through exactly what the API asks for. Roland suggested an alternate mechanism for b: adding a cap for whether the hw supports NPOT + normalized, which would also be fine for me. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium: add resource normalization flags (v3)
> I don't see the need for this "any" flag -- if this is an internally > generated texture, the state tracker can query the driver, find out what > normalization it prefers, and then use that explicitly. It is for internal textures, where we need to ask for the ability to use it as a sampler view, but not ask for any specific normalization. If we had only SAMPLER_VIEW_$norm, there would be no way to express that. > Once we get around to creating a texture, is it going to get layed out > differently Yes, it's going to get laid out differently depending on whether we want to use normalized coordinates or not. On nv30 we have two layouts: 1. "Swizzled" or z-curve, only for power-of-two textures. Supports mipmaps and requires normalized coordinates. 2. Linear layout. Doesn't support mipmaps, doesn't support non-clamp wrap and requires unnormalized coordinates On nv40 we have two layouts with less restrictions: 1. "Swizzled" or z-curve, only for power-of-two textures. 2. Linear layout. Support mipmaps, but only with normalized coordinates. Normalized coordinates can always be used. Unnormalized coordinates can always be used, as long as there are no mipmaps and either the texture is POT or the wrap mode is clamp. Also, cube maps must be square POT and use normalized coordinates on both nv30 and nv40 > depending on whether it uses clamp vs wrap addressing? No, this does not happen on any known hardware. However, since we are already splitting unnormalized and normalized, and some hardware requires clamp mode for unnormalized, it seems cleaner to also split unnormalized according to wrap mode. We could however indeed only have PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED and have a cap for non-clamp modes with unnormalized coords (only needed by OpenCL afaik). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium: add resource normalization flags (v3)
> Again, I don't see why this needs to be per-resource information -- > surely the hardware has a single preference that it keeps under all > circumstances? For nv30 there are two layouts that each require one normalization, so the "preference" (actually, a requirement) depends on the layout and hence on the resource. > Or even if it's more complex than that, it's hard to believe it is so > random it needs to be handled per-resource. In general, it is per internal texture layout, but since internal texture layouts are not exposed, it needs to be per-resource. I don't think this is a bad thing though at all: the user code is very simple (just a check of a flag on the resource) and the driver has a lot of flexibility. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging translate and unnormalized-coords-hint?
> What's wrong with addressing these needs respectively by: > > a) Adding a new pipe_texture_target enum PIPE_TEXTURE_RECT to capture > the GL usage (unnormalized, clamp). Think about CL later. I think this is essentially equivalent to my latest patchset in the following sense: - Your PIPE_TEXTURE_RECT is equivalent to my PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP - Your PIPE_TEXTURE_2D is equivalent to my PIPE_BIND_SAMPLER_VIEW_NORMALIZED I think a bind flag is the more appropriate way to represent this, because: 1. If we don't ever create a sampler view (e.g. render target) this doesn't a matter 2. Most checks for PIPE_TEXTURE_2D don't care about this, but only about the physical dimensions. Drivers that have multiple layouts already have internal flags for them. > b) Adding a pipe cap to determine hardware preference for state-tracker > generated rendering (prefer TEXTURE_RECT vs TEXTURE_2D). For API I think a single global cap is insufficient: - r300g and i965 always prefer normalized coordinates for internal drawing (since they emulate unnormalized with a multiply) even for GL_TEXTURE_RECTANGLE - llvmpipe might perhaps always prefer unnormalized for internal drawing - nv30 requires normalized or requires unnormalized depending on texture layout Hence, you at least need two global caps: one for the preference related to TEXTURE_RECT/BIND_UNNORMALIZED_CLAMP, and one for the preference related to TEXTURE_2D/BIND_NORMALIZED. However, the state tracker itself has multiple preferences (it either wants unnormalized to avoid CPU divides if it uses a subrectangle, or it wants normalized to use 0, 1 constants if it uses the whole textures), so the driver ideally should be able to specify "no preference". Thus, we need 4 bits of global caps at least. IMHO using global caps leads to a messier situation that is instead cleanly avoid with per-resource caps. Are there any downsides to per-resource "caps"? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging translate and unnormalized-coords-hint?
On 17.08.2010 16:53, Keith Whitwell wrote: > - > In terms of the unnormalized change, I think I'd like to go over it one > more time. > > It looks like there are a few things happening at once: > > a) The state tracker is informing the driver whether it will use > normalized texcoords, unnormalized texcoords or both for a given > texture. > > b) There is a query from the state tracker to the driver to find out > which it prefers (normalized vs unnormalized) for a given texture. > > These two usages seem somewhat disjoint, and the mechanism for the query > is via a new channel we haven't used for queries in the past - ie based > on the driver modifying some of the values in the create-resource > template. > > Is this a fair summary of the intentions of the change? > -- > > On Mon, 2010-08-16 at 07:20 -0700, Luca Barbieri wrote: >>> Is this a fair summary of the intentions of the change? >> It's an excellent summary. > > (Just adding it back in...) > > What's wrong with addressing these needs respectively by: > > a) Adding a new pipe_texture_target enum PIPE_TEXTURE_RECT to capture > the GL usage (unnormalized, clamp). Think about CL later. > > b) Adding a pipe cap to determine hardware preference for state-tracker > generated rendering (prefer TEXTURE_RECT vs TEXTURE_2D). For API > rendering (ie non-state-tracker-generated), pass through exactly what > the API asks for. > > Roland suggested an alternate mechanism for b: adding a cap for whether > the hw supports NPOT + normalized, which would also be fine for me. > Yes, this is pretty much the same throughout - if you have a resource unnormalized hint or just use a different target is pretty equivalent too (except the former allows drivers to completely ignore it). Though I guess there are the finer subtleties of "normal" GL 2.0 npot textures - e.g. maybe you'd want to fix coords in the generated fragment shader for hw which can't handle npot+normalized (if you pretend to support GL 2.0), but you'd still wanted the internal blit code to use unnormalized coords for such textures. Though if we'd allow the driver to change the template hint (or the target type but that seems a little less clean) that wouldn't be a problem. Hmm that's all a mess. And if there's some case where we'd prefer unnormalized coordinates even when the hw can do normalized, we can't really express that here - for that the other proposal is better suited. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 28374, which changed state. Bug 28374 Summary: SIGSEGV shader/slang/slang_typeinfo.c:534 https://bugs.freedesktop.org/show_bug.cgi?id=28374 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium: add resource normalization flags (v3)
On Tue, Aug 17, 2010 at 10:56 AM, Luca Barbieri wrote: >> I don't see the need for this "any" flag -- if this is an internally >> generated texture, the state tracker can query the driver, find out what >> normalization it prefers, and then use that explicitly. > > It is for internal textures, where we need to ask for the ability to > use it as a sampler view, but not ask for any specific normalization. > > If we had only SAMPLER_VIEW_$norm, there would be no way to express that. > >> Once we get around to creating a texture, is it going to get layed out >> differently > > Yes, it's going to get laid out differently depending on whether we > want to use normalized coordinates or not. > > On nv30 we have two layouts: > 1. "Swizzled" or z-curve, only for power-of-two textures. Supports > mipmaps and requires normalized coordinates. > 2. Linear layout. Doesn't support mipmaps, doesn't support non-clamp > wrap and requires unnormalized coordinates > > On nv40 we have two layouts with less restrictions: > 1. "Swizzled" or z-curve, only for power-of-two textures. > 2. Linear layout. Support mipmaps, but only with normalized coordinates. > Normalized coordinates can always be used. > Unnormalized coordinates can always be used, as long as there are no > mipmaps and either the texture is POT or the wrap mode is clamp. > > Also, cube maps must be square POT and use normalized coordinates on > both nv30 and nv40 > Here's a rough idea on radeon hardware: r3xx/r4xx normalized coordinates only NPOT textures supported Limited clamp and mipmap support with NPOT textures r5xx normalized and unnormalized coordinates supported NPOT textures supported Limited clamp and mipmap support with NPOT textures Limited clamp support with unnormalized coordinates r6xx/r7xx normalized and unnormalized coordinates supported NPOT textures supported Full clamp and mipmap support with NPOT textures Limited clamp support with unnormalized coordinates Alex >> depending on whether it uses clamp vs wrap addressing? > No, this does not happen on any known hardware. > > However, since we are already splitting unnormalized and normalized, > and some hardware requires clamp mode for unnormalized, it seems > cleaner to also split unnormalized according to wrap mode. > > We could however indeed only have PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED > and have a cap for non-clamp modes with unnormalized coords (only > needed by OpenCL afaik). > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging translate and unnormalized-coords-hint?
By the way, to make this clearer, the _absolute_ requirements to have a correct nv30 driver without any emulation code are those: 1. The driver must know whether a POT texture is GL_TEXTURE_2D or is a GL_TEXTURE_RECTANGLE that just happens to be POT 2. If the driver is nv30, the state tracker _must_ use unnormalized coordinates if it informed the driver that the texture is GL_TEXTURE_RECTANGLE and _must_ use normalized coordinates otherwise. The first patchset implemented exactly this: this results in a minimal change, but a conceptually messy one. The second patchset implemented the general model that has this as a special case, and is more intrusive but conceptually clean. Using a general model has additional (minor) benefits, especially in the normalization preference part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27265] GLSL Compiler doesnt link the attached vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=27265 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Eric Anholt 2010-08-17 08:33:17 PDT --- With the glsl2 merge, written but not read varyings are demoted to auto, and likely dead-code eliminated as a result. So this should be fixed now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 27265, which changed state. Bug 27265 Summary: GLSL Compiler doesnt link the attached vertex shader https://bugs.freedesktop.org/show_bug.cgi?id=27265 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging translate and unnormalized-coords-hint?
On 17.08.2010 17:22, Luca Barbieri wrote: >> What's wrong with addressing these needs respectively by: >> >> a) Adding a new pipe_texture_target enum PIPE_TEXTURE_RECT to capture >> the GL usage (unnormalized, clamp). Think about CL later. > > I think this is essentially equivalent to my latest patchset in the > following sense: > - Your PIPE_TEXTURE_RECT is equivalent to my > PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP > - Your PIPE_TEXTURE_2D is equivalent to my PIPE_BIND_SAMPLER_VIEW_NORMALIZED > > I think a bind flag is the more appropriate way to represent this, because: > 1. If we don't ever create a sampler view (e.g. render target) this > doesn't a matter > 2. Most checks for PIPE_TEXTURE_2D don't care about this, but only > about the physical dimensions. Drivers that have multiple layouts > already have internal flags for them. > >> b) Adding a pipe cap to determine hardware preference for state-tracker >> generated rendering (prefer TEXTURE_RECT vs TEXTURE_2D). For API > > I think a single global cap is insufficient: > - r300g and i965 always prefer normalized coordinates for internal > drawing (since they emulate unnormalized with a multiply) even for > GL_TEXTURE_RECTANGLE > - llvmpipe might perhaps always prefer unnormalized for internal drawing > - nv30 requires normalized or requires unnormalized depending on texture > layout > > Hence, you at least need two global caps: one for the preference > related to TEXTURE_RECT/BIND_UNNORMALIZED_CLAMP, and one for the > preference related to TEXTURE_2D/BIND_NORMALIZED. > > However, the state tracker itself has multiple preferences (it either > wants unnormalized to avoid CPU divides if it uses a subrectangle, or > it wants normalized to use 0, 1 constants if it uses the whole > textures), so the driver ideally should be able to specify "no > preference". > > Thus, we need 4 bits of global caps at least. > > IMHO using global caps leads to a messier situation that is instead > cleanly avoid with per-resource caps. > Are there any downsides to per-resource "caps"? I'm not sure it's really worth bothering about all those cases to optimize some divs or muls away. Hence one flag (for tex rect) would be sufficient, otherwise just use normalized. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27261] GLSL Compiler fails on the following vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=27261 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Eric Anholt 2010-08-17 08:35:20 PDT --- With glsl2 merged to master, parsing is fine on all of these. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 27261, which changed state. Bug 27261 Summary: GLSL Compiler fails on the following vertex shader https://bugs.freedesktop.org/show_bug.cgi?id=27261 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 26224] [GLSL] Cannot get location of a uniform struct member
https://bugs.freedesktop.org/show_bug.cgi?id=26224 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Eric Anholt 2010-08-17 08:41:02 PDT --- I think your struct issues should be fixed with the glsl2 merge to Mesa master. Also, I stuffed your two shaders at the bottom into a shader_runner test, and it came out fine (after fixing the vec3 constructor to actually have 3 arguments). So this should be fixed now. If you've got issues with structure usage still, could you make a piglit shader_runner test for it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 26224, which changed state. Bug 26224 Summary: [GLSL] Cannot get location of a uniform struct member https://bugs.freedesktop.org/show_bug.cgi?id=26224 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 26001, which changed state. Bug 26001 Summary: [GLSL 1.10] constructing matrix from matrix succeeds https://bugs.freedesktop.org/show_bug.cgi?id=26001 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 26000, which changed state. Bug 26000 Summary: [GLSL] allowing different parameter qualifier between the function definition and declaration https://bugs.freedesktop.org/show_bug.cgi?id=26000 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25999, which changed state. Bug 25999 Summary: [GLSL] embedded structure constructor fails to compile https://bugs.freedesktop.org/show_bug.cgi?id=25999 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging translate and unnormalized-coords-hint?
> I'm not sure it's really worth bothering about all those cases to > optimize some divs or muls away. Yes, the gain might be marginal, but once you change internal code to support either normalization, supporting fine grained preferences is a tiny change. > Hence one flag (for tex rect) would be > sufficient, otherwise just use normalized. Yes (for the needs of nv30, with loss of generality). However this way you have the following weird check: use_normalized_coords = (texture->target != PIPE_TEXTURE_RECT) || screen->get_param(PIPE_CAP_PREFER_NORMALIZED_EVEN_FOR_RECT); With a per-resource cap, you have this natural one instead: use_normalized_coords = (texture->flags & PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS); And if you have two flags, you can also do this use_normalized_coords = !(texture->flags & PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS); depending on the preference of the state tracker itself (they differ if neither flag is set). It seems to me that the second and third checks are way cleaner than the first, and I can't think of anything that would negatively balance this significant gain. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25878, which changed state. Bug 25878 Summary: [GLSL] sampler is converted to int successfully https://bugs.freedesktop.org/show_bug.cgi?id=25878 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25877, which changed state. Bug 25877 Summary: [GLSL 1.10] implicit conversion from "int" to "float" should not be allowed https://bugs.freedesktop.org/show_bug.cgi?id=25877 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25830, which changed state. Bug 25830 Summary: [GLSL] allowing non-constant-expression as const declaration initializer https://bugs.freedesktop.org/show_bug.cgi?id=25830 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] [PATCH 0/4] New coordinate normalization patches with bind flags
> Well I don't like drivers changing the hints flag on their own, > overwriting what the state tracker set. Hence the suggestion to just > always use normalized coords unless the driver can't handle it (which > can be a usual global query). In my second patchset, those flags are owned by the driver, and the state tracker must pass them as 0 (instead, the state tracker uses bind flags, which are distinct, to express its requirement). This is an improvement over the first one, where indeed the driver overrode the state tracker in a weird way. Why don't you like this? >> llvmpipe would probably prefer unnormalized coords at least in some >> cases since it saves a multiplication. > This is possible but I don't think we'd care enough. I agree, but it's trivial to support this once you support both normalizations. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 16854] GLSL function call at global scope causes SEGV
https://bugs.freedesktop.org/show_bug.cgi?id=16854 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Eric Anholt 2010-08-17 08:54:52 PDT --- Other than the implicit conversion, glsl2 is fine with this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 16854, which changed state. Bug 16854 Summary: GLSL function call at global scope causes SEGV https://bugs.freedesktop.org/show_bug.cgi?id=16854 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 16856] GLSL indexing of unsized array results in assertion failure
https://bugs.freedesktop.org/show_bug.cgi?id=16856 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Eric Anholt 2010-08-17 09:03:56 PDT --- After fixing the shader to use a constant expression for the array sizing, it looks like glsl2 is fine with this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 16856, which changed state. Bug 16856 Summary: GLSL indexing of unsized array results in assertion failure https://bugs.freedesktop.org/show_bug.cgi?id=16856 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 18659] Crash in shader/slang/slang_codegen.c _slang_gen_function_call_name()
https://bugs.freedesktop.org/show_bug.cgi?id=18659 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Eric Anholt 2010-08-17 09:06:07 PDT --- This testcase compiles under glsl2, and I don't know of any specific issues brought up with linking in this bug, so I think it's fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 18659, which changed state. Bug 18659 Summary: Crash in shader/slang/slang_codegen.c _slang_gen_function_call_name() https://bugs.freedesktop.org/show_bug.cgi?id=18659 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 24553] shader compilation times explode when using more () pairs
https://bugs.freedesktop.org/show_bug.cgi?id=24553 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Eric Anholt 2010-08-17 09:09:49 PDT --- glsl2 is merged, and parsing is nice and fast now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 24553, which changed state. Bug 24553 Summary: shader compilation times explode when using more () pairs https://bugs.freedesktop.org/show_bug.cgi?id=24553 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25664, which changed state. Bug 25664 Summary: [GLSL] re-declaring an empty array fails to compile https://bugs.freedesktop.org/show_bug.cgi?id=25664 What|Old Value |New Value Resolution||FIXED Status|ASSIGNED|RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25769, which changed state. Bug 25769 Summary: [GLSL] "float" can be implicitly converted to "int" https://bugs.freedesktop.org/show_bug.cgi?id=25769 What|Old Value |New Value Resolution||FIXED Status|REOPENED|RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25808, which changed state. Bug 25808 Summary: [GLSL] const variable is modified successfully https://bugs.freedesktop.org/show_bug.cgi?id=25808 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging translate and unnormalized-coords-hint?
On 17.08.2010 17:43, Luca Barbieri wrote: >> I'm not sure it's really worth bothering about all those cases to >> optimize some divs or muls away. > Yes, the gain might be marginal, but once you change internal code to > support either normalization, supporting fine grained preferences is a > tiny change. > >> Hence one flag (for tex rect) would be >> sufficient, otherwise just use normalized. > > Yes (for the needs of nv30, with loss of generality). > > However this way you have the following weird check: > use_normalized_coords = (texture->target != PIPE_TEXTURE_RECT) || > screen->get_param(PIPE_CAP_PREFER_NORMALIZED_EVEN_FOR_RECT); Well I'd have preferred a slightly easier (imho) to read version: nonnormalized coords = (texture->target == PIPE_TEXTURE_RECT) && !screen->get_param(PIPE_CAP_SUPPORTS_NPOT_NORMALIZED). Plus the parameter should probably be stored somewhere not requeried when needed multiple times. > > With a per-resource cap, you have this natural one instead: > use_normalized_coords = (texture->flags & > PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS); > > And if you have two flags, you can also do this > use_normalized_coords = !(texture->flags & > PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS); > > depending on the preference of the state tracker itself (they differ > if neither flag is set). > > It seems to me that the second and third checks are way cleaner than > the first, and I can't think of anything that would negatively balance > this significant gain. They are less complex, that much is true. Doesn't look that significant to me, and needs a bit less code elsewhere. It is true this is more a special case for nvfx, but I just don't see it as very useful to have these hints used by other drivers. Especially because APIs always use normalized anyway for rendering (except for the special RECT case) and newer hw needs to support both anyway, the gains in internal code look minimal to me. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25826, which changed state. Bug 25826 Summary: [GLSL] declaring an unsized array then re-declaring with a size fails https://bugs.freedesktop.org/show_bug.cgi?id=25826 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25827, which changed state. Bug 25827 Summary: [GLSL] vector constructor accepts too many arguments successfully https://bugs.freedesktop.org/show_bug.cgi?id=25827 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 25829, which changed state. Bug 25829 Summary: [GLSL] allowing non-void function without returning value https://bugs.freedesktop.org/show_bug.cgi?id=25829 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] [PATCH 0/4] New coordinate normalization patches with bind flags
On 17.08.2010 17:48, Luca Barbieri wrote: >> Well I don't like drivers changing the hints flag on their own, >> overwriting what the state tracker set. Hence the suggestion to just >> always use normalized coords unless the driver can't handle it (which >> can be a usual global query). > > In my second patchset, those flags are owned by the driver, and the > state tracker must pass them as 0 (instead, the state tracker uses > bind flags, which are distinct, to express its requirement). > This is an improvement over the first one, where indeed the driver > overrode the state tracker in a weird way. > Why don't you like this? Because there is some expectation (with the exception of the private flags) this is state set by the state tracker. Though I guess this isn't too bad. > >>> llvmpipe would probably prefer unnormalized coords at least in some >>> cases since it saves a multiplication. >> This is possible but I don't think we'd care enough. > I agree, but it's trivial to support this once you support both > normalizations. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Bug 29044 depends on bug 26990, which changed state. Bug 26990 Summary: [GLSL] variable declaration in "while" fails to compile https://bugs.freedesktop.org/show_bug.cgi?id=26990 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29601] Crash in video games in the new glsl compiler
https://bugs.freedesktop.org/show_bug.cgi?id=29601 Eric Anholt changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|mesa-...@lists.freedesktop. |e...@anholt.net |org | --- Comment #1 from Eric Anholt 2010-08-17 09:32:40 PDT --- Both run fine for me. Maybe some particular combination of graphics settings? MESA_GLSL=dump can get you shader source to trim down to a minimal testcase to run under glsl_compiler for debugging, since your failure is during compile. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] [PATCH 0/4] New coordinate normalization patches with bind flags
> Because there is some expectation (with the exception of the private > flags) this is state set by the state tracker. Yes, currently it's this way, but I think that overall, this is suboptimal. For instance, I think that drivers should override the bind flags, setting them to what the resource actually supports. Right now, after creation the bind flags aren't very useful, since they represent an arbitrary subset of what the resource actually supports. For instance, this would allow the driver to decide between using the blitter module or the 2D engine just by checking the bind flags instead of requiring internal flags or duplicated logic, and would allow an arbitrary util module to choose between a fast path that requires the ability to render and a software fallback, even if the state tracker did not anticipate the need to render and thus didn't ask for it. In fact it's quite possible that right now some parts of the codebase might be unnecessarily using fallbacks just because only a few bind flags were specified at creation, even though most resources actually support any kind of operation. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29607] Global scope re-declarations regression after GLSL2 merge
https://bugs.freedesktop.org/show_bug.cgi?id=29607 Eric Anholt changed: What|Removed |Added Priority|medium |high AssignedTo|mesa-...@lists.freedesktop. |kenn...@whitecape.org |org | --- Comment #1 from Eric Anholt 2010-08-17 09:45:01 PDT --- Note that the 1.20 wording you quoted is different from 1.10. We do need to support the 1.20 stuff. I'm not entirely clear from reading 1.10 on whether it allows what you've done there. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27403] GLSL struct causing "Invalid src register file ..." error
https://bugs.freedesktop.org/show_bug.cgi?id=27403 Eric Anholt changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|mesa-...@lists.freedesktop. |e...@anholt.net |org | --- Comment #3 from Eric Anholt 2010-08-17 09:49:25 PDT --- There is a piglit testcase for this now: glsl-fs-uniform-sampler-struct -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27266] Cubosphere: undefined function 'texture2D' / incompatible types in assignment
https://bugs.freedesktop.org/show_bug.cgi?id=27266 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Sven Arvidsson 2010-08-17 10:24:37 PDT --- The glsl2 merge seems to have solved this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29420] Amnesia / HPL2 RendererFeatTest - not rendering correctly
https://bugs.freedesktop.org/show_bug.cgi?id=29420 --- Comment #4 from Sven Arvidsson 2010-08-17 10:28:09 PDT --- The GLSL errors are gone now, it's still not rendering correctly though, probably because of these remaining errors: ERROR: Could not create texture 'LinearDepth' ERROR: Frame buffer 'LinearDepth' is not complete! Incomplete draw buffer! ERROR: Could not create texture 'EdgeSmoothLinearDepth' ERROR: Frame buffer 'EdgeSmoothLinearDepth' is not complete! Incomplete draw buffer! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Mesa prog_optimize.c: solve glsl2 regression
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Benjamin Segovia wrote:
> - In one optimization pass, register files may have been messed therefore
> merging instructions which use the same index in two different register
> files
>
> - The fix consists in only processing temporary registers as it must be
I was just getting ready to commit this patch, but it seems the test
case is already fixed. Something in Eric's commit below makes the
problem in glsl-vs-mat-mul-1 go away.
commit 62383ae6fe5d2ca092e8f9d8dae2ba9562e03d95
Author: Eric Anholt
Date: Thu Jul 8 17:05:42 2010 -0700
i965: Add disasm for Compr4 instruction compression.
Do you think your patch is still necessary?
> ---
> src/mesa/program/prog_optimize.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/program/prog_optimize.c
> b/src/mesa/program/prog_optimize.c
> index ab87875..0dc7790 100644
> --- a/src/mesa/program/prog_optimize.c
> +++ b/src/mesa/program/prog_optimize.c
> @@ -758,7 +758,11 @@ _mesa_remove_extra_moves(struct gl_program *prog)
> nesting--;
> break;
>case OPCODE_MOV:
> - if (i > 0 && can_downward_mov_be_modifed(mov) && nesting == 0) {
> + if (i > 0 &&
> + can_downward_mov_be_modifed(mov) &&
> + mov->SrcReg[0].File == PROGRAM_TEMPORARY &&
> + nesting == 0)
> + {
>
> /* see if this MOV can be removed */
> const GLuint id = mov->SrcReg[0].Index;
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxq3msACgkQX1gOwKyEAw8coQCfQpxPW06XRV+sCdOKQFrcZ0Z4
xEUAn2JJOsFzXhZ79ncVaEDxmaLMTEnz
=dXdB
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Mesa prog_optimize.c: solve glsl2 regression
Yes, absolutely. The code was just wrong.
Ben
From: Ian Romanick [...@freedesktop.org]
Sent: Tuesday, August 17, 2010 1:09 PM
To: Segovia, Benjamin
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Mesa prog_optimize.c: solve glsl2 regression
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Benjamin Segovia wrote:
> - In one optimization pass, register files may have been messed therefore
> merging instructions which use the same index in two different register
> files
>
> - The fix consists in only processing temporary registers as it must be
I was just getting ready to commit this patch, but it seems the test
case is already fixed. Something in Eric's commit below makes the
problem in glsl-vs-mat-mul-1 go away.
commit 62383ae6fe5d2ca092e8f9d8dae2ba9562e03d95
Author: Eric Anholt
Date: Thu Jul 8 17:05:42 2010 -0700
i965: Add disasm for Compr4 instruction compression.
Do you think your patch is still necessary?
> ---
> src/mesa/program/prog_optimize.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/program/prog_optimize.c
> b/src/mesa/program/prog_optimize.c
> index ab87875..0dc7790 100644
> --- a/src/mesa/program/prog_optimize.c
> +++ b/src/mesa/program/prog_optimize.c
> @@ -758,7 +758,11 @@ _mesa_remove_extra_moves(struct gl_program *prog)
> nesting--;
> break;
>case OPCODE_MOV:
> - if (i > 0 && can_downward_mov_be_modifed(mov) && nesting == 0) {
> + if (i > 0 &&
> + can_downward_mov_be_modifed(mov) &&
> + mov->SrcReg[0].File == PROGRAM_TEMPORARY &&
> + nesting == 0)
> + {
>
> /* see if this MOV can be removed */
> const GLuint id = mov->SrcReg[0].Index;
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxq3msACgkQX1gOwKyEAw8coQCfQpxPW06XRV+sCdOKQFrcZ0Z4
xEUAn2JJOsFzXhZ79ncVaEDxmaLMTEnz
=dXdB
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29620] New: link errors in glcpp/glcpp
https://bugs.freedesktop.org/show_bug.cgi?id=29620 Summary: link errors in glcpp/glcpp Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: david.ro...@mcgill.ca I'm getting link errors (below) involving talloc. I've checked and at least some of the symbols are in the libs. I'm using gcc-4.5.1 have 2.0.3 of talloc installed. This worked the last time I tried to build mesa (1-2 weeks ago, and samba hasn't changed here in the mean time). Here's the log: ar: creating libglsl.a /usr/bin/g++ -I. -I../mesa -I../mapi -I../../include -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_XEXTPROTO_71 -DFEATURE_GL=1 ../mesa/program/hash_table.o ../mesa/program/symbol_table.o main.o ../../src/glsl/libglsl.a -L/usr/local/samba/lib -ltalloc -o glsl_compiler /usr/bin/gcc -I. -I../mesa -I../mapi -I../../include -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_XEXTPROTO_71 -DFEATURE_GL=1 glcpp/glcpp-lex.o glcpp/glcpp-parse.o glcpp/pp.o glcpp/glcpp.o ../mesa/program/hash_table.o ../../src/glsl/libglsl.a -L/usr/local/samba/lib -ltalloc -o glcpp/glcpp glcpp/glcpp-parse.o: In function `add_builtin_define': glcpp-parse.c:(.text+0x587): undefined reference to `_talloc_reference' glcpp-parse.c:(.text+0x5ff): undefined reference to `_talloc_steal' glcpp/glcpp-parse.o: In function `_glcpp_parser_expand_token_list': glcpp-parse.c:(.text+0x686): undefined reference to `talloc_free' glcpp-parse.c:(.text+0x6f4): undefined reference to `talloc_free' glcpp-parse.c:(.text+0x74e): undefined reference to `talloc_free' glcpp-parse.c:(.text+0x80e): undefined reference to `_talloc_steal' glcpp-parse.c:(.text+0x86b): undefined reference to `_talloc_reference' glcpp-parse.c:(.text+0x8f4): undefined reference to `talloc_free' glcpp-parse.c:(.text+0xaab): undefined reference to `_talloc_reference' glcpp-parse.c:(.text+0xc5f): undefined reference to `_talloc_reference' glcpp-parse.c:(.text+0xcee): undefined reference to `talloc_free' glcpp-parse.c:(.text+0xf6e): undefined reference to `_talloc_reference' glcpp-parse.c:(.text+0x107c): undefined reference to `_talloc_reference' glcpp-parse.c:(.text+0x10ce): undefined reference to `_talloc_reference' glcpp-parse.c:(.text+0x1137): undefined reference to `talloc_free' glcpp-parse.c:(.text+0x147e): undefined reference to `_talloc_steal' glcpp-parse.c:(.text+0x1597): undefined reference to `talloc_free' glcpp-parse.c:(.text+0x1623): undefined reference to `_talloc_reference' glcpp/glcpp-parse.o: In function `_glcpp_parser_expand_if': glcpp-parse.c:(.text+0x1883): undefined reference to `_talloc_reference' glcpp-parse.c:(.text+0x1976): undefined reference to `_talloc_reference' glcpp-parse.c:(.text+0x19b1): undefined reference to `talloc_free' glcpp-parse.c:(.text+0x19e3): undefined reference to `talloc_free' glcpp/glcpp-parse.o: In function `.L452': glcpp-parse.c:(.text+0x2975): undefined reference to `_talloc_steal' glcpp/glcpp-parse.o: In function `.L450': glcpp-parse.c:(.text+0x2a21): undefined reference to `_talloc_steal' glcpp/glcpp-parse.o: In function `.L449': glcpp-parse.c:(.text+0x2a7c): undefined reference to `_talloc_steal' glcpp/glcpp-parse.o: In function `.L448': glcpp-parse.c:(.text+0x2adf): undefined reference to `_talloc_reference' glcpp/glcpp-parse.o: In function `.L447': glcpp-parse.c:(.text+0x2ba9): undefined reference to `_talloc_reference' glcpp/glcpp-parse.o: In function `.L396': glcpp-parse.c:(.text+0x2d62): undefined reference to `talloc_free' glcpp-parse.c:(.text+0x2dba): undefined reference to `talloc_free' glcpp/glcpp-parse.o: In function `.L411': glcpp-parse.c:(.text+0x2ed0): undefined reference to `talloc_free' glcpp/glcpp-parse.o: In function `.L410': glcpp-parse.c:(.text+0x2f49): undefined reference to `talloc_free' glcpp/glcpp-parse.o: In function `.L406': glcpp-parse.c:(.text+0x3010): undefined reference to `talloc_free' glcpp/glcpp-parse.o:glcpp-parse.c:(.text+0x30ab): more undefined references to `ta
Re: [Mesa-dev] [PATCH] Mesa prog_optimize.c: solve glsl2 regression
BTW, the patch is a real fix not a workaround. This is what has to be done.
Ben
From: mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org
[mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org] On Behalf
Of Segovia, Benjamin [benjamin.sego...@intel.com]
Sent: Tuesday, August 17, 2010 1:18 PM
To: Ian Romanick
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Mesa prog_optimize.c: solve glsl2 regression
Yes, absolutely. The code was just wrong.
Ben
From: Ian Romanick [...@freedesktop.org]
Sent: Tuesday, August 17, 2010 1:09 PM
To: Segovia, Benjamin
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Mesa prog_optimize.c: solve glsl2 regression
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Benjamin Segovia wrote:
> - In one optimization pass, register files may have been messed therefore
> merging instructions which use the same index in two different register
> files
>
> - The fix consists in only processing temporary registers as it must be
I was just getting ready to commit this patch, but it seems the test
case is already fixed. Something in Eric's commit below makes the
problem in glsl-vs-mat-mul-1 go away.
commit 62383ae6fe5d2ca092e8f9d8dae2ba9562e03d95
Author: Eric Anholt
Date: Thu Jul 8 17:05:42 2010 -0700
i965: Add disasm for Compr4 instruction compression.
Do you think your patch is still necessary?
> ---
> src/mesa/program/prog_optimize.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/program/prog_optimize.c
> b/src/mesa/program/prog_optimize.c
> index ab87875..0dc7790 100644
> --- a/src/mesa/program/prog_optimize.c
> +++ b/src/mesa/program/prog_optimize.c
> @@ -758,7 +758,11 @@ _mesa_remove_extra_moves(struct gl_program *prog)
> nesting--;
> break;
>case OPCODE_MOV:
> - if (i > 0 && can_downward_mov_be_modifed(mov) && nesting == 0) {
> + if (i > 0 &&
> + can_downward_mov_be_modifed(mov) &&
> + mov->SrcReg[0].File == PROGRAM_TEMPORARY &&
> + nesting == 0)
> + {
>
> /* see if this MOV can be removed */
> const GLuint id = mov->SrcReg[0].Index;
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxq3msACgkQX1gOwKyEAw8coQCfQpxPW06XRV+sCdOKQFrcZ0Z4
xEUAn2JJOsFzXhZ79ncVaEDxmaLMTEnz
=dXdB
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC] [PATCH 0/3] Coordinate normalization, third attempt
This is a mix of my first and second attempts, and tries to include the best received parts from each. In general, it tries to be both unobtrusive, and have clean semantics. >From the first attempt, it restores the usage of a single st->driver flag instead of 4 bind flags, which is now called PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS. Using a flag instead of a new texture target allows to avoid hundreds of changes to existing code, and allows drivers for modern hardware to just ignore this flag. >From the second attempt, it keeps unchanged the two normalization reference driver->st flags, separated from the flag above. I think this is the approach allows the code to be the simplest, and cleanly separates this aspect from everything else. Also, drivers for modern hardware can just do nothing and thus express no preference. The downside of all this is that the texture usage semantics are quite convoluted, whereas using 4 bind flags, they are simpler. However, they are more predictable, while otherwise everything would depend on the acceptance or not of specific combinations of bind flags. Also, nv30 is slightly worse off (because we can't differentiate between POT TEXTURE_2D and internal textures), but this doesn't really matter. Again, this is only compile tested, since the goal right now is to find the most acceptable high level design. Luca Barbieri (3): gallium: add resource normalization flags (v4) gallium: use unnormalized coords internally if the driver asks for them (v6) st/mesa: set PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS for GL_TEXTURE_RECTANGLE (v3) src/gallium/auxiliary/util/u_blit.c| 55 ++-- src/gallium/auxiliary/util/u_blitter.c | 48 +--- src/gallium/include/pipe/p_defines.h | 54 +++ src/mesa/state_tracker/st_atom_pixeltransfer.c |2 +- src/mesa/state_tracker/st_cb_bitmap.c | 25 +++ src/mesa/state_tracker/st_cb_drawpixels.c | 34 ++ src/mesa/state_tracker/st_cb_texture.c | 17 ++- src/mesa/state_tracker/st_context.h|2 +- src/mesa/state_tracker/st_gen_mipmap.c |3 +- src/mesa/state_tracker/st_texture.c|5 +- src/mesa/state_tracker/st_texture.h|3 +- 11 files changed, 170 insertions(+), 78 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallium: add resource normalization flags (v4)
Changes in v4:
- Use a single flag for state tracker -> driver like in v1, but with
a better name and separated from the other flags
- Fully clarify semantics of that flag
Changes in v3:
- Rework to use multiple flags
Changes in v2:
- Add a much longer and better comment
This allows:
1. The state tracker to tell the driver which normalizations it needs
2. The driver to tell the state tracker which normalization it prefers
---
src/gallium/include/pipe/p_defines.h | 55 ++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 00aa207..9625d52 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -313,6 +313,61 @@ enum pipe_transfer_usage {
/* Flags for the driver about resource behaviour:
*/
#define PIPE_RESOURCE_FLAG_GEN_MIPS(1 << 0) /* Driver performs autogen
mips */
+
+/*
+ * PIPE_CAP_FLEXIBLE_SAMPLING is a fictitious cap that doesn't currently
+ * exist, but will be supported by OpenCL-capable cards.
+ *
+ * If PIPE_CAP_FLEXIBLE_SAMPLING is supported:
+ * - PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS is ignored
+ * - if PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS is set by the driver,
+ * should use unnormalized coordinates, but can use normalized too
+ * - If PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS is set by the driver,
+ * should use normalized coordinates, but can use unnormalized too
+ * - Otherwise, can use any normalization indifferently
+
+ * If PIPE_CAP_FLEXIBLE_SAMPLING is not set
+ *and PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS is set:
+ * - last_level must be 0
+ * - Must use a clamp wrap mode
+ * - if PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS is set by the driver,.
+ * should use normalized coordinates, but can use unnormalized too
+ * - if PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS is set by the driver
+ * must use unnormalized coordinates
+ * - Otherwise, can use any normalization indifferently
+
+ * If PIPE_CAP_FLEXIBLE_SAMPLING is not set
+ *and PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS is not set:
+ * - If NPOT and PIPE_CAP_NPOT_TEXTURES is not supported,
+ * last_level must be 0
+ * - If using unnormalized coordinates or
+ *if NPOT and PIPE_CAP_NPOT_TEXTURES is not supported
+ * Must use a clamp wrap mode
+ * - if PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS is set by the driver,.
+ * must use normalized coordinates
+ * - if PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS is set by the driver
+ *and NPOT and PIPE_CAP_NPOT_TEXTURES is not supported,
+ * must use unnormalized coordinates
+ - if PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS is set by the driver
+ *and POT or PIPE_CAP_NPOT_TEXTURES is supported,
+ * should use unnormalized coordinates, but can use normalized too
+ * - Otherwise, can use any normalization indifferently
+ */
+#define PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS (1 << 1)
+
+/* State trackers must not set these flags.
+ *
+ * Drivers should set these flags to inform the state tracker of the
normalization
+ * it should use in internal drawing code, if they prefer any.
+ *
+ * Drivers who need to always have the same normalization used for a given
+ * resource must set either flag depending on whether
+ * PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS has been specified by the
+ * driver
+ */
+#define PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS (1 << 2)
+#define PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS (1 << 3)
+
#define PIPE_RESOURCE_FLAG_DRV_PRIV(1 << 16) /* driver/winsys private */
#define PIPE_RESOURCE_FLAG_ST_PRIV (1 << 24) /* state-tracker/winsys
private */
--
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] gallium: use unnormalized coords internally if the driver asks for them (v6)
Changes in v6:
- Remove hunks about bind flags
Changes in v5:
- Use the new flags
Changes in v4:
- Modify st_Bitmap to use unnormalized coordinates if the driver wants it to
Changes in v3:
- Updated comment
Changes in v2:
- u_blit no longer sets the unnormalized hint flag for NPOT textures:
the driver should do that if it wants to
Currently Gallium internals always use normalized coordinates to
access textures.
However, for NPOT textures on hardware without ARB_texture_non_power_of_two
support (e.g. nv30) this can trigger a software fallback or even not be
supported at all.
Hence, this change adds support for both kinds of normalization, depending
on what the driver asks.
---
src/gallium/auxiliary/util/u_blit.c | 55 +---
src/gallium/auxiliary/util/u_blitter.c| 48 -
src/mesa/state_tracker/st_cb_bitmap.c | 21 +++
src/mesa/state_tracker/st_cb_drawpixels.c | 34 +++---
src/mesa/state_tracker/st_context.h |2 +-
5 files changed, 92 insertions(+), 68 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blit.c
b/src/gallium/auxiliary/util/u_blit.c
index 97fa99e..abd9e69 100644
--- a/src/gallium/auxiliary/util/u_blit.c
+++ b/src/gallium/auxiliary/util/u_blit.c
@@ -110,7 +110,6 @@ util_create_blit(struct pipe_context *pipe, struct
cso_context *cso)
ctx->sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NONE;
ctx->sampler.min_img_filter = 0; /* set later */
ctx->sampler.mag_img_filter = 0; /* set later */
- ctx->sampler.normalized_coords = 1;
/* vertex elements state */
memset(&ctx->velem[0], 0, sizeof(ctx->velem[0]) * 2);
@@ -296,6 +295,7 @@ util_blit_pixels_writemask(struct blit_state *ctx,
unsigned offset;
boolean overlap;
float s0, t0, s1, t1;
+ boolean normalized;
assert(filter == PIPE_TEX_MIPFILTER_NEAREST ||
filter == PIPE_TEX_MIPFILTER_LINEAR);
@@ -335,7 +335,6 @@ util_blit_pixels_writemask(struct blit_state *ctx,
return;
}
-
/* Create a temporary texture when src and dest alias or when src
* is anything other than a 2d texture.
* XXX should just use appropriate shader to access 1d / 3d slice / cube
face,
@@ -392,10 +391,19 @@ util_blit_pixels_writemask(struct blit_state *ctx,
src_tex, srcsub, srcLeft, srcTop, srcZ0, /*
src */
srcW, srcH); /* size */
- s0 = 0.0f;
- s1 = 1.0f;
- t0 = 0.0f;
- t1 = 1.0f;
+ normalized = !(tex->flags &
PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS);
+ if(normalized) {
+ s0 = 0.0f;
+ s1 = 1.0f;
+ t0 = 0.0f;
+ t1 = 1.0f;
+ }
+ else {
+ s0 = 0;
+ s1 = srcW;
+ t0 = 0;
+ t1 = srcH;
+ }
u_sampler_view_default_template(&sv_templ, tex, tex->format);
sampler_view = pipe->create_sampler_view(pipe, tex, &sv_templ);
@@ -415,10 +423,18 @@ util_blit_pixels_writemask(struct blit_state *ctx,
return;
}
- s0 = srcX0 / (float)(u_minify(sampler_view->texture->width0,
srcsub.level));
- s1 = srcX1 / (float)(u_minify(sampler_view->texture->width0,
srcsub.level));
- t0 = srcY0 / (float)(u_minify(sampler_view->texture->height0,
srcsub.level));
- t1 = srcY1 / (float)(u_minify(sampler_view->texture->height0,
srcsub.level));
+ s0 = srcX0;
+ s1 = srcX1;
+ t0 = srcY0;
+ t1 = srcY1;
+ normalized = !!(sampler_view->texture->flags &
PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS);
+ if(normalized)
+ {
+ s0 /= (float)(u_minify(sampler_view->texture->width0, srcsub.level));
+ s1 /= (float)(u_minify(sampler_view->texture->width0, srcsub.level));
+ t0 /= (float)(u_minify(sampler_view->texture->height0, srcsub.level));
+ t1 /= (float)(u_minify(sampler_view->texture->height0, srcsub.level));
+ }
}
@@ -450,6 +466,7 @@ util_blit_pixels_writemask(struct blit_state *ctx,
cso_set_vertex_elements(ctx->cso, 2, ctx->velem);
/* sampler */
+ ctx->sampler.normalized_coords = normalized;
ctx->sampler.min_img_filter = filter;
ctx->sampler.mag_img_filter = filter;
/* we've limited this already with the sampler view but you never know... */
@@ -574,6 +591,7 @@ util_blit_pixels_tex(struct blit_state *ctx,
int dstX1, int dstY1,
float z, uint filter)
{
+ boolean normalized = !!(src_sampler_view->texture->flags &
PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS);
struct pipe_framebuffer_state fb;
float s0, t0, s1, t1;
unsigned offset;
@@ -586,10 +604,18 @@ util_blit_pixels_tex(struct blit_state *ctx,
assert(tex->width0 != 0);
assert(tex->height0 != 0);
- s0 = srcX0 / (float)tex->width0;
- s1 = srcX1 / (float)tex->width0;
- t0 = srcY0 / (float)tex->height0;
- t1 = srcY1 / (float)tex->height0;
+ s0 = srcX0;
+ s1 = srcX1;
+ t0 = s
[Mesa-dev] [PATCH 3/3] st/mesa: set PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS for GL_TEXTURE_RECTANGLE (v3)
Changes in v3:
- Renamed flag from PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT
Changes in v2:
- No longer set the flag in compress_with_blit depending on NPOT, let the
driver do that if needed
Allow to pass flags to st_texture_create and take advantage of that
to tell the pipe driver that a texture is going to be used with unnormalized
coordinates.
This is useful for hardware with no mipmapped NPOT support that needs to
allocate texture rectangles in a special way (e.g. nv30).
---
src/mesa/state_tracker/st_atom_pixeltransfer.c |2 +-
src/mesa/state_tracker/st_cb_bitmap.c |4 ++--
src/mesa/state_tracker/st_cb_drawpixels.c |2 +-
src/mesa/state_tracker/st_cb_texture.c | 17 ++---
src/mesa/state_tracker/st_gen_mipmap.c |3 ++-
src/mesa/state_tracker/st_texture.c|5 +++--
src/mesa/state_tracker/st_texture.h|3 ++-
7 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c
b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index 8a8d175..449847c 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -128,7 +128,7 @@ create_color_map_texture(GLcontext *ctx)
/* create texture for color map/table */
pt = st_texture_create(st, PIPE_TEXTURE_2D, format, 0,
- texSize, texSize, 1, PIPE_BIND_SAMPLER_VIEW);
+ texSize, texSize, 1, PIPE_BIND_SAMPLER_VIEW, 0);
return pt;
}
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index f3e2230..df74741 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -277,7 +277,7 @@ make_bitmap_texture(GLcontext *ctx, GLsizei width, GLsizei
height,
*/
pt = st_texture_create(st, PIPE_TEXTURE_2D, st->bitmap.tex_format,
0, width, height, 1,
- PIPE_BIND_SAMPLER_VIEW);
+ PIPE_BIND_SAMPLER_VIEW, 0);
if (!pt) {
_mesa_unmap_pbo_source(ctx, unpack);
return NULL;
@@ -550,7 +550,7 @@ reset_cache(struct st_context *st)
st->bitmap.tex_format, 0,
BITMAP_CACHE_WIDTH, BITMAP_CACHE_HEIGHT,
1,
- PIPE_BIND_SAMPLER_VIEW);
+ PIPE_BIND_SAMPLER_VIEW, 0);
}
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index b074c13..68347c5 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -306,7 +306,7 @@ alloc_texture(struct st_context *st, GLsizei width, GLsizei
height,
struct pipe_resource *pt;
pt = st_texture_create(st, PIPE_TEXTURE_2D, texFormat, 0,
- width, height, 1, PIPE_BIND_SAMPLER_VIEW);
+ width, height, 1, PIPE_BIND_SAMPLER_VIEW, 0);
return pt;
}
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 4c3e368..2ef5451 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -265,7 +265,7 @@ guess_and_alloc_texture(struct st_context *st,
{
const GLuint dims = get_texture_dims(stObj->base.Target);
GLuint level, lastLevel, width, height, depth;
- GLuint bindings;
+ GLuint bindings, flags;
enum pipe_format fmt;
DBG("%s\n", __FUNCTION__);
@@ -343,6 +343,11 @@ guess_and_alloc_texture(struct st_context *st,
bindings = default_bindings(st, fmt);
+ flags = 0;
+
+ if(stObj->base.Target == GL_TEXTURE_RECTANGLE)
+ flags |= PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS;
+
stObj->pt = st_texture_create(st,
gl_target_to_pipe(stObj->base.Target),
fmt,
@@ -350,7 +355,8 @@ guess_and_alloc_texture(struct st_context *st,
width,
height,
depth,
- bindings);
+ bindings,
+ flags);
DBG("%s returning %d\n", __FUNCTION__, (stObj->pt != NULL));
@@ -1867,6 +1873,10 @@ st_finalize_texture(GLcontext *ctx,
*/
if (!stObj->pt) {
GLuint bindings = default_bindings(st, firstImageFormat);
+ GLuint flags = 0;
+
+ if(stObj->base.Target == GL_TEXTURE_RECTANGLE)
+ flags |= PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS;
stObj->pt = st_texture_create(st,
gl_target_to_pipe(stObj->base.Target),
@@ -1875,7 +1885,8 @@ st_finalize_texture(GLcontext *ctx,
stObj->width0,
stObj->height0,
[Mesa-dev] [Bug 29622] New: glGetUniformLocation does not work between glNewList and glEndList
https://bugs.freedesktop.org/show_bug.cgi?id=29622 Summary: glGetUniformLocation does not work between glNewList and glEndList Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: nbow...@draconx.ca Calling glGetUniformLocation between glNewList and glEndList always returns 0, even if the variable being requested does not exist in the program. Occurs with at least swrast and i965. I tested both mesa 7.8.2 and git master. Restructuring the program so that the glGetUniformLocation is called outside of the list makes it work. For example: glNewList(1, GL_COMPILE_AND_EXECUTE); var = glGetUniformLocation(program, "something"); /* var will now be zero, regardless of the program or "something" */ /* do other stuff */ glEndList(); -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] [PATCH 0/3] Coordinate normalization, third attempt
> Using a flag instead of a new texture target allows to avoid hundreds of > changes to existing code, and allows drivers for modern hardware to > just ignore this flag. I grepped a bit through the code, and a new texture target seems easier than expected: apparently there are only about 36 checks for PIPE_TEXTURE_2D (grepping for ([!=]=.*PIPE_TEXTURE_2D|PIPE_TEXTURE_2D.*[!=]=|case.*PIPE_TEXTURE_2D)). It's still going to be more intrusive than a flag that almost everything just ignores (and with much greater risk of introducing bugs), but it could perhaps be an option, if the consensus is to add a new target. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27748] MesaLib-7.8.1.zip windows compilation error
https://bugs.freedesktop.org/show_bug.cgi?id=27748 Karl Schultz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29623] New: Regression: GLSL linker aborts when linking a single vertex program containing a varying.
https://bugs.freedesktop.org/show_bug.cgi?id=29623 Summary: Regression: GLSL linker aborts when linking a single vertex program containing a varying. Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: nbow...@draconx.ca Created an attachment (id=37927) --> (https://bugs.freedesktop.org/attachment.cgi?id=37927) Test case When attempting to link a program object using a single vertex shader that has a 'varying' object, the GLSL linker instantly aborts: varycrash: program/ir_to_mesa.cpp:1467: virtual void ir_to_mesa_visitor::visit(ir_dereference_variable*): Assertion `ir->var->location != -1' failed. This is a regression from mesa 7.8, presumably due to the recent glsl2 merge. I can bisect it later if necessary. Occurs on at least swrast and i965. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29623] Regression: GLSL linker aborts when linking a single vertex program containing a varying.
https://bugs.freedesktop.org/show_bug.cgi?id=29623 Nick Bowler changed: What|Removed |Added Attachment #37927|text/x-c|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29623] Regression: GLSL linker aborts when linking a single vertex program containing a varying.
https://bugs.freedesktop.org/show_bug.cgi?id=29623 Ian Romanick changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|mesa-...@lists.freedesktop. |i...@freedesktop.org |org | --- Comment #1 from Ian Romanick 2010-08-17 14:35:11 PDT --- I add a piglit shader_runner test glsl-vs-ff-frag that reproduces this bug. I think I know what might be causing this. When linking a vertex shader and a fragment shader, all varyings that are written but not read are marked as not being varying. When there's only a vertex shader, this pass never happens. This means the linker should be modified to do at least the demoting of varyings in the VS-only case. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29431] Nurb demos fail when callists are executed.
https://bugs.freedesktop.org/show_bug.cgi?id=29431 Eric Anholt changed: What|Removed |Added Component|Drivers/DRI/i965|Mesa core AssignedTo|e...@anholt.net |mesa-...@lists.freedesktop. ||org --- Comment #2 from Eric Anholt 2010-08-17 15:01:32 PDT --- This is unlikely to be driver-specific, so reassigning to core. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600c: Handle reads from PROGRAM_OUTPUT.
---
src/mesa/drivers/dri/r600/r700_assembler.c | 25 +++--
src/mesa/drivers/dri/r600/r700_assembler.h |2 +-
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/r600/r700_assembler.c
b/src/mesa/drivers/dri/r600/r700_assembler.c
index 9c954cb..94bc261 100644
--- a/src/mesa/drivers/dri/r600/r700_assembler.c
+++ b/src/mesa/drivers/dri/r600/r700_assembler.c
@@ -1357,7 +1357,7 @@ GLboolean assemble_src(r700_AssemblerBase *pAsm,
break;
case PROGRAM_INPUT:
setaddrmode_PVSSRC(&(pAsm->S[fld].src), ADDR_ABSOLUTE);
-pAsm->S[fld].src.rtype = SRC_REG_INPUT;
+pAsm->S[fld].src.rtype = SRC_REG_GPR;
switch (pAsm->currentShaderType)
{
case SPT_FP:
@@ -1368,6 +1368,19 @@ GLboolean assemble_src(r700_AssemblerBase *pAsm,
break;
}
break;
+case PROGRAM_OUTPUT:
+setaddrmode_PVSSRC(&(pAsm->S[fld].src), ADDR_ABSOLUTE);
+pAsm->S[fld].src.rtype = SRC_REG_GPR;
+switch (pAsm->currentShaderType)
+{
+case SPT_FP:
+pAsm->S[fld].src.reg =
pAsm->uiFP_OutputMap[pILInst->SrcReg[src].Index];
+break;
+case SPT_VP:
+pAsm->S[fld].src.reg =
pAsm->ucVP_OutputMap[pILInst->SrcReg[src].Index];
+break;
+}
+break;
default:
radeon_error("Invalid source argument type : %d \n",
pILInst->SrcReg[src].File);
return GL_FALSE;
@@ -1521,7 +1534,7 @@ GLboolean tex_src(r700_AssemblerBase *pAsm)
bValidTexCoord = GL_TRUE;
pAsm->S[0].src.reg =
pAsm->ucVP_AttributeMap[pILInst->SrcReg[0].Index];
-pAsm->S[0].src.rtype = SRC_REG_INPUT;
+pAsm->S[0].src.rtype = SRC_REG_GPR;
break;
}
}
@@ -1544,7 +1557,7 @@ GLboolean tex_src(r700_AssemblerBase *pAsm)
bValidTexCoord = GL_TRUE;
pAsm->S[0].src.reg =
pAsm->uiFP_AttributeMap[pILInst->SrcReg[0].Index];
-pAsm->S[0].src.rtype = SRC_REG_INPUT;
+pAsm->S[0].src.rtype = SRC_REG_GPR;
break;
case FRAG_ATTRIB_FACE:
fprintf(stderr, "FRAG_ATTRIB_FACE unsupported\n");
@@ -1560,7 +1573,7 @@ GLboolean tex_src(r700_AssemblerBase *pAsm)
bValidTexCoord = GL_TRUE;
pAsm->S[0].src.reg =
pAsm->uiFP_AttributeMap[pILInst->SrcReg[0].Index];
-pAsm->S[0].src.rtype = SRC_REG_INPUT;
+pAsm->S[0].src.rtype = SRC_REG_GPR;
}
}
@@ -1745,7 +1758,7 @@ GLboolean assemble_alu_src(R700ALUInstruction*
alu_instruction_ptr,
else
{
if ( (pSource->rtype == SRC_REG_TEMPORARY) ||
- (pSource->rtype == SRC_REG_INPUT)
+ (pSource->rtype == SRC_REG_GPR)
)
{
src_sel = pSource->reg;
@@ -2384,7 +2397,7 @@ GLboolean assemble_alu_instruction(r700_AssemblerBase
*pAsm)
default: channel_swizzle = SQ_SEL_MASK; break;
}
if ( ((pSource[j]->rtype == SRC_REG_TEMPORARY) ||
- (pSource[j]->rtype == SRC_REG_INPUT))
+ (pSource[j]->rtype == SRC_REG_GPR))
&& (channel_swizzle <= SQ_SEL_W) )
{
chan_counter[channel_swizzle]++;
diff --git a/src/mesa/drivers/dri/r600/r700_assembler.h
b/src/mesa/drivers/dri/r600/r700_assembler.h
index dbc6cdb..ab954ec 100644
--- a/src/mesa/drivers/dri/r600/r700_assembler.h
+++ b/src/mesa/drivers/dri/r600/r700_assembler.h
@@ -108,7 +108,7 @@ typedef enum AddressMode
typedef enum SrcRegisterType
{
SRC_REG_TEMPORARY = 0,
-SRC_REG_INPUT = 1,
+SRC_REG_GPR= 1,
SRC_REG_CONSTANT = 2,
SRC_REG_ALT_TEMPORARY = 3,
SRC_REC_LITERAL= 4,
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29624] New: crash in _mesa_DeleteTextures, in _mesa_HashLookup_unlocked
https://bugs.freedesktop.org/show_bug.cgi?id=29624 Summary: crash in _mesa_DeleteTextures, in _mesa_HashLookup_unlocked Product: Mesa Version: 7.6 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: bja...@mozilla.com Hi, Please have a look at the crash that I reported there: https://bugzilla.mozilla.org/show_bug.cgi?id=588187 It has a back-trace pointing to _mesa_DeleteTextures, and inside of it, in _mesa_HashLookup_unlocked. It is looking like a linked list is expected to be null-terminated, and it crashes when some bogus node pointer is 0x10001. I tried calling glIsTexture before, just to check, and as a result, got exactly the same crash in glIsTexture. Thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29627] New: [glsl2] Matrix comparison not implemented for non-constants
https://bugs.freedesktop.org/show_bug.cgi?id=29627 Summary: [glsl2] Matrix comparison not implemented for non-constants Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: i...@freedesktop.org piglit test cases glsl-mat-from-int-ctor-* attempt to construct matrices and compare them with expected values. These tests fail seemingly because the matrix comparisons are not broken down into vector operations. This results in a assertion failure in ir_to_mesa: shader_runner: program/ir_to_mesa.cpp:727: virtual void ir_to_mesa_visitor::visit(ir_expression*): Assertion `!ir->operands[operand]->type->is_matrix()' failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 25994] [GM45][GLSL] 'return' statement in vertex shader may cause GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=25994 Eric Anholt changed: What|Removed |Added Summary|[i915][GLSL] 'return' |[GM45][GLSL] 'return' |statement in vertex shader |statement in vertex shader |may cause GPU hang |may cause GPU hang Product|DRI |Mesa Version|XOrg CVS|git Status|NEW |ASSIGNED Component|DRM/Intel |Drivers/DRI/i965 AssignedTo|i...@freedesktop.org |e...@anholt.net -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29638] New: Mesa demos fpglsl run incorrectly on glsl2 branch
https://bugs.freedesktop.org/show_bug.cgi?id=29638 Summary: Mesa demos fpglsl run incorrectly on glsl2 branch Product: Mesa Version: git Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: jinjin.w...@intel.com Created an attachment (id=37936) --> (https://bugs.freedesktop.org/attachment.cgi?id=37936) test picture on glsl2 System Environment: -- Arch: x86_64 Platform: Calpella/Piketon Libdrm: (master)2.4.21-15-gb04515c5d6c95f573457a94267b855cceb639105 Mesa:(glsl2)commit a433cd286c60eb9d4c2114f042709eda0f3de676 Xserver: (master)xorg-server-1.8.99.905-12-g8d7b7a0d71e0b89321b3341b781bc8845386def6 Cairo: (master)046b642db0782ab5e2a5c82988b21e05afe8e716 Kernel: (for-linus)9fe6206f400646a2322096b56c59891d530e8d51 Bug detailed description: - With Mesa (glsl2)commit a433cd286c60eb9d4c2114f042709eda0f3de676, Mesa demos fpglsl with tex-multi.glsl displayed differently from (master) 15a3b42e135a3a2cb463ec3cff80a55dd8528051 that not merged with glsl2.And the problem also be found in the newest master branch. Reproduce steps: 1.xinit& 2.cd /GFX/build/component/Mesa_demos/src/fpglsl 3. ./fp-tri tex-multi.glsl -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29638] Mesa demos fpglsl run incorrectly on glsl2 branch
https://bugs.freedesktop.org/show_bug.cgi?id=29638 --- Comment #1 from wang,jinjin 2010-08-17 22:41:54 PDT --- Created an attachment (id=37937) --> (https://bugs.freedesktop.org/attachment.cgi?id=37937) test picture on master not merged -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29638] [glsl2]Mesa demo fpglsl render incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=29638 wang,jinjin changed: What|Removed |Added Summary|Mesa demos fpglsl run |[glsl2]Mesa demo fpglsl |incorrectly on glsl2 branch |render incorrectly -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
