[Mesa-dev] [PATCH 3/3] i965: For color clears, only disable writes to components that exist.
The SIMD16 replicated FB write message only works if we don't need the
color calculator to mask our framebuffer writes. Previously, we bailed
on it if color_mask wasn't true, true, true, true. However, this was
needlessly strict for formats with fewer than four components - only the
components that actually exist matter.
WebGL Aquarium attempts to clear a BGRX texture with the ColorMask set
to true, true, true, false. This will work perfectly fine with the
replicated data message; we just bailed unnecessarily.
Improves performance of WebGL Aquarium on Iris Pro (at 1920x1080) by
abound 50%, and Bay Trail (at 1366x768) by over 70% (using Chrome 24).
v2: Use _mesa_format_has_color_component() to properly handle ALPHA
formats (and generally be less fragile).
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
We do support rendering to alpha formats, so the old patch was broken.
This one ought to work, and still gives the same performance improvement.
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index 3c6c57b..fd18b45 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -231,7 +231,8 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct
brw_context *brw,
* state. This is not documented.
*/
for (int i = 0; i 4; i++) {
- if (!color_mask[i]) {
+ if (_mesa_format_has_color_component(irb-mt-format, i)
+ !color_mask[i]) {
color_write_disable[i] = true;
wm_prog_key.use_simd16_replicated_data = false;
}
--
1.9.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] mesa: Skip clearing color buffers when color writes are disabled.
WebGL Aquarium in Chrome 24 actually hits this.
v2: Move to core Mesa (wisely suggested by Ian); only consider
components which actually exist.
v3: Use _mesa_format_has_color_component to determine whether components
actually exist, fixing alpha format handling.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/clear.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
Thanks for the review! You're absolutely right about ALPHA formats.
I think this version should actually work :)
diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
index 077c5fc..e2566c0 100644
--- a/src/mesa/main/clear.c
+++ b/src/mesa/main/clear.c
@@ -106,6 +106,24 @@ _mesa_ClearColorIuiEXT(GLuint r, GLuint g, GLuint b,
GLuint a)
}
+static bool
+color_buffer_writes_enabled(const struct gl_context *ctx, unsigned idx)
+{
+ struct gl_renderbuffer *rb = ctx-DrawBuffer-_ColorDrawBuffers[idx];
+ GLuint c;
+ GLubyte colorMask = 0;
+
+ if (rb) {
+ for (c = 0; c 4; c++) {
+ if (_mesa_format_has_color_component(rb-Format, c))
+colorMask |= ctx-Color.ColorMask[idx][c];
+ }
+ }
+
+ return colorMask != 0;
+}
+
+
/**
* Clear buffers.
*
@@ -181,7 +199,7 @@ _mesa_Clear( GLbitfield mask )
for (i = 0; i ctx-DrawBuffer-_NumColorDrawBuffers; i++) {
GLint buf = ctx-DrawBuffer-_ColorDrawBufferIndexes[i];
-if (buf = 0) {
+if (buf = 0 color_buffer_writes_enabled(ctx, i)) {
bufferMask |= 1 buf;
}
}
--
1.9.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa: Introduce a _mesa_format_has_color_component() helper.
When considering color write masks, we often want to know whether an
RGBA component actually contains any meaningful data. This function
provides an easy way to answer that question, and handles luminance,
intensity, and alpha formats correctly.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/formats.c | 29 +
src/mesa/main/formats.h | 4
2 files changed, 33 insertions(+)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index c3e8049..4fb1f11 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -2207,6 +2207,35 @@ _mesa_format_num_components(mesa_format format)
/**
+ * Returns true if a color format has data stored in the R/G/B/A channels,
+ * given an index from 0 to 3.
+ */
+bool
+_mesa_format_has_color_component(mesa_format format, int component)
+{
+ const struct gl_format_info *info = _mesa_get_format_info(format);
+
+ assert(info-BaseFormat != GL_DEPTH_COMPONENT
+ info-BaseFormat != GL_DEPTH_STENCIL
+ info-BaseFormat != GL_STENCIL_INDEX);
+
+ switch (component) {
+ case 0:
+ return (info-RedBits + info-IntensityBits + info-LuminanceBits) 0;
+ case 1:
+ return (info-GreenBits + info-IntensityBits + info-LuminanceBits) 0;
+ case 2:
+ return (info-BlueBits + info-IntensityBits + info-LuminanceBits) 0;
+ case 3:
+ return (info-AlphaBits + info-IntensityBits) 0;
+ default:
+ assert(!Invalid color component: must be 0..3);
+ return false;
+ }
+}
+
+
+/**
* Return number of bytes needed to store an image of the given size
* in the given format.
*/
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 3079f03..89bd021 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -34,6 +34,7 @@
#include GL/gl.h
+#include stdbool.h
#ifdef __cplusplus
@@ -474,6 +475,9 @@ _mesa_get_uncompressed_format(mesa_format format);
extern GLuint
_mesa_format_num_components(mesa_format format);
+extern bool
+_mesa_format_has_color_component(mesa_format format, int component);
+
GLboolean
_mesa_format_matches_format_and_type(mesa_format mesa_format,
GLenum format, GLenum type,
--
1.9.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Change the winsys MSAA blits from blorp to meta.
On 03/21/2014 06:27 PM, Eric Anholt wrote:
This gets us equivalent code paths on BDW and pre-BDW, except for stencil
(where we don't have MSAA stencil resolve code yet)
v2: Move the new meta code to brw_meta_updownsample.c, name it
brw_meta_updownsample(), add a comment about
intel_rb_storage_first_mt_slice(), and rename that function and move
the RB generation into it (review ideas by Ken).
v3: Fix 2 src vs dst pasteos in previous change.
---
src/mesa/drivers/dri/i965/Makefile.sources| 1 +
src/mesa/drivers/dri/i965/brw_context.h | 6 +
src/mesa/drivers/dri/i965/brw_meta_updownsample.c | 132
++
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 21 ++--
4 files changed, 152 insertions(+), 8 deletions(-)
create mode 100644 src/mesa/drivers/dri/i965/brw_meta_updownsample.c
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
b/src/mesa/drivers/dri/i965/Makefile.sources
index 1649369..dfb88e2 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -74,6 +74,7 @@ i965_FILES = \
brw_interpolation_map.c \
brw_lower_texture_gradients.cpp \
brw_lower_unnormalized_offset.cpp \
+ brw_meta_updownsample.c \
brw_misc_state.c \
brw_object_purgeable.c \
brw_performance_monitor.c \
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 32fc38b..04af5d0 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1484,6 +1484,12 @@ GLboolean brwCreateContext(gl_api api,
/*==
* brw_misc_state.c
*/
+void brw_meta_updownsample(struct brw_context *brw,
+ struct intel_mipmap_tree *src,
+ struct intel_mipmap_tree *dst);
+/*==
+ * brw_misc_state.c
+ */
void brw_get_depthstencil_tile_masks(struct intel_mipmap_tree *depth_mt,
uint32_t depth_level,
uint32_t depth_layer,
diff --git a/src/mesa/drivers/dri/i965/brw_meta_updownsample.c
b/src/mesa/drivers/dri/i965/brw_meta_updownsample.c
new file mode 100644
index 000..de25bf4
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_meta_updownsample.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include brw_context.h
+#include intel_batchbuffer.h
+#include intel_fbo.h
+
+#include main/blit.h
+#include main/buffers.h
+#include main/fbobject.h
+
+#include drivers/common/meta.h
+
+/**
+ * @file brw_meta_updownsample.c
+ *
+ * Implements upsampling and downsampling of miptrees for window system
+ * framebuffers.
+ */
+
+/**
+ * Creates a new named renderbuffer that wraps the first slice
+ * of an existing miptree.
+ *
+ * Clobbers the current renderbuffer binding (ctx-CurrentRenderbuffer).
+ */
+static GLuint
+brw_get_rb_for_first_slice(struct brw_context *brw, struct intel_mipmap_tree
*mt)
+{
+ struct gl_context *ctx = brw-ctx;
+ GLuint rbo;
+ struct gl_renderbuffer *rb;
+ struct intel_renderbuffer *irb;
+
+ /* This turns the GenRenderbuffers name into an actual struct
+* intel_renderbuffer.
+*/
+ _mesa_GenRenderbuffers(1, rbo);
+ _mesa_BindRenderbuffer(GL_RENDERBUFFER, rbo);
+
+ rb = ctx-CurrentRenderbuffer;
+ irb = intel_renderbuffer(rb);
+
+ rb-Format = mt-format;
+ rb-_BaseFormat = _mesa_base_fbo_format(ctx, mt-format);
+
+ rb-NumSamples = mt-num_samples;
+ rb-Width = mt-logical_width0;
+ rb-Height = mt-logical_height0;
+
+ intel_miptree_reference(irb-mt, mt);
+
+ return rbo;
+}
+
Re: [Mesa-dev] [PATCH 1/4] i965: Add an env var for forcing window system MSAA.
On 03/21/2014 05:45 PM, Eric Anholt wrote:
Sometimes it would be nice to benchmark some app with MSAA versus not, but
it doesn't offer the controls you want. Just provide a handy knob to
force the issue.
---
src/mesa/drivers/dri/i965/intel_screen.c | 15 +++
src/mesa/drivers/dri/i965/intel_screen.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 4e9a775..0788a1b 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -975,6 +975,11 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
_mesa_initialize_window_framebuffer(fb, mesaVis);
+ if (screen-winsys_msaa_samples_override != -1) {
+ num_samples = screen-winsys_msaa_samples_override;
+ fb-Visual.samples = num_samples;
+ }
+
if (mesaVis-redBits == 5)
rgbFormat = MESA_FORMAT_B5G6R5_UNORM;
else if (mesaVis-sRGBCapable)
@@ -1335,6 +1340,16 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
intelScreen-hw_has_swizzling = intel_detect_swizzling(intelScreen);
+ const char *force_msaa = getenv(INTEL_FORCE_MSAA);
+ if (force_msaa) {
+ intelScreen-winsys_msaa_samples_override =
+ intel_quantize_num_samples(intelScreen, atoi(force_msaa));
+ printf(Forcing winsys sample count to %d\n,
+ intelScreen-winsys_msaa_samples_override);
+ } else {
+ intelScreen-winsys_msaa_samples_override = -1;
+ }
+
set_max_gl_versions(intelScreen);
/* Notification of GPU resets requires hardware contexts and a kernel new
diff --git a/src/mesa/drivers/dri/i965/intel_screen.h
b/src/mesa/drivers/dri/i965/intel_screen.h
index 0969021..945f6f5 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -62,6 +62,8 @@ struct intel_screen
*/
unsigned program_id;
+ int winsys_msaa_samples_override;
+
struct {
struct ra_regs *regs;
These four are:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] Native GBM backends and map/unmap support
On 03/17/2014 11:05 AM, Jammy Zhou wrote: Hi Ander, Some comments inline. And I have some further thinking about current GBM support, which is tied to specific implementation closely, although the GBM APIs are quite independent from mesa. I have some idea below to make GBM a generic solution. I'm not sure if anybody else in the community raised this before. What's your opinion? Even though the APIs are independent from mesa, they were designed with the idea that GBM would be bundled with an EGL implementation. The logic for allocating buffers for a gbm_surface is in the EGL platform by the design. If GBM were to be split, that API would have to be changed, but in a way that would still let the EGL platform to be in control of the buffer allocation for surfaces. - Decouple the GBM main library as standard API from mesa, and a separate repository can be maintained for this library, which defines callbacks for backend to implement. It can be packaged separately from mesa by distros. - Build the DRI backend as a separate library (i.e, gbm_dri.so) just as the gallium backend, and it should still be part of mesa. - New native backend can be implemented (i.e, gbm_intel.so), and the GBM backend can be specified in some configuration file (i.e, /etc/gbm.conf) if several backends can be used. Choosing the backend automatically would be better, but otherwise that would be a reasonable approach if a split were to be made. 2014-03-13 22:02 GMT+08:00 Ander Conselvan de Oliveira conselv...@gmail.com mailto:conselv...@gmail.com: From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com mailto:ander.conselvan.de.olive...@intel.com Hi, This patch series implements an API for mapping an unapping GBM buffer objects. The native intel backend was implemented so that the map and unmap functionality wouldn't have to be implemented in the DRI image Can you elaborate more about why the map/unmap functionality cannot be implemented in the DRI image extension? There is no technical limitation, but that functionality falls out of the scope of the extension, which is to allow the implementation of EGLimage and associated extensions and some level of buffer sharing. It has grown quite a bit lately and, IMHO, a bit out of control too. extension. A new EGL platform is necessary, since platform_drm.c assumes it is run on top of a gbm device with the dri backend. The new gbm platform is quite similar as the existing drm platform, why not improve the drm platform to satisfy the new requirements? For example, some abstraction can be done to decouple gbm_dri backend dependency. My approach was to duplicate first. You're right that there are code we can share between them, but I rather try to find the proper abstraction later and leave this out of the way for now. Thanks, Ander This new platform is written so that it could support other native backends, not only intel. Comments are really welcome. Thanks, Ander Ander Conselvan de Oliveira (8): egl/drm: Rename dri2_egl_surface field gbm_surf to gbm_dri_surf egl: Protect use of gbm_dri with ifdef HAVE_DRM_PLATFORM gbm: Add a native intel backend gbm_drm: Keep a reference to drm native objects dri, i965: Add an extension for sharing the drm bufmgr dri, i965: Add entry point for creating image from native handle egl/dri: Add gbm platform gbm: Add entry points for mapping and unmapping bos configure.ac http://configure.ac | 7 +- include/GL/internal/dri_interface.h | 24 +- src/egl/drivers/dri2/Makefile.am | 5 + src/egl/drivers/dri2/egl_dri2.c | 8 + src/egl/drivers/dri2/egl_dri2.h | 16 +- src/egl/drivers/dri2/platform_drm.c | 6 +- src/egl/drivers/dri2/platform_gbm.c | 486 ++ src/egl/main/Makefile.am | 5 + src/egl/main/egldisplay.c | 3 +- src/egl/main/egldisplay.h | 1 + src/gbm/Makefile.am | 14 +- src/gbm/backends/dri/gbm_dri.c| 3 + src/gbm/backends/intel/gbm_intel.c| 270 + src/gbm/backends/intel/gbm_intel.h| 76 + src/gbm/main/backend.c| 2 + src/gbm/main/common_drm.h | 13 + src/gbm/main/gbm.c| 25 ++ src/gbm/main/gbm.h| 10 + src/gbm/main/gbmint.h | 4 + src/mesa/drivers/dri/common/dri_util.c| 2 + src/mesa/drivers/dri/common/dri_util.h| 1 + src/mesa/drivers/dri/i965/intel_regions.c | 50 +-- src/mesa/drivers/dri/i965/intel_regions.h | 6 + src/mesa/drivers/dri/i965/intel_screen.c | 46 ++- 24 files changed, 1044
[Mesa-dev] [PATCH 3/3] st/mesa: Revert use pipe_sampler_view_release()
From: Christian König christian.koe...@amd.com
The original problem is fixed by now and unconditionally
destroying the sampler view, which is possible still
referenced elsewhere, is a really bad idea also.
This reverts commit 670be71bd801fea876f7512865ed5f54340da9be.
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 2826d12..eaa43d5 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -262,7 +262,7 @@ update_single_texture(struct st_context *st,
stObj-base.DepthMode) ||
(view_format != stObj-sampler_view-format) ||
stObj-base.BaseLevel != stObj-sampler_view-u.tex.first_level) {
-pipe_sampler_view_release(pipe, stObj-sampler_view);
+pipe_sampler_view_reference(stObj-sampler_view, NULL);
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] st/mesa: fix sampler view handling with shared textures v2
From: Christian König christian.koe...@amd.com
Release the references to the sampler views before
destroying the pipe context.
v2: remove TODO and unrelated change
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom.h | 2 ++
src/mesa/state_tracker/st_atom_texture.c | 8
src/mesa/state_tracker/st_context.c | 10 ++
3 files changed, 20 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom.h b/src/mesa/state_tracker/st_atom.h
index 60d89d7..394c6ad 100644
--- a/src/mesa/state_tracker/st_atom.h
+++ b/src/mesa/state_tracker/st_atom.h
@@ -45,6 +45,8 @@ void st_destroy_atoms( struct st_context *st );
void st_validate_state( struct st_context *st );
+void st_atom_texture_cleanup( struct st_context *st,
+ struct gl_texture_object *texObj );
extern const struct st_tracked_state st_update_array;
extern const struct st_tracked_state st_update_framebuffer;
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index dc7f635..2826d12 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -373,6 +373,14 @@ update_geometry_textures(struct st_context *st)
}
}
+void st_atom_texture_cleanup(struct st_context *st,
+ struct gl_texture_object *texObj)
+{
+ struct st_texture_object *stObj = st_texture_object(texObj);
+
+ if (stObj-sampler_view stObj-sampler_view-context == st-pipe)
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+}
const struct st_tracked_state st_update_fragment_texture = {
st_update_texture,/* name */
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index 0ffc762..816a095 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -33,6 +33,7 @@
#include main/shaderobj.h
#include main/version.h
#include main/vtxfmt.h
+#include main/hash.h
#include program/prog_cache.h
#include vbo/vbo.h
#include glapi/glapi.h
@@ -280,6 +281,13 @@ static void st_destroy_context_priv( struct st_context *st
)
free( st );
}
+static void st_destroy_tex_sampler( GLuint id, void *data, void *userData )
+{
+ struct gl_texture_object *texObj = (struct gl_texture_object *) data;
+ struct st_context *st = (struct st_context *) userData;
+
+ st_atom_texture_cleanup(st, texObj);
+}
void st_destroy_context( struct st_context *st )
{
@@ -288,6 +296,8 @@ void st_destroy_context( struct st_context *st )
struct gl_context *ctx = st-ctx;
GLuint i;
+ _mesa_HashWalk(ctx-Shared-TexObjects, st_destroy_tex_sampler, st);
+
/* need to unbind and destroy CSO objects before anything else */
cso_release_all(st-cso_context);
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] st/mesa: recreate sampler view on context change v2
From: Christian König christian.koe...@amd.com
With shared glx contexts it is possible that a texture is create and used
in one context and then used in another one resulting in incorrect
sampler view usage.
v2: avoid template copy
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_texture.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 3557a3f..dc7f635 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -198,6 +198,13 @@ st_get_texture_sampler_view_from_stobj(struct
st_texture_object *stObj,
if (!stObj-sampler_view) {
stObj-sampler_view =
st_create_texture_sampler_view_from_stobj(pipe, stObj, samp, format);
+
+ } else if (stObj-sampler_view-context != pipe) {
+ /* Recreate view in correct context, use existing view as template */
+ struct pipe_sampler_view *sv =
+ pipe-create_sampler_view(pipe, stObj-pt, stObj-sampler_view);
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+ stObj-sampler_view = sv;
}
return stObj-sampler_view;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PIGLIT,radeonsi] crash in spec/glsl-1.50/execution/geometry/max-input-components – who's bug is it?
On 03/22/2014 01:53 PM, Kai Wasserbäch wrote: Dear Mesa devs, I'm not sure whether this is a bug in Mesa, LLVM or in eglibc. The crash happens in _int_malloc, but since that is certainly one of the more often used functions, I'm not yet convinced, the fault lies indeed with eglibc. Therefore I'm attaching the full backtrace of the crash in spec/glsl-1.50/execution/geometry/max-input-components (it takes a very long time until the crash actually happens, Piglit recorded an execution time of 1538.0506579875946) and hope you can point me to the right bug tracker. I'm unable to tell, whether this is a regression or not, since today was the first time I was able to run a full Piglit quick test, without crashing my X on this machine with the radeonsi. My graphics stack is: GPU: PITCAIRN (ChipID = 0x6819) Linux: 3.13.6 libdrm: 2.4.52-1 LLVM: SVN:trunk/r204517 libclc: Git:master/1e278a7b04 Mesa: Git:master/4c79f088c0 GLAMOR: Git:master/a4fbc7732a (Standalone) DDX: Git:master/ea6d0affe5 X: 1.15.0-2 Let me know if you need further information. While it would take even longer, running with valgrind might help to isolate the location of a memory error. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 1/5] i965: Add writes_accumulator flag
I think I would need some hints here, I don't know how to test my
changes now properly.
On Sat, Mar 22, 2014 at 8:26 AM, Matt Turner matts...@gmail.com wrote:
On Fri, Mar 21, 2014 at 11:17 PM, Matt Turner matts...@gmail.com wrote:
On Fri, Mar 21, 2014 at 7:33 AM, Juha-Pekka Heikkila
juhapekka.heikk...@gmail.com wrote:
Our hardware has an accumulator register, which can be used to store
intermediate results across multiple instructions. Many instructions
can implicitly write a value to the accumulator in addition to their
normal destination register. This is enabled by the AccWrEn flag.
This patch introduces a new flag, inst-writes_accumulator, which
allows us to express the AccWrEn notion in the IR. It also creates a
n ALU2_ACC macro to easily define emitters for instructions that
implicitly write the accumulator.
Previously, we only supported implicit accumulator writes from the
ADDC, SUBB, and MACH instructions. We always enabled them on those
instructions, and left them disabled for other instructions.
To take advantage of the MAC (multiply-accumulate) instruction, we
need to be able to set AccWrEn on other types of instructions.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 34
+++-
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 7 +
src/mesa/drivers/dri/i965/brw_shader.cpp | 3 +++
src/mesa/drivers/dri/i965/brw_shader.h | 1 +
src/mesa/drivers/dri/i965/brw_vec4.cpp | 15 +--
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 7 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 21 +++
7 files changed, 39 insertions(+), 49 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 27cf0f6..107d9e6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -64,6 +64,8 @@ fs_inst::init()
/* This will be the case for almost all instructions. */
this-regs_written = 1;
+
+ this-writes_accumulator = false;
}
fs_inst::fs_inst()
@@ -151,6 +153,15 @@ fs_inst::fs_inst(enum opcode opcode, fs_reg dst,
return new(mem_ctx) fs_inst(BRW_OPCODE_##op, dst, src0, src1);\
}
+#define ALU2_ACC(op)\
+ fs_inst *\
+ fs_visitor::op(fs_reg dst, fs_reg src0, fs_reg src1) \
+ {\
+ fs_inst *inst = new(mem_ctx) fs_inst(BRW_OPCODE_##op, dst, src0,
src1);\
+ inst-writes_accumulator = true; \
+ return inst; \
+ }
+
#define ALU3(op)\
fs_inst *\
fs_visitor::op(fs_reg dst, fs_reg src0, fs_reg src1, fs_reg src2)\
@@ -166,7 +177,7 @@ ALU1(RNDE)
ALU1(RNDZ)
ALU2(ADD)
ALU2(MUL)
-ALU2(MACH)
+ALU2_ACC(MACH)
ALU2(AND)
ALU2(OR)
ALU2(XOR)
@@ -182,8 +193,8 @@ ALU1(FBH)
ALU1(FBL)
ALU1(CBIT)
ALU3(MAD)
-ALU2(ADDC)
-ALU2(SUBB)
+ALU2_ACC(ADDC)
+ALU2_ACC(SUBB)
ALU2(SEL)
/** Gen4 predicated IF. */
@@ -2103,21 +2114,8 @@ fs_visitor::dead_code_eliminate()
}
if (dead) {
-/* Don't dead code eliminate instructions that write to the
- * accumulator as a side-effect. Instead just set the
destination
- * to the null register to free it.
- */
-switch (inst-opcode) {
-case BRW_OPCODE_ADDC:
-case BRW_OPCODE_SUBB:
-case BRW_OPCODE_MACH:
- inst-dst = fs_reg(retype(brw_null_reg(), inst-dst.type));
- break;
-default:
- inst-remove();
- progress = true;
- break;
-}
+inst-remove();
+progress = true;
I think you meant something like
if (inst-writes_accumulator) {
inst-dst = fs_reg(retype(brw_null_reg(), inst-dst.type));
} else {
inst-remove();
}
progress = true;
rather than removing instructions that implicitly wrote the
accumulator when their destination was dead.
I did take the entire switch/case block out because it seemed of very
little use and possibly more harmful than useful. I was trying to see
when the switch case I took out was used for ADDC/SUBB/MACH but it
seemed to execute close to never on running piglit glsl tests.
Reason that part being skipped is when ADDC/SUBB opcodes are used the
destination register is set to dst_null_ud() before arriving here,
similar is almost always true for MACH. I did go checking and found
null register is not grf but considered arf which is internally
enumerated to
Re: [Mesa-dev] [PATCH] haiku: Fix build through scons corrections and viewport fixes
On 03/22/2014 04:58 PM, Alexander von Gluck IV wrote:
* Add HAVE_PTHREAD, we do have pthread support wrappers now for
non-native Haiku threaded applications.
* Viewport changed behavior recently breaking the build.
We fix this by looking at the gl_context ViewportArray
(Thanks Brian for the idea)
---
scons/gallium.py |5 +
.../targets/haiku-softpipe/GalliumContext.cpp | 12 +---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/scons/gallium.py b/scons/gallium.py
index f505a62..e11d4db 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -269,6 +269,11 @@ def generate(env):
cppdefines += ['HAVE_ALIAS']
else:
cppdefines += ['GLX_ALIAS_UNSUPPORTED']
+if env['platform'] == 'haiku':
+cppdefines += [
+'HAVE_PTHREAD',
+'HAVE_POSIX_MEMALIGN'
+]
if platform == 'windows':
cppdefines += [
'WIN32',
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
index 1078cb7..52cd764 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
@@ -44,9 +44,15 @@ extern C {
static void
-hgl_viewport(struct gl_context* glContext, GLint x, GLint y,
- GLsizei width, GLsizei height)
+hgl_viewport(struct gl_context* glContext)
{
+ // TODO: We should try to eliminate this function
+
+ GLint x = glContext-ViewportArray[0].X;
+ GLint y = glContext-ViewportArray[0].Y;
+ GLint width = glContext-ViewportArray[0].Width;
+ GLint height = glContext-ViewportArray[0].Height;
+
TRACE(%s(glContext: %p, x: %d, y: %d, w: %d, h: %d\n, __func__,
glContext, x, y, width, height);
@@ -525,7 +531,7 @@ GalliumContext::ResizeViewport(int32 width, int32 height)
for (context_id i = 0; i CONTEXT_MAX; i++) {
if (fContext[i] fContext[i]-st) {
struct st_context *stContext = (struct
st_context*)fContext[i]-st;
- _mesa_set_viewport(stContext-ctx, 0, 0, width, height);
+ _mesa_set_viewport(stContext-ctx, 0, 0, 0, width,
height);
st_manager_validate_framebuffers(stContext);
}
}
Acked-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix format matching checks for GL_INTENSITY* internalformats.
On 03/23/2014 03:07 AM, Chris Forbes wrote: GL_INTENSITY has never been valid as a pixel format -- to get the memcpy pack/unpack paths, the app needs to specify GL_RED as the pixel format (or GL_RED_INTEGER for the integer formats). Signed-off-by: Chris Forbes chr...@ijw.co.nz --- src/mesa/main/formats.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Generate FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT earlier
On 03/23/2014 03:41 AM, Chris Forbes wrote: The ARB_framebuffer_object spec lists this case before the FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER and FRAMEBUFFER_INCOMPLETE_READ_BUFFER cases. Fixes two broken cases in piglit's fbo-incomplete test, if ARB_ES2_compatibility is not advertised. (If it is, this is masked because the FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER / FRAMEBUFFER_INCOMPLETE_READ_BUFFER cases are removed by that extension) Signed-off-by: Chris Forbes chr...@ijw.co.nz --- src/mesa/main/fbobject.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 76530] account request
https://bugs.freedesktop.org/show_bug.cgi?id=76530 Brian Paul bri...@vmware.com changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org Product|Mesa|freedesktop.org Component|Other |New Accounts --- Comment #2 from Brian Paul bri...@vmware.com --- Reassigning to the admins. -- 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/3] mesa: Introduce a _mesa_format_has_color_component() helper.
On 03/24/2014 02:52 AM, Kenneth Graunke wrote:
When considering color write masks, we often want to know whether an
RGBA component actually contains any meaningful data. This function
provides an easy way to answer that question, and handles luminance,
intensity, and alpha formats correctly.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/formats.c | 29 +
src/mesa/main/formats.h | 4
2 files changed, 33 insertions(+)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index c3e8049..4fb1f11 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -2207,6 +2207,35 @@ _mesa_format_num_components(mesa_format format)
/**
+ * Returns true if a color format has data stored in the R/G/B/A channels,
+ * given an index from 0 to 3.
+ */
+bool
+_mesa_format_has_color_component(mesa_format format, int component)
+{
+ const struct gl_format_info *info = _mesa_get_format_info(format);
+
+ assert(info-BaseFormat != GL_DEPTH_COMPONENT
+ info-BaseFormat != GL_DEPTH_STENCIL
+ info-BaseFormat != GL_STENCIL_INDEX);
+
+ switch (component) {
+ case 0:
+ return (info-RedBits + info-IntensityBits + info-LuminanceBits) 0;
+ case 1:
+ return (info-GreenBits + info-IntensityBits + info-LuminanceBits) 0;
+ case 2:
+ return (info-BlueBits + info-IntensityBits + info-LuminanceBits) 0;
+ case 3:
+ return (info-AlphaBits + info-IntensityBits) 0;
+ default:
+ assert(!Invalid color component: must be 0..3);
+ return false;
+ }
+}
+
+
+/**
* Return number of bytes needed to store an image of the given size
* in the given format.
*/
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 3079f03..89bd021 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -34,6 +34,7 @@
#include GL/gl.h
+#include stdbool.h
#ifdef __cplusplus
@@ -474,6 +475,9 @@ _mesa_get_uncompressed_format(mesa_format format);
extern GLuint
_mesa_format_num_components(mesa_format format);
+extern bool
+_mesa_format_has_color_component(mesa_format format, int component);
+
GLboolean
_mesa_format_matches_format_and_type(mesa_format mesa_format,
GLenum format, GLenum type,
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] mesa: Skip clearing color buffers when color writes are disabled.
On 03/24/2014 02:52 AM, Kenneth Graunke wrote:
WebGL Aquarium in Chrome 24 actually hits this.
v2: Move to core Mesa (wisely suggested by Ian); only consider
components which actually exist.
v3: Use _mesa_format_has_color_component to determine whether components
actually exist, fixing alpha format handling.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/clear.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
Thanks for the review! You're absolutely right about ALPHA formats.
I think this version should actually work :)
diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
index 077c5fc..e2566c0 100644
--- a/src/mesa/main/clear.c
+++ b/src/mesa/main/clear.c
@@ -106,6 +106,24 @@ _mesa_ClearColorIuiEXT(GLuint r, GLuint g, GLuint b,
GLuint a)
}
+static bool
+color_buffer_writes_enabled(const struct gl_context *ctx, unsigned idx)
+{
+ struct gl_renderbuffer *rb = ctx-DrawBuffer-_ColorDrawBuffers[idx];
+ GLuint c;
+ GLubyte colorMask = 0;
+
+ if (rb) {
+ for (c = 0; c 4; c++) {
+ if (_mesa_format_has_color_component(rb-Format, c))
+colorMask |= ctx-Color.ColorMask[idx][c];
+ }
+ }
+
+ return colorMask != 0;
+}
+
+
/**
* Clear buffers.
*
@@ -181,7 +199,7 @@ _mesa_Clear( GLbitfield mask )
for (i = 0; i ctx-DrawBuffer-_NumColorDrawBuffers; i++) {
GLint buf = ctx-DrawBuffer-_ColorDrawBufferIndexes[i];
-if (buf = 0) {
+if (buf = 0 color_buffer_writes_enabled(ctx, i)) {
bufferMask |= 1 buf;
}
}
I still think a comment on the new function would be nice. Looks good
though.
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] llvmpipe: Simplify vertex and geometry shaders.
From: José Fonseca jfons...@vmware.com
Eliminate lp_vertex_shader, as it added nothing over draw_vertex_shader.
Simplify lp_geometry_shader, as most of the incoming state is unneeded.
(We could also just use draw_geometry_shader if we were willing to peek
inside the structure.)
---
src/gallium/drivers/llvmpipe/lp_context.h | 4 +--
src/gallium/drivers/llvmpipe/lp_draw_arrays.c | 8 ++---
src/gallium/drivers/llvmpipe/lp_state.h | 13 ++--
src/gallium/drivers/llvmpipe/lp_state_gs.c| 32 +++
src/gallium/drivers/llvmpipe/lp_state_vs.c| 46 +++
5 files changed, 33 insertions(+), 70 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_context.h
b/src/gallium/drivers/llvmpipe/lp_context.h
index 05cdfe5..ee8033c 100644
--- a/src/gallium/drivers/llvmpipe/lp_context.h
+++ b/src/gallium/drivers/llvmpipe/lp_context.h
@@ -46,8 +46,8 @@
struct llvmpipe_vbuf_render;
struct draw_context;
struct draw_stage;
+struct draw_vertex_shader;
struct lp_fragment_shader;
-struct lp_vertex_shader;
struct lp_blend_state;
struct lp_setup_context;
struct lp_setup_variant;
@@ -63,7 +63,7 @@ struct llvmpipe_context {
const struct pipe_depth_stencil_alpha_state *depth_stencil;
const struct pipe_rasterizer_state *rasterizer;
struct lp_fragment_shader *fs;
- const struct lp_vertex_shader *vs;
+ struct draw_vertex_shader *vs;
const struct lp_geometry_shader *gs;
const struct lp_velems_state *velems;
const struct lp_so_state *so;
diff --git a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
index 3df0a5c..99e6d19 100644
--- a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
+++ b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
@@ -112,11 +112,11 @@ llvmpipe_draw_vbo(struct pipe_context *pipe, const struct
pipe_draw_info *info)
llvmpipe_prepare_geometry_sampling(lp,
lp-num_sampler_views[PIPE_SHADER_GEOMETRY],
lp-sampler_views[PIPE_SHADER_GEOMETRY]);
- if (lp-gs !lp-gs-shader.tokens) {
+ if (lp-gs lp-gs-no_tokens) {
/* we have an empty geometry shader with stream output, so
attach the stream output info to the current vertex shader */
if (lp-vs) {
- draw_vs_attach_so(lp-vs-draw_data, lp-gs-shader.stream_output);
+ draw_vs_attach_so(lp-vs, lp-gs-stream_output);
}
}
draw_collect_pipeline_statistics(draw,
@@ -136,11 +136,11 @@ llvmpipe_draw_vbo(struct pipe_context *pipe, const struct
pipe_draw_info *info)
}
draw_set_mapped_so_targets(draw, 0, NULL);
- if (lp-gs !lp-gs-shader.tokens) {
+ if (lp-gs lp-gs-no_tokens) {
/* we have attached stream output to the vs for rendering,
now lets reset it */
if (lp-vs) {
- draw_vs_reset_so(lp-vs-draw_data);
+ draw_vs_reset_so(lp-vs);
}
}
diff --git a/src/gallium/drivers/llvmpipe/lp_state.h
b/src/gallium/drivers/llvmpipe/lp_state.h
index 8635cf1..2da6caa 100644
--- a/src/gallium/drivers/llvmpipe/lp_state.h
+++ b/src/gallium/drivers/llvmpipe/lp_state.h
@@ -65,17 +65,10 @@ struct llvmpipe_context;
-/** Subclass of pipe_shader_state */
-struct lp_vertex_shader
-{
- struct pipe_shader_state shader;
- struct draw_vertex_shader *draw_data;
-};
-
-/** Subclass of pipe_shader_state */
struct lp_geometry_shader {
- struct pipe_shader_state shader;
- struct draw_geometry_shader *draw_data;
+ boolean no_tokens;
+ struct pipe_stream_output_info stream_output;
+ struct draw_geometry_shader *dgs;
};
/** Vertex element state */
diff --git a/src/gallium/drivers/llvmpipe/lp_state_gs.c
b/src/gallium/drivers/llvmpipe/lp_state_gs.c
index 74cf992..c94afed 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_gs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_gs.c
@@ -48,7 +48,7 @@ llvmpipe_create_gs_state(struct pipe_context *pipe,
state = CALLOC_STRUCT(lp_geometry_shader);
if (state == NULL )
- goto fail;
+ goto no_state;
/* debug */
if (LP_DEBUG DEBUG_TGSI) {
@@ -57,26 +57,19 @@ llvmpipe_create_gs_state(struct pipe_context *pipe,
}
/* copy stream output info */
- state-shader = *templ;
- if (templ-tokens) {
- /* copy shader tokens, the ones passed in will go away. */
- state-shader.tokens = tgsi_dup_tokens(templ-tokens);
- if (state-shader.tokens == NULL)
- goto fail;
-
- state-draw_data = draw_create_geometry_shader(llvmpipe-draw, templ);
- if (state-draw_data == NULL)
- goto fail;
+ state-no_tokens = !templ-tokens;
+ memcpy(state-stream_output, templ-stream_output, sizeof
state-stream_output);
+
+ state-dgs = draw_create_geometry_shader(llvmpipe-draw, templ);
+ if (state-dgs == NULL) {
+ goto no_dgs;
}
return state;
-fail:
- if (state) {
- FREE( (void *)state-shader.tokens );
- FREE( state-draw_data );
- FREE( state );
-
[Mesa-dev] [PATCH 1/2] draw: Duplicate TGSI tokens in draw_pipe_pstipple module.
From: José Fonseca jfons...@vmware.com
As done in draw_pipe_aaline and draw_pipe_aapoint modules.
---
src/gallium/auxiliary/draw/draw_pipe_pstipple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index d7dcfdb..d216787 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
@@ -673,7 +673,7 @@ pstip_create_fs_state(struct pipe_context *pipe,
struct pstip_fragment_shader *pstipfs =
CALLOC_STRUCT(pstip_fragment_shader);
if (pstipfs) {
- pstipfs-state = *fs;
+ pstipfs-state.tokens = tgsi_dup_tokens(fs-tokens);
/* pass-through */
pstipfs-driver_fs = pstip-driver_create_fs_state(pstip-pipe, fs);
@@ -707,6 +707,7 @@ pstip_delete_fs_state(struct pipe_context *pipe, void *fs)
if (pstipfs-pstip_fs)
pstip-driver_delete_fs_state(pstip-pipe, pstipfs-pstip_fs);
+ FREE((void*)pstipfs-state.tokens);
FREE(pstipfs);
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 69874] Automake throws a lot of [...] option 'subdir-objects' is disabled
https://bugs.freedesktop.org/show_bug.cgi?id=69874 Fabio Pedretti fabio@libero.it changed: What|Removed |Added CC||fabio@libero.it -- 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/2] draw: Duplicate TGSI tokens in draw_pipe_pstipple module.
- Original Message -
On 03/24/2014 09:31 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
As done in draw_pipe_aaline and draw_pipe_aapoint modules.
---
src/gallium/auxiliary/draw/draw_pipe_pstipple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index d7dcfdb..d216787 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
@@ -673,7 +673,7 @@ pstip_create_fs_state(struct pipe_context *pipe,
struct pstip_fragment_shader *pstipfs =
CALLOC_STRUCT(pstip_fragment_shader);
if (pstipfs) {
- pstipfs-state = *fs;
+ pstipfs-state.tokens = tgsi_dup_tokens(fs-tokens);
/* pass-through */
pstipfs-driver_fs = pstip-driver_create_fs_state(pstip-pipe,
fs);
@@ -707,6 +707,7 @@ pstip_delete_fs_state(struct pipe_context *pipe, void
*fs)
if (pstipfs-pstip_fs)
pstip-driver_delete_fs_state(pstip-pipe, pstipfs-pstip_fs);
+ FREE((void*)pstipfs-state.tokens);
FREE(pstipfs);
}
Tag as a candidate for stable branches?
Yes, indeed.
Reviewed-by: Brian Paul bri...@vmware.com
Thanks.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] st/mesa: Revert use pipe_sampler_view_release()
On 03/24/2014 08:06 AM, Christian König wrote:
From: Christian König christian.koe...@amd.com
The original problem is fixed by now and unconditionally
destroying the sampler view, which is possible still
referenced elsewhere, is a really bad idea also.
This reverts commit 670be71bd801fea876f7512865ed5f54340da9be.
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 2826d12..eaa43d5 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -262,7 +262,7 @@ update_single_texture(struct st_context *st,
stObj-base.DepthMode) ||
(view_format != stObj-sampler_view-format) ||
stObj-base.BaseLevel != stObj-sampler_view-u.tex.first_level) {
-pipe_sampler_view_release(pipe, stObj-sampler_view);
+pipe_sampler_view_reference(stObj-sampler_view, NULL);
}
}
The pipe_sampler_view_release() obeys reference counting too so I don't
think this change is necessary.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] draw: Duplicate TGSI tokens in draw_pipe_pstipple module.
On 03/24/2014 09:31 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
As done in draw_pipe_aaline and draw_pipe_aapoint modules.
---
src/gallium/auxiliary/draw/draw_pipe_pstipple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index d7dcfdb..d216787 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
@@ -673,7 +673,7 @@ pstip_create_fs_state(struct pipe_context *pipe,
struct pstip_fragment_shader *pstipfs =
CALLOC_STRUCT(pstip_fragment_shader);
if (pstipfs) {
- pstipfs-state = *fs;
+ pstipfs-state.tokens = tgsi_dup_tokens(fs-tokens);
/* pass-through */
pstipfs-driver_fs = pstip-driver_create_fs_state(pstip-pipe, fs);
@@ -707,6 +707,7 @@ pstip_delete_fs_state(struct pipe_context *pipe, void *fs)
if (pstipfs-pstip_fs)
pstip-driver_delete_fs_state(pstip-pipe, pstipfs-pstip_fs);
+ FREE((void*)pstipfs-state.tokens);
FREE(pstipfs);
}
Tag as a candidate for stable branches?
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] st/mesa: fix sampler view handling with shared textures v2
On 03/24/2014 08:06 AM, Christian König wrote:
From: Christian König christian.koe...@amd.com
Release the references to the sampler views before
destroying the pipe context.
v2: remove TODO and unrelated change
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom.h | 2 ++
src/mesa/state_tracker/st_atom_texture.c | 8
src/mesa/state_tracker/st_context.c | 10 ++
3 files changed, 20 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom.h b/src/mesa/state_tracker/st_atom.h
index 60d89d7..394c6ad 100644
--- a/src/mesa/state_tracker/st_atom.h
+++ b/src/mesa/state_tracker/st_atom.h
@@ -45,6 +45,8 @@ void st_destroy_atoms( struct st_context *st );
void st_validate_state( struct st_context *st );
+void st_atom_texture_cleanup( struct st_context *st,
+ struct gl_texture_object *texObj );
Let's call this st_release_texture_sample_view() and put it in
st_texture.h. The function doesn't really pertain to state atoms and
seems to go along with the other texture / sampler view functions in
st_texture.h.
extern const struct st_tracked_state st_update_array;
extern const struct st_tracked_state st_update_framebuffer;
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index dc7f635..2826d12 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -373,6 +373,14 @@ update_geometry_textures(struct st_context *st)
}
}
+void st_atom_texture_cleanup(struct st_context *st,
+ struct gl_texture_object *texObj)
+{
+ struct st_texture_object *stObj = st_texture_object(texObj);
+
+ if (stObj-sampler_view stObj-sampler_view-context == st-pipe)
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+}
Move to st_texture.c
const struct st_tracked_state st_update_fragment_texture = {
st_update_texture, /* name */
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index 0ffc762..816a095 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -33,6 +33,7 @@
#include main/shaderobj.h
#include main/version.h
#include main/vtxfmt.h
+#include main/hash.h
#include program/prog_cache.h
#include vbo/vbo.h
#include glapi/glapi.h
@@ -280,6 +281,13 @@ static void st_destroy_context_priv( struct st_context *st
)
free( st );
}
+static void st_destroy_tex_sampler( GLuint id, void *data, void *userData )
I know we're not consistent about this in the state tracker, but we can
drop the st_ prefix on static functions. And I'd probably put a _cb
suffix (for callback) on the function as we do in shared.c. And put a
comment on it:
/**
* Callback to release the sampler view attached to a texture object.
* Called by _mesa_HashWalk().
*/
static void
destroy_tex_sampler_cb(GLuint id, void *data, void *userData)
+{
+ struct gl_texture_object *texObj = (struct gl_texture_object *) data;
+ struct st_context *st = (struct st_context *) userData;
+
+ st_atom_texture_cleanup(st, texObj);
+}
void st_destroy_context( struct st_context *st )
{
@@ -288,6 +296,8 @@ void st_destroy_context( struct st_context *st )
struct gl_context *ctx = st-ctx;
GLuint i;
+ _mesa_HashWalk(ctx-Shared-TexObjects, st_destroy_tex_sampler, st);
+
/* need to unbind and destroy CSO objects before anything else */
cso_release_all(st-cso_context);
Looks good otherwise.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] st/mesa: recreate sampler view on context change v2
On 03/24/2014 08:06 AM, Christian König wrote:
From: Christian König christian.koe...@amd.com
With shared glx contexts it is possible that a texture is create and used
in one context and then used in another one resulting in incorrect
sampler view usage.
v2: avoid template copy
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_texture.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 3557a3f..dc7f635 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -198,6 +198,13 @@ st_get_texture_sampler_view_from_stobj(struct
st_texture_object *stObj,
if (!stObj-sampler_view) {
stObj-sampler_view =
st_create_texture_sampler_view_from_stobj(pipe, stObj, samp, format);
+
+ } else if (stObj-sampler_view-context != pipe) {
+ /* Recreate view in correct context, use existing view as template */
+ struct pipe_sampler_view *sv =
+ pipe-create_sampler_view(pipe, stObj-pt, stObj-sampler_view);
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+ stObj-sampler_view = sv;
}
return stObj-sampler_view;
My concern with this is if there really are multiple contexts using one
texture, we're going to continuously destroy and create sampler views
when we validate state. Right?
Ultimately, the right solution might be to have a list of sampler views
per texture, one sampler view per context. Since there usually aren't
too many contexts sharing textures, a linked list would probably be OK.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] st/mesa: recreate sampler view on context change v2
Am 24.03.2014 16:36, schrieb Brian Paul:
On 03/24/2014 08:06 AM, Christian König wrote:
From: Christian König christian.koe...@amd.com
With shared glx contexts it is possible that a texture is create and
used
in one context and then used in another one resulting in incorrect
sampler view usage.
v2: avoid template copy
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_texture.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 3557a3f..dc7f635 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -198,6 +198,13 @@ st_get_texture_sampler_view_from_stobj(struct
st_texture_object *stObj,
if (!stObj-sampler_view) {
stObj-sampler_view =
st_create_texture_sampler_view_from_stobj(pipe, stObj,
samp, format);
+
+ } else if (stObj-sampler_view-context != pipe) {
+ /* Recreate view in correct context, use existing view as
template */
+ struct pipe_sampler_view *sv =
+ pipe-create_sampler_view(pipe, stObj-pt,
stObj-sampler_view);
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+ stObj-sampler_view = sv;
}
return stObj-sampler_view;
My concern with this is if there really are multiple contexts using
one texture, we're going to continuously destroy and create sampler
views when we validate state. Right?
Yes that's correct and it also concerned me as well.
Ultimately, the right solution might be to have a list of sampler
views per texture, one sampler view per context. Since there usually
aren't too many contexts sharing textures, a linked list would
probably be OK.
Completely agree, but this patchset is meant to be a bugfix for the
crashes we experience with 10.x. For master a solution with a linked
list should work better indeed.
Christian.
-Brian
___
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] [PATCH 1/3] st/mesa: recreate sampler view on context change v2
On 03/24/2014 10:04 AM, Christian König wrote:
Am 24.03.2014 16:36, schrieb Brian Paul:
On 03/24/2014 08:06 AM, Christian König wrote:
From: Christian König christian.koe...@amd.com
With shared glx contexts it is possible that a texture is create and
used
in one context and then used in another one resulting in incorrect
sampler view usage.
v2: avoid template copy
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_texture.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 3557a3f..dc7f635 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -198,6 +198,13 @@ st_get_texture_sampler_view_from_stobj(struct
st_texture_object *stObj,
if (!stObj-sampler_view) {
stObj-sampler_view =
st_create_texture_sampler_view_from_stobj(pipe, stObj,
samp, format);
+
+ } else if (stObj-sampler_view-context != pipe) {
+ /* Recreate view in correct context, use existing view as
template */
+ struct pipe_sampler_view *sv =
+ pipe-create_sampler_view(pipe, stObj-pt,
stObj-sampler_view);
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+ stObj-sampler_view = sv;
}
return stObj-sampler_view;
My concern with this is if there really are multiple contexts using
one texture, we're going to continuously destroy and create sampler
views when we validate state. Right?
Yes that's correct and it also concerned me as well.
Ultimately, the right solution might be to have a list of sampler
views per texture, one sampler view per context. Since there usually
aren't too many contexts sharing textures, a linked list would
probably be OK.
Completely agree, but this patchset is meant to be a bugfix for the
crashes we experience with 10.x. For master a solution with a linked
list should work better indeed.
OK, let's put a 'XXX' comment describing that solution in the code for now.
With that, Reviewed-by: Brian Paul bri...@vmware.com
Will you try to implement the linked list?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] st/mesa: Revert use pipe_sampler_view_release()
Am 24.03.2014 16:36, schrieb Brian Paul:
On 03/24/2014 08:06 AM, Christian König wrote:
From: Christian König christian.koe...@amd.com
The original problem is fixed by now and unconditionally
destroying the sampler view, which is possible still
referenced elsewhere, is a really bad idea also.
This reverts commit 670be71bd801fea876f7512865ed5f54340da9be.
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 2826d12..eaa43d5 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -262,7 +262,7 @@ update_single_texture(struct st_context *st,
stObj-base.DepthMode) ||
(view_format != stObj-sampler_view-format) ||
stObj-base.BaseLevel !=
stObj-sampler_view-u.tex.first_level) {
- pipe_sampler_view_release(pipe, stObj-sampler_view);
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
}
}
The pipe_sampler_view_release() obeys reference counting too so I
don't think this change is necessary.
OK, didn't know that. I changed the comment and removed the stable CC,
but I would still like to commit it to master because destroying the
sampler view in the wrong context might still cause problems.
Christian.
-Brian
___
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] [PATCH 3/3] st/mesa: Revert use pipe_sampler_view_release() v2
From: Christian König christian.koe...@amd.com
The original problem is fixed by now.
This reverts commit 670be71bd801fea876f7512865ed5f54340da9be.
v2: update patch text and remove stable CC
Signed-off-by: Christian König christian.koe...@amd.com
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index dc7f635..11da142 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -262,7 +262,7 @@ update_single_texture(struct st_context *st,
stObj-base.DepthMode) ||
(view_format != stObj-sampler_view-format) ||
stObj-base.BaseLevel != stObj-sampler_view-u.tex.first_level) {
-pipe_sampler_view_release(pipe, stObj-sampler_view);
+pipe_sampler_view_reference(stObj-sampler_view, NULL);
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] st/mesa: fix sampler view handling with shared textures v3
From: Christian König christian.koe...@amd.com
Release the references to the sampler views before
destroying the pipe context.
v2: remove TODO and unrelated change
v3: move to st_texture.[ch], rename callback, add comment
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_context.c | 16
src/mesa/state_tracker/st_texture.c | 9 +
src/mesa/state_tracker/st_texture.h | 4
3 files changed, 29 insertions(+)
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index 0ffc762..277dc42 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -33,6 +33,7 @@
#include main/shaderobj.h
#include main/version.h
#include main/vtxfmt.h
+#include main/hash.h
#include program/prog_cache.h
#include vbo/vbo.h
#include glapi/glapi.h
@@ -280,6 +281,19 @@ static void st_destroy_context_priv( struct st_context *st
)
free( st );
}
+
+/**
+ * Callback to release the sampler view attached to a texture object.
+ * Called by _mesa_HashWalk().
+ */
+static void
+destroy_tex_sampler_cb(GLuint id, void *data, void *userData)
+{
+ struct gl_texture_object *texObj = (struct gl_texture_object *) data;
+ struct st_context *st = (struct st_context *) userData;
+
+ st_atom_texture_cleanup(st, texObj);
+}
void st_destroy_context( struct st_context *st )
{
@@ -288,6 +302,8 @@ void st_destroy_context( struct st_context *st )
struct gl_context *ctx = st-ctx;
GLuint i;
+ _mesa_HashWalk(ctx-Shared-TexObjects, destroy_tex_sampler_cb, st);
+
/* need to unbind and destroy CSO objects before anything else */
cso_release_all(st-cso_context);
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index b5ccc76..db6b54e 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -412,3 +412,12 @@ st_create_color_map_texture(struct gl_context *ctx)
return pt;
}
+void
+st_release_texture_sample_view(struct st_context *st,
+ struct gl_texture_object *texObj)
+{
+ struct st_texture_object *stObj = st_texture_object(texObj);
+
+ if (stObj-sampler_view stObj-sampler_view-context == st-pipe)
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+}
diff --git a/src/mesa/state_tracker/st_texture.h
b/src/mesa/state_tracker/st_texture.h
index bce2a09..44327cd 100644
--- a/src/mesa/state_tracker/st_texture.h
+++ b/src/mesa/state_tracker/st_texture.h
@@ -227,4 +227,8 @@ st_texture_image_copy(struct pipe_context *pipe,
extern struct pipe_resource *
st_create_color_map_texture(struct gl_context *ctx);
+extern void
+st_release_texture_sample_view(struct st_context *st,
+ struct gl_texture_object *texObj);
+
#endif
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] st/mesa: recreate sampler view on context change v2
From: Christian König christian.koe...@amd.com
With shared glx contexts it is possible that a texture is create and used
in one context and then used in another one resulting in incorrect
sampler view usage.
v2: avoid template copy
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_texture.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 3557a3f..dc7f635 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -198,6 +198,13 @@ st_get_texture_sampler_view_from_stobj(struct
st_texture_object *stObj,
if (!stObj-sampler_view) {
stObj-sampler_view =
st_create_texture_sampler_view_from_stobj(pipe, stObj, samp, format);
+
+ } else if (stObj-sampler_view-context != pipe) {
+ /* Recreate view in correct context, use existing view as template */
+ struct pipe_sampler_view *sv =
+ pipe-create_sampler_view(pipe, stObj-pt, stObj-sampler_view);
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+ stObj-sampler_view = sv;
}
return stObj-sampler_view;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] st/mesa: recreate sampler view on context change v2
Am 24.03.2014 17:13, schrieb Brian Paul:
On 03/24/2014 10:04 AM, Christian König wrote:
Am 24.03.2014 16:36, schrieb Brian Paul:
On 03/24/2014 08:06 AM, Christian König wrote:
From: Christian König christian.koe...@amd.com
With shared glx contexts it is possible that a texture is create and
used
in one context and then used in another one resulting in incorrect
sampler view usage.
v2: avoid template copy
Signed-off-by: Christian König christian.koe...@amd.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_texture.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 3557a3f..dc7f635 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -198,6 +198,13 @@ st_get_texture_sampler_view_from_stobj(struct
st_texture_object *stObj,
if (!stObj-sampler_view) {
stObj-sampler_view =
st_create_texture_sampler_view_from_stobj(pipe, stObj,
samp, format);
+
+ } else if (stObj-sampler_view-context != pipe) {
+ /* Recreate view in correct context, use existing view as
template */
+ struct pipe_sampler_view *sv =
+ pipe-create_sampler_view(pipe, stObj-pt,
stObj-sampler_view);
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+ stObj-sampler_view = sv;
}
return stObj-sampler_view;
My concern with this is if there really are multiple contexts using
one texture, we're going to continuously destroy and create sampler
views when we validate state. Right?
Yes that's correct and it also concerned me as well.
Ultimately, the right solution might be to have a list of sampler
views per texture, one sampler view per context. Since there usually
aren't too many contexts sharing textures, a linked list would
probably be OK.
Completely agree, but this patchset is meant to be a bugfix for the
crashes we experience with 10.x. For master a solution with a linked
list should work better indeed.
OK, let's put a 'XXX' comment describing that solution in the code for
now.
With that, Reviewed-by: Brian Paul bri...@vmware.com
Thanks, I've added the comment and pushed the result upstream.
What about the other two patches? I would like to push at least #2 as
well, cause it is clearly a bugfix.
Will you try to implement the linked list?
Sure, shouldn't be to much of a problem.
Christian.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OpenCL/clover buffers vs images
I have been experimenting with adding image support to the clover implementation, and have been trying to understand the differences between the existing buffer support and what would be required to support images. From what I'm gathering, buffers are laid out in VRAM in a linear format, while images would be laid out in some sort of tiled format. I have been trying to do some research on tiled memory layout, and have not yet been able to find anything which describes the tiled format that is in use on R600 and Evergreen GPUs. I have also tried going through the OpenGL code to understand how image textures are transferred to the R600/Evergreen GPUs, since I am making the assumption that OpenGL would be transferring the images to GPU RAM in the same tiled format that an OpenCL texture would use. I have been trying to do some comparisons with the Catalyst driver's implementation, but I have not determined a way to view the internals of the registers and CB areas within the catalyst environment. For example, looking at the IL and ISA generated using the Catalyst SDK, I can see that there are 8 32-bit fields being read from CB1 for an read_only image kernel parameter. I have been able to determine that the first three are integer width, height, depth. The fourth is the image channel data type, the 8th is the image channel order. The 5th and 6th are involved in offset calculations for sampler coordinates (not sure if they are row and slice pitches of some sort) while the 7th seems unused (I'm assuming it must have something to do with 3D images) I have been thinking that it should be possible to use Mesa's OpenGL texture transfer routines within the Clover transfer routines (rather than the current path through soft_copy_op, which uses direct memcpy instructions) Unfortunately, so far I've only been able to look at a 4x4 image, anything beyond that causes the GPU CP to stall on me. If anyone can shed some light on these parameters that the Catalyst driver uses, or provide some information on how the Mesa OpenGL implementation transfers texture data to the radeon GPUs, I'd appreciate it. My online research hasn't been very productive, I think because I don't fully understand the terminology being used in this area. Thanks! Al Dorrington Software Engineer Sr Lockheed Martin, Mission Systems and Training ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] mesa: Add support to unpack depth-stencil texture in to FLOAT_32_UNSIGNED_INT_24_8_REV
Am 22.03.2014 18:15, schrieb Brian Paul:
On 03/21/2014 04:01 PM, Anuj Phogat wrote:
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/main/format_unpack.c | 79
++-
src/mesa/main/format_unpack.h | 5 +++
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/format_unpack.c
b/src/mesa/main/format_unpack.c
index 7abbe46..1725f10 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -4264,6 +4264,79 @@
_mesa_unpack_uint_24_8_depth_stencil_row(mesa_format format, GLuint n,
}
}
+static void
+unpack_float_32_uint_24_8_depth_stencil_S8_Z24(const GLuint *src,
+ GLuint *dst, GLuint n)
+{
+ GLuint i;
+
+ for (i = 0; i n; i++) {
+ GLuint val = src[i];
+ GLuint z24 = val 0xff;
+ GLfloat zf = z24 * (1.0F / 0xff);
In other function where we convert 24-bit Z to a float we need to use
double precision. See fc52534f012837a39c03a764eb611d460210514a
As a side note, the commit there is telling lies (GLfloat doesn't have
enough precision to exactly represent 0xff and 0x. (and a
reciprocal of those, if I am not mistaken)
0xff is perfectly representable using floats (as is any other 24bit
unorm number). Therefore, I can't see why the _pack_ functions need
doubles (I have some faint memory though there was some discussion about
it...). The reciprocal, however, indeed is not (I doubt it's exactly
representable with doubles neither, but with floats indeed that last bit
is nearly exactly 50% off). I guess it would be nice if those functions
would use some inline helper for unorm24-float and vice versa
conversions so at least the same logic is used everywhere. But in any
case since it's all scalar double vs. float probably doesn't really matter.
Roland
+ GLuint s = val 0xff00;
+ ((GLfloat *) dst)[i * 2 + 0] = zf;
+ dst[i * 2 + 1] = s;
+ }
+}
+
+static void
+unpack_float_32_uint_24_8_depth_stencil_Z32_S8X24(const GLuint *src,
+ GLuint *dst, GLuint n)
+{
+ GLuint i;
+
+ for (i = 0; i n; i++) {
+ /* 8 bytes per pixel (float + uint32) */
+ GLfloat zf = ((GLfloat *) src)[i * 2 + 0];
+ GLuint s = src[i * 2 + 1] 0xff;
+ ((GLfloat *) dst)[i * 2 + 0] = zf;
+ dst[i * 2 + 1] = s;
+ }
+}
+
+static void
+unpack_float_32_uint_24_8_depth_stencil_Z24_S8(const GLuint *src,
+ GLuint *dst, GLuint n)
+{
+ GLuint i;
+
+ for (i = 0; i n; i++) {
+ GLuint val = src[i];
+ GLuint z24 = (val 8);
+ GLfloat zf = z24 * (1.0F / 0xff);
+ GLuint s = val 0xff;
+ ((GLfloat *) dst)[i * 2 + 0] = zf;
+ dst[i * 2 + 1] = s 24;
+ }
+}
+
+/**
+ * Unpack depth/stencil returning as GL_FLOAT_32_UNSIGNED_INT_24_8_REV.
+ * \param format the source data format
+ */
+void
+_mesa_unpack_float_32_uint_24_8_depth_stencil_row(mesa_format format,
GLuint n,
+ const void *src, GLuint *dst)
+{
+ switch (format) {
+ case MESA_FORMAT_S8_UINT_Z24_UNORM:
+ unpack_float_32_uint_24_8_depth_stencil_Z24_S8(src, dst, n);
Let's try to follow the new format naming conventions. So can we rename
the function to include the actual src format name? Something like:
unpack_float_32_uint_24_8_depth_stencil_S8_UINT_Z24_UNORM().
or maybe unpack_float_32_uint_24_8_from_S8_UINT_Z24_UNORM().
I know the name gets a little crazy, but I think including the actual
format name in the function name is desirable. I'm about to post a
series which does this for most other functions in the
format_pack/unpack.c files.
+ break;
+ case MESA_FORMAT_Z24_UNORM_S8_UINT:
+ unpack_float_32_uint_24_8_depth_stencil_S8_Z24(src, dst, n);
+ break;
+ case MESA_FORMAT_Z32_FLOAT_S8X24_UINT:
+ unpack_float_32_uint_24_8_depth_stencil_Z32_S8X24(src, dst, n);
+ break;
+ default:
+ _mesa_problem(NULL,
+bad format %s in
_mesa_unpack_uint_24_8_depth_stencil_row,
+_mesa_get_format_name(format));
+ return;
+ }
+}
+
/**
* Unpack depth/stencil
* \param format the source data format
@@ -4274,12 +4347,16 @@ _mesa_unpack_depth_stencil_row(mesa_format
format, GLuint n,
const void *src, GLenum type,
GLuint *dst)
{
- assert(type == GL_UNSIGNED_INT_24_8);
+ assert(type == GL_UNSIGNED_INT_24_8 ||
+ type == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
switch (type) {
case GL_UNSIGNED_INT_24_8:
_mesa_unpack_uint_24_8_depth_stencil_row(format, n, src, dst);
break;
+ case GL_FLOAT_32_UNSIGNED_INT_24_8_REV:
+
Re: [Mesa-dev] [PATCH 2/2] i965: Change the winsys MSAA blits from blorp to meta.
Kenneth Graunke kenn...@whitecape.org writes:
On 03/21/2014 06:27 PM, Eric Anholt wrote:
This gets us equivalent code paths on BDW and pre-BDW, except for stencil
(where we don't have MSAA stencil resolve code yet)
v2: Move the new meta code to brw_meta_updownsample.c, name it
brw_meta_updownsample(), add a comment about
intel_rb_storage_first_mt_slice(), and rename that function and move
the RB generation into it (review ideas by Ken).
v3: Fix 2 src vs dst pasteos in previous change.
---
src/mesa/drivers/dri/i965/Makefile.sources| 1 +
src/mesa/drivers/dri/i965/brw_context.h | 6 +
src/mesa/drivers/dri/i965/brw_meta_updownsample.c | 132
++
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 21 ++--
4 files changed, 152 insertions(+), 8 deletions(-)
create mode 100644 src/mesa/drivers/dri/i965/brw_meta_updownsample.c
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
b/src/mesa/drivers/dri/i965/Makefile.sources
index 1649369..dfb88e2 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -74,6 +74,7 @@ i965_FILES = \
brw_interpolation_map.c \
brw_lower_texture_gradients.cpp \
brw_lower_unnormalized_offset.cpp \
+brw_meta_updownsample.c \
brw_misc_state.c \
brw_object_purgeable.c \
brw_performance_monitor.c \
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 32fc38b..04af5d0 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1484,6 +1484,12 @@ GLboolean brwCreateContext(gl_api api,
/*==
* brw_misc_state.c
*/
+void brw_meta_updownsample(struct brw_context *brw,
+ struct intel_mipmap_tree *src,
+ struct intel_mipmap_tree *dst);
+/*==
+ * brw_misc_state.c
+ */
void brw_get_depthstencil_tile_masks(struct intel_mipmap_tree *depth_mt,
uint32_t depth_level,
uint32_t depth_layer,
diff --git a/src/mesa/drivers/dri/i965/brw_meta_updownsample.c
b/src/mesa/drivers/dri/i965/brw_meta_updownsample.c
new file mode 100644
index 000..de25bf4
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_meta_updownsample.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include brw_context.h
+#include intel_batchbuffer.h
+#include intel_fbo.h
+
+#include main/blit.h
+#include main/buffers.h
+#include main/fbobject.h
+
+#include drivers/common/meta.h
+
+/**
+ * @file brw_meta_updownsample.c
+ *
+ * Implements upsampling and downsampling of miptrees for window system
+ * framebuffers.
+ */
+
+/**
+ * Creates a new named renderbuffer that wraps the first slice
+ * of an existing miptree.
+ *
+ * Clobbers the current renderbuffer binding (ctx-CurrentRenderbuffer).
+ */
+static GLuint
+brw_get_rb_for_first_slice(struct brw_context *brw, struct
intel_mipmap_tree *mt)
+{
+ struct gl_context *ctx = brw-ctx;
+ GLuint rbo;
+ struct gl_renderbuffer *rb;
+ struct intel_renderbuffer *irb;
+
+ /* This turns the GenRenderbuffers name into an actual struct
+* intel_renderbuffer.
+*/
+ _mesa_GenRenderbuffers(1, rbo);
+ _mesa_BindRenderbuffer(GL_RENDERBUFFER, rbo);
+
+ rb = ctx-CurrentRenderbuffer;
+ irb = intel_renderbuffer(rb);
+
+ rb-Format = mt-format;
+ rb-_BaseFormat = _mesa_base_fbo_format(ctx, mt-format);
+
+ rb-NumSamples = mt-num_samples;
+ rb-Width = mt-logical_width0;
+ rb-Height = mt-logical_height0;
+
+
Re: [Mesa-dev] RFC: Fixing XBMC crash with NV_vdpau_interop
Am 23.03.2014 12:36, schrieb Christian König: Am 22.03.2014 23:33, schrieb Brian Paul: On Sat, Mar 22, 2014 at 2:49 PM, Christian König deathsim...@vodafone.de mailto:deathsim...@vodafone.de wrote: Hi guys, recently some XBMC users complained about crashes with the relatively new NV_vdpau_interop support. That turned out to be a problem with how st_atom_texture.c caches the sampler view for a texture. Since the texture in question is shared between two GLX contexts the pipe object the sampler view was originally created for doesn't necessary match the pipe object it is used with. Now my question is am I missing something or is this case really not correctly supported? Where is the check if a texture is used in more than one context? The attached patch fixes the issue, but I'm not sure if it is the right approach. I've run into this too. I think the best thing to do (short of removing the sampler view from the st_texture_object) is to walk over all the textures in the share group at context-destroy time, looking for sampler views belonging to the context being destroyed, then free those sampler views. Yeah, that's also a problem, but not what I'm currently dealing with. My problem is that we pass a sampler view to a pipe context which doesn't belong to this context. Surprisingly the driver doesn't crash immediately, but instead works fine for at least some time. Our radeonsi driver keeps an internal reference to all sample views bound to it, and so when some times later a new sampler view is bound we unreference the sampler view in question and crash because the context where this sampler view was created with no longer exists. So it's reference inside the driver that crashes, not the one in the mesa state tracker. So there is probably nothing I can do except for what the attached patch does and try to never bind a sampler view to a context it doesn't belong to. I could probably whip up a patch next week. Would you mind if I try to fix that? Doesn't sounds so complicated to me. Some texture sharing problems crop up from time to time due to this (textures being sharable by GL, but sampler views are strictly per-context in gallium). If the sampler view would be destroyed when the context is destroyed, wouldn't that also get rid of the reference in the driver (though I guess you should unbind that texture if it's still bound at that point)? Though arguably, you are not supposed to use sampler views belonging to another context even if said context still exists. So, I think recreating the sampler view when the current one belongs to a different context is fine, though maybe it would be better if the views would be separated from the st_texture_object and stored somewhere else in the context. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/12] i965/vec4: Eliminate writes that are never read.
On Thu, Mar 20, 2014 at 12:28 PM, Eric Anholt e...@anholt.net wrote:
Matt Turner matts...@gmail.com writes:
With an awful O(n^2) algorithm that searches previous instructions for
dead writes.
total instructions in shared programs: 805582 - 788074 (-2.17%)
instructions in affected programs: 144561 - 127053 (-12.11%)
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 46
++
1 file changed, 46 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 4ad398a..e9219a9 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -369,6 +369,7 @@ bool
vec4_visitor::dead_code_eliminate()
{
bool progress = false;
+ bool seen_control_flow = false;
int pc = -1;
calculate_live_intervals();
@@ -378,6 +379,8 @@ vec4_visitor::dead_code_eliminate()
pc++;
+ seen_control_flow = inst-is_control_flow() || seen_control_flow;
+
So, once there's control flow in the program, this piece of optimization
doesn't happen ever after it? Seems like in the walk backwards you
could just stop the walk when you find a control flow instruction.
That's a good idea. I'll try to implement that today.
if (inst-dst.file != GRF || inst-has_side_effects())
continue;
@@ -393,6 +396,49 @@ vec4_visitor::dead_code_eliminate()
}
progress = try_eliminate_instruction(inst, write_mask) || progress;
+
+ if (seen_control_flow || inst-predicate || inst-prev == NULL)
+ continue;
+
+ int dead_channels = inst-dst.writemask;
+
+ for (int i = 0; i 3; i++) {
+ if (inst-src[i].file != GRF ||
+ inst-src[i].reg != inst-dst.reg)
+ continue;
+
+ for (int j = 0; j 4; j++) {
+int swiz = BRW_GET_SWZ(inst-src[i].swizzle, j);
+dead_channels = ~(1 swiz);
+ }
+ }
+
+ for (exec_node *node = inst-prev, *prev = node-prev;
+ prev != NULL dead_channels != 0;
+ node = prev, prev = prev-prev) {
You could potentially terminate the loop when you're out of the live
range of the dst, which would reduce the pain of n^2.
Also a good idea. I thought about this a little and punted because I'd
have to modify the ip value when previous instructions were removed,
but that should be a pretty simple change. I'll try to do that too.
Thanks for the reviews and the ideas.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] llvmpipe: Simplify vertex and geometry shaders.
Am 24.03.2014 16:31, schrieb jfons...@vmware.com:
From: José Fonseca jfons...@vmware.com
Eliminate lp_vertex_shader, as it added nothing over draw_vertex_shader.
Simplify lp_geometry_shader, as most of the incoming state is unneeded.
(We could also just use draw_geometry_shader if we were willing to peek
inside the structure.)
---
src/gallium/drivers/llvmpipe/lp_context.h | 4 +--
src/gallium/drivers/llvmpipe/lp_draw_arrays.c | 8 ++---
src/gallium/drivers/llvmpipe/lp_state.h | 13 ++--
src/gallium/drivers/llvmpipe/lp_state_gs.c| 32 +++
src/gallium/drivers/llvmpipe/lp_state_vs.c| 46
+++
5 files changed, 33 insertions(+), 70 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_context.h
b/src/gallium/drivers/llvmpipe/lp_context.h
index 05cdfe5..ee8033c 100644
--- a/src/gallium/drivers/llvmpipe/lp_context.h
+++ b/src/gallium/drivers/llvmpipe/lp_context.h
@@ -46,8 +46,8 @@
struct llvmpipe_vbuf_render;
struct draw_context;
struct draw_stage;
+struct draw_vertex_shader;
struct lp_fragment_shader;
-struct lp_vertex_shader;
struct lp_blend_state;
struct lp_setup_context;
struct lp_setup_variant;
@@ -63,7 +63,7 @@ struct llvmpipe_context {
const struct pipe_depth_stencil_alpha_state *depth_stencil;
const struct pipe_rasterizer_state *rasterizer;
struct lp_fragment_shader *fs;
- const struct lp_vertex_shader *vs;
+ struct draw_vertex_shader *vs;
const struct lp_geometry_shader *gs;
const struct lp_velems_state *velems;
const struct lp_so_state *so;
diff --git a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
index 3df0a5c..99e6d19 100644
--- a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
+++ b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
@@ -112,11 +112,11 @@ llvmpipe_draw_vbo(struct pipe_context *pipe, const
struct pipe_draw_info *info)
llvmpipe_prepare_geometry_sampling(lp,
lp-num_sampler_views[PIPE_SHADER_GEOMETRY],
lp-sampler_views[PIPE_SHADER_GEOMETRY]);
- if (lp-gs !lp-gs-shader.tokens) {
+ if (lp-gs lp-gs-no_tokens) {
/* we have an empty geometry shader with stream output, so
attach the stream output info to the current vertex shader */
if (lp-vs) {
- draw_vs_attach_so(lp-vs-draw_data, lp-gs-shader.stream_output);
+ draw_vs_attach_so(lp-vs, lp-gs-stream_output);
}
}
draw_collect_pipeline_statistics(draw,
@@ -136,11 +136,11 @@ llvmpipe_draw_vbo(struct pipe_context *pipe, const
struct pipe_draw_info *info)
}
draw_set_mapped_so_targets(draw, 0, NULL);
- if (lp-gs !lp-gs-shader.tokens) {
+ if (lp-gs lp-gs-no_tokens) {
/* we have attached stream output to the vs for rendering,
now lets reset it */
if (lp-vs) {
- draw_vs_reset_so(lp-vs-draw_data);
+ draw_vs_reset_so(lp-vs);
}
}
diff --git a/src/gallium/drivers/llvmpipe/lp_state.h
b/src/gallium/drivers/llvmpipe/lp_state.h
index 8635cf1..2da6caa 100644
--- a/src/gallium/drivers/llvmpipe/lp_state.h
+++ b/src/gallium/drivers/llvmpipe/lp_state.h
@@ -65,17 +65,10 @@ struct llvmpipe_context;
-/** Subclass of pipe_shader_state */
-struct lp_vertex_shader
-{
- struct pipe_shader_state shader;
- struct draw_vertex_shader *draw_data;
-};
-
-/** Subclass of pipe_shader_state */
struct lp_geometry_shader {
- struct pipe_shader_state shader;
- struct draw_geometry_shader *draw_data;
+ boolean no_tokens;
+ struct pipe_stream_output_info stream_output;
+ struct draw_geometry_shader *dgs;
};
/** Vertex element state */
diff --git a/src/gallium/drivers/llvmpipe/lp_state_gs.c
b/src/gallium/drivers/llvmpipe/lp_state_gs.c
index 74cf992..c94afed 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_gs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_gs.c
@@ -48,7 +48,7 @@ llvmpipe_create_gs_state(struct pipe_context *pipe,
state = CALLOC_STRUCT(lp_geometry_shader);
if (state == NULL )
- goto fail;
+ goto no_state;
/* debug */
if (LP_DEBUG DEBUG_TGSI) {
@@ -57,26 +57,19 @@ llvmpipe_create_gs_state(struct pipe_context *pipe,
}
/* copy stream output info */
- state-shader = *templ;
- if (templ-tokens) {
- /* copy shader tokens, the ones passed in will go away. */
- state-shader.tokens = tgsi_dup_tokens(templ-tokens);
- if (state-shader.tokens == NULL)
- goto fail;
-
- state-draw_data = draw_create_geometry_shader(llvmpipe-draw, templ);
- if (state-draw_data == NULL)
- goto fail;
+ state-no_tokens = !templ-tokens;
+ memcpy(state-stream_output, templ-stream_output, sizeof
state-stream_output);
+
+ state-dgs = draw_create_geometry_shader(llvmpipe-draw, templ);
+ if
Re: [Mesa-dev] [PATCH 2/2] llvmpipe: Simplify vertex and geometry shaders.
The series looks great to me.
- Original Message -
From: José Fonseca jfons...@vmware.com
Eliminate lp_vertex_shader, as it added nothing over draw_vertex_shader.
Simplify lp_geometry_shader, as most of the incoming state is unneeded.
(We could also just use draw_geometry_shader if we were willing to peek
inside the structure.)
---
src/gallium/drivers/llvmpipe/lp_context.h | 4 +--
src/gallium/drivers/llvmpipe/lp_draw_arrays.c | 8 ++---
src/gallium/drivers/llvmpipe/lp_state.h | 13 ++--
src/gallium/drivers/llvmpipe/lp_state_gs.c| 32 +++
src/gallium/drivers/llvmpipe/lp_state_vs.c| 46
+++
5 files changed, 33 insertions(+), 70 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_context.h
b/src/gallium/drivers/llvmpipe/lp_context.h
index 05cdfe5..ee8033c 100644
--- a/src/gallium/drivers/llvmpipe/lp_context.h
+++ b/src/gallium/drivers/llvmpipe/lp_context.h
@@ -46,8 +46,8 @@
struct llvmpipe_vbuf_render;
struct draw_context;
struct draw_stage;
+struct draw_vertex_shader;
struct lp_fragment_shader;
-struct lp_vertex_shader;
struct lp_blend_state;
struct lp_setup_context;
struct lp_setup_variant;
@@ -63,7 +63,7 @@ struct llvmpipe_context {
const struct pipe_depth_stencil_alpha_state *depth_stencil;
const struct pipe_rasterizer_state *rasterizer;
struct lp_fragment_shader *fs;
- const struct lp_vertex_shader *vs;
+ struct draw_vertex_shader *vs;
const struct lp_geometry_shader *gs;
const struct lp_velems_state *velems;
const struct lp_so_state *so;
diff --git a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
index 3df0a5c..99e6d19 100644
--- a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
+++ b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
@@ -112,11 +112,11 @@ llvmpipe_draw_vbo(struct pipe_context *pipe, const
struct pipe_draw_info *info)
llvmpipe_prepare_geometry_sampling(lp,
lp-num_sampler_views[PIPE_SHADER_GEOMETRY],
lp-sampler_views[PIPE_SHADER_GEOMETRY]);
- if (lp-gs !lp-gs-shader.tokens) {
+ if (lp-gs lp-gs-no_tokens) {
/* we have an empty geometry shader with stream output, so
attach the stream output info to the current vertex shader */
if (lp-vs) {
- draw_vs_attach_so(lp-vs-draw_data,
lp-gs-shader.stream_output);
+ draw_vs_attach_so(lp-vs, lp-gs-stream_output);
}
}
draw_collect_pipeline_statistics(draw,
@@ -136,11 +136,11 @@ llvmpipe_draw_vbo(struct pipe_context *pipe, const
struct pipe_draw_info *info)
}
draw_set_mapped_so_targets(draw, 0, NULL);
- if (lp-gs !lp-gs-shader.tokens) {
+ if (lp-gs lp-gs-no_tokens) {
/* we have attached stream output to the vs for rendering,
now lets reset it */
if (lp-vs) {
- draw_vs_reset_so(lp-vs-draw_data);
+ draw_vs_reset_so(lp-vs);
}
}
diff --git a/src/gallium/drivers/llvmpipe/lp_state.h
b/src/gallium/drivers/llvmpipe/lp_state.h
index 8635cf1..2da6caa 100644
--- a/src/gallium/drivers/llvmpipe/lp_state.h
+++ b/src/gallium/drivers/llvmpipe/lp_state.h
@@ -65,17 +65,10 @@ struct llvmpipe_context;
-/** Subclass of pipe_shader_state */
-struct lp_vertex_shader
-{
- struct pipe_shader_state shader;
- struct draw_vertex_shader *draw_data;
-};
-
-/** Subclass of pipe_shader_state */
struct lp_geometry_shader {
- struct pipe_shader_state shader;
- struct draw_geometry_shader *draw_data;
+ boolean no_tokens;
+ struct pipe_stream_output_info stream_output;
+ struct draw_geometry_shader *dgs;
};
/** Vertex element state */
diff --git a/src/gallium/drivers/llvmpipe/lp_state_gs.c
b/src/gallium/drivers/llvmpipe/lp_state_gs.c
index 74cf992..c94afed 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_gs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_gs.c
@@ -48,7 +48,7 @@ llvmpipe_create_gs_state(struct pipe_context *pipe,
state = CALLOC_STRUCT(lp_geometry_shader);
if (state == NULL )
- goto fail;
+ goto no_state;
/* debug */
if (LP_DEBUG DEBUG_TGSI) {
@@ -57,26 +57,19 @@ llvmpipe_create_gs_state(struct pipe_context *pipe,
}
/* copy stream output info */
- state-shader = *templ;
- if (templ-tokens) {
- /* copy shader tokens, the ones passed in will go away. */
- state-shader.tokens = tgsi_dup_tokens(templ-tokens);
- if (state-shader.tokens == NULL)
- goto fail;
-
- state-draw_data = draw_create_geometry_shader(llvmpipe-draw, templ);
- if (state-draw_data == NULL)
- goto fail;
+ state-no_tokens = !templ-tokens;
+ memcpy(state-stream_output, templ-stream_output, sizeof
state-stream_output);
+
+ state-dgs = draw_create_geometry_shader(llvmpipe-draw, templ);
+ if
[Mesa-dev] [Bug 76489] Mesa git (011569b5b7) compilation issue: render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]
https://bugs.freedesktop.org/show_bug.cgi?id=76489 --- Comment #6 from Dâniel Fraga frag...@gmail.com --- (In reply to comment #5) gcc -E will help you out. Note that I'm not passionate at looking through and comparing the mile long preprocessed sources so I'd leave that pleasure to you :) No problem! ;) I do the hard work. But I need at least a little help to figure out it. As far as I understand, the problem is with the indirect_init.c file. So I need to generate the preprocessed source with gcc -E indirect_init.c right? I did it including the needed -I parameters. I'll attach the result file. Does it help? -- 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 76489] Mesa git (011569b5b7) compilation issue: render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]
https://bugs.freedesktop.org/show_bug.cgi?id=76489 --- Comment #7 from Dâniel Fraga frag...@gmail.com --- Created attachment 96313 -- https://bugs.freedesktop.org/attachment.cgi?id=96313action=edit Preprocessed source (indirect_init.c) -- 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] OpenCL/clover buffers vs images
On Mon, Mar 24, 2014 at 02:35:04PM +, Dorrington, Albert wrote: I have been experimenting with adding image support to the clover implementation, and have been trying to understand the differences between the existing buffer support and what would be required to support images. From what I'm gathering, buffers are laid out in VRAM in a linear format, while images would be laid out in some sort of tiled format. I have been trying to do some research on tiled memory layout, and have not yet been able to find anything which describes the tiled format that is in use on R600 and Evergreen GPUs. I have also tried going through the OpenGL code to understand how image textures are transferred to the R600/Evergreen GPUs, since I am making the assumption that OpenGL would be transferring the images to GPU RAM in the same tiled format that an OpenCL texture would use. I have been trying to do some comparisons with the Catalyst driver's implementation, but I have not determined a way to view the internals of the registers and CB areas within the catalyst environment. For example, looking at the IL and ISA generated using the Catalyst SDK, I can see that there are 8 32-bit fields being read from CB1 for an read_only image kernel parameter. I have been able to determine that the first three are integer width, height, depth. The fourth is the image channel data type, the 8th is the image channel order. The 5th and 6th are involved in offset calculations for sampler coordinates (not sure if they are row and slice pitches of some sort) while the 7th seems unused (I'm assuming it must have something to do with 3D images) If you send me your example code, I can look at the kernel analyzer and try to figure out what is going on. I have been thinking that it should be possible to use Mesa's OpenGL texture transfer routines within the Clover transfer routines (rather than the current path through soft_copy_op, which uses direct memcpy instructions) Unfortunately, so far I've only been able to look at a 4x4 image, anything beyond that causes the GPU CP to stall on me. If anyone can shed some light on these parameters that the Catalyst driver uses, or provide some information on how the Mesa OpenGL implementation transfers texture data to the radeon GPUs, I'd appreciate it. My online research hasn't been very productive, I think because I don't fully understand the terminology being used in this area. I think you should be able to re-use most of the texturing code in r600g for OpenCL. However, I have very limited knowledge of this code, so I may be wrong. I actually had basic image support working about 6 months ago. I had to hard code a bunch of values into the compiler and also libclc, but I was able to pass a simple test. Below you can find some links to the code. You might get lucky and it will still work after you rebase it, but I doubt it. However, it may help you get an idea of what to do by looking through the code: http://cgit.freedesktop.org/~tstellar/mesa/log/?h=r600g-image-support http://cgit.freedesktop.org/~tstellar/libclc/log/?h=image http://cgit.freedesktop.org/~tstellar/llvm/log/?h=image-support Thanks! Al Dorrington Software Engineer Sr Lockheed Martin, Mission Systems and Training ___ 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] [PATCH 1/3] mesa: Introduce a _mesa_format_has_color_component() helper.
Kenneth Graunke kenn...@whitecape.org writes:
When considering color write masks, we often want to know whether an
RGBA component actually contains any meaningful data. This function
provides an easy way to answer that question, and handles luminance,
intensity, and alpha formats correctly.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/formats.c | 29 +
src/mesa/main/formats.h | 4
2 files changed, 33 insertions(+)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index c3e8049..4fb1f11 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -2207,6 +2207,35 @@ _mesa_format_num_components(mesa_format format)
/**
+ * Returns true if a color format has data stored in the R/G/B/A channels,
+ * given an index from 0 to 3.
+ */
+bool
+_mesa_format_has_color_component(mesa_format format, int component)
+{
+ const struct gl_format_info *info = _mesa_get_format_info(format);
+
+ assert(info-BaseFormat != GL_DEPTH_COMPONENT
+ info-BaseFormat != GL_DEPTH_STENCIL
+ info-BaseFormat != GL_STENCIL_INDEX);
+
+ switch (component) {
+ case 0:
+ return (info-RedBits + info-IntensityBits + info-LuminanceBits) 0;
+ case 1:
+ return (info-GreenBits + info-IntensityBits + info-LuminanceBits)
0;
+ case 2:
+ return (info-BlueBits + info-IntensityBits + info-LuminanceBits)
0;
+ case 3:
+ return (info-AlphaBits + info-IntensityBits) 0;
+ default:
+ assert(!Invalid color component: must be 0..3);
+ return false;
+ }
+}
It would be possible to catch more cases by having the BaseFormat passed
in from the outseide, so we'd answer false when asked about the A
channel of an RGB texture that got stored in an ARGB mesa_format.
However, this all appears correct now, and it's a big win, so the series
is:
Reviewed-by: Eric Anholt e...@anholt.net
pgpfLOo5M_ZnB.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: In core profile, refuse to draw unless a VAO is bound.
On 03/20/2014 11:53 AM, Kenneth Graunke wrote:
Core profile requires a non-default VAO to be bound. Currently, calls
to glVertexAttribPointer raise INVALID_OPERATION unless a VAO is bound,
and we never actually get any vertex data set. Trying to draw without
any vertex data can only cause problems. In i965, it causes a crash.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76400
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Candidate for stable?
---
src/mesa/main/api_validate.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index f3fd1a4..923a195 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -125,8 +125,11 @@ check_valid_to_render(struct gl_context *ctx, const char
*function)
return GL_FALSE;
break;
- case API_OPENGL_COMPAT:
case API_OPENGL_CORE:
+ if (ctx-Array.VAO == ctx-Array.DefaultVAO)
+ return GL_FALSE;
+ /* fallthrough */
+ case API_OPENGL_COMPAT:
{
const struct gl_shader_program *vsProg =
ctx-Shader.CurrentProgram[MESA_SHADER_VERTEX];
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] mesa: Skip clearing color buffers when color writes are disabled.
On 03/24/2014 08:07 AM, Brian Paul wrote:
On 03/24/2014 02:52 AM, Kenneth Graunke wrote:
WebGL Aquarium in Chrome 24 actually hits this.
v2: Move to core Mesa (wisely suggested by Ian); only consider
components which actually exist.
v3: Use _mesa_format_has_color_component to determine whether components
actually exist, fixing alpha format handling.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/clear.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
Thanks for the review! You're absolutely right about ALPHA formats.
I think this version should actually work :)
diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
index 077c5fc..e2566c0 100644
--- a/src/mesa/main/clear.c
+++ b/src/mesa/main/clear.c
@@ -106,6 +106,24 @@ _mesa_ClearColorIuiEXT(GLuint r, GLuint g, GLuint
b, GLuint a)
}
+static bool
+color_buffer_writes_enabled(const struct gl_context *ctx, unsigned idx)
+{
+ struct gl_renderbuffer *rb = ctx-DrawBuffer-_ColorDrawBuffers[idx];
+ GLuint c;
+ GLubyte colorMask = 0;
+
+ if (rb) {
+ for (c = 0; c 4; c++) {
+ if (_mesa_format_has_color_component(rb-Format, c))
+colorMask |= ctx-Color.ColorMask[idx][c];
+ }
+ }
+
+ return colorMask != 0;
+}
+
+
/**
* Clear buffers.
*
@@ -181,7 +199,7 @@ _mesa_Clear( GLbitfield mask )
for (i = 0; i ctx-DrawBuffer-_NumColorDrawBuffers; i++) {
GLint buf = ctx-DrawBuffer-_ColorDrawBufferIndexes[i];
-if (buf = 0) {
+if (buf = 0 color_buffer_writes_enabled(ctx, i)) {
bufferMask |= 1 buf;
}
}
I still think a comment on the new function would be nice. Looks good
though.
Reviewed-by: Brian Paul bri...@vmware.com
Oops, sorry...I missed your request for a comment. Added in v4 (with no
actual code changes), and pushed. Thanks!
--Ken
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] haiku: Fix build through scons corrections and viewport fixes
On 03/22/2014 03:58 PM, Alexander von Gluck IV wrote:
* Add HAVE_PTHREAD, we do have pthread support wrappers now for
non-native Haiku threaded applications.
* Viewport changed behavior recently breaking the build.
We fix this by looking at the gl_context ViewportArray
(Thanks Brian for the idea)
The build fixes and the Viewport changes should be separate patches.
With the changes split, the patch with the Viewport changes is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
I don't know anything about scons, so someone else will have to review that.
---
scons/gallium.py |5 +
.../targets/haiku-softpipe/GalliumContext.cpp | 12 +---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/scons/gallium.py b/scons/gallium.py
index f505a62..e11d4db 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -269,6 +269,11 @@ def generate(env):
cppdefines += ['HAVE_ALIAS']
else:
cppdefines += ['GLX_ALIAS_UNSUPPORTED']
+if env['platform'] == 'haiku':
+cppdefines += [
+'HAVE_PTHREAD',
+'HAVE_POSIX_MEMALIGN'
+]
if platform == 'windows':
cppdefines += [
'WIN32',
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
index 1078cb7..52cd764 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
@@ -44,9 +44,15 @@ extern C {
static void
-hgl_viewport(struct gl_context* glContext, GLint x, GLint y,
- GLsizei width, GLsizei height)
+hgl_viewport(struct gl_context* glContext)
{
+ // TODO: We should try to eliminate this function
+
+ GLint x = glContext-ViewportArray[0].X;
+ GLint y = glContext-ViewportArray[0].Y;
+ GLint width = glContext-ViewportArray[0].Width;
+ GLint height = glContext-ViewportArray[0].Height;
+
TRACE(%s(glContext: %p, x: %d, y: %d, w: %d, h: %d\n, __func__,
glContext, x, y, width, height);
@@ -525,7 +531,7 @@ GalliumContext::ResizeViewport(int32 width, int32 height)
for (context_id i = 0; i CONTEXT_MAX; i++) {
if (fContext[i] fContext[i]-st) {
struct st_context *stContext = (struct
st_context*)fContext[i]-st;
- _mesa_set_viewport(stContext-ctx, 0, 0, width, height);
+ _mesa_set_viewport(stContext-ctx, 0, 0, 0, width,
height);
st_manager_validate_framebuffers(stContext);
}
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXTERNAL: Re: OpenCL/clover buffers vs images
The kernel I'm working with is rather simple:
const sampler_t s_nearest = CLK_FILTER_NEAREST | CLK_NORMALIZED_COORDS_FALSE |
CLK_ADDRESS_NONE;
__kernel void
image_test (__read_only image2d_t im, __global float4 *out)
{
out[ 0] = read_imagef (im, s_nearest, (int2) (0, 0));
}
Using the Catalyst compiler to produce the ISA (with a -O0 compile flag) I get
the following, which includes my notes/comments on the right side:
; Disassembly
00 ALU: ADDR(32) CNT(18) KCACHE0(CB1:0-15) KCACHE1(CB2:0-15)
0 z: BFE_UINTT0.z, KC1[0].x, 0x0005, 1; Linear Filter
Flag
w: AND_INT T0.w, KC1[0].x, 1 ; Normalized
Flag
t: I_TO_F , KC0[0].x ; convert Int to Float
(Width?)
1 x: LSHRR1.x, KC0[2].x, 2 ; KC0[2].x / 4
- R1.x
z: CNDE_INT, PV0.w, 1.0f, ImgWidth ; if Not Normalized
then 1.0f else ImgWidth
t: I_TO_F , KC0[0].y ; convert int to float
(Height?)
2 x: MUL_e T0.x, PV1.z, xCoord ; Scale xCoord
- T0.x
y: CNDE_INT, T0.w, 1.0f, ImgHeight ; if Not Normalized
then 1.0f else ImgHeight
3 y: FLOOR , PV2.x; floor(xCoord)
w: MUL_e T0.w, PV2.y, yCoord ; Scale yCoord - T0.w
4 x: FLOOR , PV3.w; Floor(yCoord)
w: CNDE_INT, T0.z, PV3.y, T0.x ; If Not Linear
then floor(xCoord) else Scaled(xCoord)
5 x: MUL_e R0.x, KC0[1].x, PV4.w ; R0.x = KC0[1].x *
xCoord (floored/scaled)
z: CNDE_INT, T0.z, PV4.x, T0.w ; If Not Linear
then floor(xCoord) else Scaled(yCoord)
6 y: MUL_e R0.y, KC0[1].y, PV5.z ; R0.y = KC0[1].y *
yCoord (floored/scaled)
01 TEX: ADDR(64) CNT(1)
7 SAMPLE R0, R0.xy0x, t0, s0
02 MEM_RAT_CACHELESS_STORE_RAW: RAT(11)[R1], R0, ARRAY_SIZE(4) VPM
END_OF_PROGRAM
I am fairly certain that KC1[0] is the Sampler value.
And that KC0[0] and KC0[1] are image parameters while KC0[2] is the output
pointer parameter
The fields I'm unsure of are KC0[1].x and KC0[1].y. I'm fairly certain that
they are pitch or stride values, but since I'm not sure if the texture memory
is linear or tiled, I'm not sure.
I was trying to use the sampler set as CLK_ADDRESS_NONE, in an attempt to look
'outside' of the image dimensions, to see what else might be in the memory
buffer - but I'm guessing that doesn't work as I suspected, because I keep
seeing clamped values anyway.
I've started reviewing the changes you made. I'm happy to see that I made a lot
of the same changes as you implemented (makes me think I actually understand
some of this!)
Although I'm not sure I quite yet follow what you did in
evergreen_set_compute_resources(), where you removed the vertex buffer setup.
-Al
-Original Message-
From: Tom Stellard [mailto:t...@stellard.net]
Sent: Monday, March 24, 2014 4:16 PM
To: Dorrington, Albert
Cc: mesa-dev@lists.freedesktop.org
Subject: EXTERNAL: Re: [Mesa-dev] OpenCL/clover buffers vs images
On Mon, Mar 24, 2014 at 02:35:04PM +, Dorrington, Albert wrote:
I have been experimenting with adding image support to the clover
implementation, and have been trying to understand the differences
between the existing buffer support and what would be required to support
images.
From what I'm gathering, buffers are laid out in VRAM in a linear format,
while images would be laid out in some sort of tiled format.
I have been trying to do some research on tiled memory layout, and have
not yet been able to find anything which describes the tiled format that is in
use on R600 and Evergreen GPUs.
I have also tried going through the OpenGL code to understand how image
textures are transferred to the R600/Evergreen GPUs, since I am making the
assumption that OpenGL would be transferring the images to GPU RAM in
the same tiled format that an OpenCL texture would use.
I have been trying to do some comparisons with the Catalyst driver's
implementation, but I have not determined a way to view the internals of
the registers and CB areas within the catalyst environment.
For example, looking at the IL and ISA generated using the Catalyst SDK, I
can see that there are 8 32-bit fields being read from CB1 for an read_only
image kernel parameter.
I have been able to determine that the first three are integer width,
height,
depth. The fourth is the image channel data type, the 8th is the image
channel order.
The 5th and 6th are involved in offset calculations for sampler
coordinates (not sure if they are row and slice pitches of some sort)
while the 7th seems unused (I'm assuming it must have something to do
with 3D images)
If you send me your example code, I can look at the kernel
[Mesa-dev] [PATCH] st/mesa: add null pointer checking in query object functions
Don't pass null query object pointers into gallium functions.
This avoids segfaulting in the VMware driver (and others?) if the
pipe_context::create_query() call fails and returns NULL.
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_cb_queryobj.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
b/src/mesa/state_tracker/st_cb_queryobj.c
index 5186a51..78a7370 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -141,7 +141,13 @@ st_BeginQuery(struct gl_context *ctx, struct
gl_query_object *q)
stq-pq = pipe-create_query(pipe, type);
stq-type = type;
}
- pipe-begin_query(pipe, stq-pq);
+ if (stq-pq) {
+ pipe-begin_query(pipe, stq-pq);
+ }
+ else {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, glBeginQuery);
+ return;
+ }
}
assert(stq-type == type);
}
@@ -162,7 +168,8 @@ st_EndQuery(struct gl_context *ctx, struct gl_query_object
*q)
stq-type = PIPE_QUERY_TIMESTAMP;
}
- pipe-end_query(pipe, stq-pq);
+ if (stq-pq)
+ pipe-end_query(pipe, stq-pq);
}
@@ -171,6 +178,13 @@ get_query_result(struct pipe_context *pipe,
struct st_query_object *stq,
boolean wait)
{
+ if (!stq-pq) {
+ /* Only needed in case we failed to allocate the gallium query earlier.
+ * Return TRUE so we don't spin on this forever.
+ */
+ return TRUE;
+ }
+
if (!pipe-get_query_result(pipe,
stq-pq,
wait,
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] svga: add work-around for Sauerbraten Z fighting issue
---
src/gallium/drivers/svga/svga_context.c | 33 ++
src/gallium/drivers/svga/svga_context.h |5
src/gallium/drivers/svga/svga_state_need_swtnl.c | 13 +++--
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_context.c
b/src/gallium/drivers/svga/svga_context.c
index 4da9a65..0ba09ce 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -25,11 +25,13 @@
#include svga_cmd.h
+#include os/os_process.h
#include pipe/p_defines.h
#include util/u_inlines.h
#include pipe/p_screen.h
#include util/u_memory.h
#include util/u_bitmask.h
+#include util/u_string.h
#include svga_context.h
#include svga_screen.h
@@ -80,6 +82,35 @@ static void svga_destroy( struct pipe_context *pipe )
}
+/**
+ * Check the process name to see if we're running with an app that
+ * needs any particular work-arounds.
+ */
+static void
+check_for_workarounds(struct svga_context *svga)
+{
+ char name[1000];
+
+ if (!os_get_process_name(name, sizeof(name)))
+ return;
+
+ if (util_strcmp(name, sauer_client) == 0) {
+ /*
+ * Sauerbraten uses a two-pass rendering algorithm. The first pass
+ * draws a depth map. The second pass draws the colors. On the second
+ * pass we wind up using the swtnl path because the game tries to use
+ * a GLbyte[3] normal vector array (which the SVGA3D protocol does not
+ * support.) The vertices of the first and second passes don't quite
+ * match so we see some depth/Z-fighting issues. This work-around
+ * causes us to map GLbyte[3] to SVGA3D_DECLTYPE_UBYTE4N and avoid the
+ * swtnl path. Despite not correctly converting normal vectors from
+ * GLbyte[3] to float[4], the rendering looks OK.
+ */
+ debug_printf(Enabling sauerbraten GLbyte[3] work-around\n);
+ svga-workaround.use_decltype_ubyte4n = TRUE;
+ }
+}
+
struct pipe_context *svga_context_create( struct pipe_screen *screen,
void *priv )
@@ -156,6 +187,8 @@ struct pipe_context *svga_context_create( struct
pipe_screen *screen,
LIST_INITHEAD(svga-dirty_buffers);
+ check_for_workarounds(svga);
+
return svga-pipe;
no_state:
diff --git a/src/gallium/drivers/svga/svga_context.h
b/src/gallium/drivers/svga/svga_context.h
index 0daab0b..1e93b02 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -389,6 +389,11 @@ struct svga_context
/** performance / info queries */
uint64_t num_draw_calls; /** SVGA_QUERY_DRAW_CALLS */
uint64_t num_fallbacks; /** SVGA_QUERY_FALLBACKS */
+
+ /** quirks / work-around flags for particular apps */
+ struct {
+ boolean use_decltype_ubyte4n;
+ } workaround;
};
/* A flag for each state_tracker state object:
diff --git a/src/gallium/drivers/svga/svga_state_need_swtnl.c
b/src/gallium/drivers/svga/svga_state_need_swtnl.c
index c0bfd2c..6f1d802 100644
--- a/src/gallium/drivers/svga/svga_state_need_swtnl.c
+++ b/src/gallium/drivers/svga/svga_state_need_swtnl.c
@@ -36,7 +36,8 @@
* format. Return SVGA3D_DECLTYPE_MAX for unsupported gallium formats.
*/
static INLINE SVGA3dDeclType
-svga_translate_vertex_format(enum pipe_format format)
+svga_translate_vertex_format(const struct svga_context *svga,
+ enum pipe_format format)
{
switch (format) {
case PIPE_FORMAT_R32_FLOAT:return SVGA3D_DECLTYPE_FLOAT1;
@@ -57,6 +58,12 @@ svga_translate_vertex_format(enum pipe_format format)
case PIPE_FORMAT_R16G16_FLOAT: return SVGA3D_DECLTYPE_FLOAT16_2;
case PIPE_FORMAT_R16G16B16A16_FLOAT: return SVGA3D_DECLTYPE_FLOAT16_4;
+ case PIPE_FORMAT_R8G8B8_SNORM:
+ if (svga-workaround.use_decltype_ubyte4n) {
+ return SVGA3D_DECLTYPE_UBYTE4N;
+ }
+ /* fall-through */
+
default:
/* There are many formats without hardware support. This case
* will be hit regularly, meaning we'll need swvfetch.
@@ -78,7 +85,9 @@ update_need_swvfetch(struct svga_context *svga, unsigned
dirty)
}
for (i = 0; i svga-curr.velems-count; i++) {
- svga-state.sw.ve_format[i] =
svga_translate_vertex_format(svga-curr.velems-velem[i].src_format);
+ svga-state.sw.ve_format[i] =
+ svga_translate_vertex_format(svga,
+ svga-curr.velems-velem[i].src_format);
if (svga-state.sw.ve_format[i] == SVGA3D_DECLTYPE_MAX) {
/* Unsupported format - use software fetch */
need_swvfetch = TRUE;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] svga: null out query's hwbuf pointer after destroying
Just to be extra safe.
---
src/gallium/drivers/svga/svga_pipe_query.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/svga/svga_pipe_query.c
b/src/gallium/drivers/svga/svga_pipe_query.c
index cdf463c..0283aa9 100644
--- a/src/gallium/drivers/svga/svga_pipe_query.c
+++ b/src/gallium/drivers/svga/svga_pipe_query.c
@@ -148,6 +148,7 @@ svga_destroy_query(struct pipe_context *pipe, struct
pipe_query *q)
switch (sq-type) {
case PIPE_QUERY_OCCLUSION_COUNTER:
sws-buffer_destroy(sws, sq-hwbuf);
+ sq-hwbuf = NULL;
sws-fence_reference(sws, sq-fence, NULL);
break;
case SVGA_QUERY_DRAW_CALLS:
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] svga: add some debug_printf() calls in the query object code
To help debug failures.
---
src/gallium/drivers/svga/svga_pipe_query.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_pipe_query.c
b/src/gallium/drivers/svga/svga_pipe_query.c
index 61085c4..cdf463c 100644
--- a/src/gallium/drivers/svga/svga_pipe_query.c
+++ b/src/gallium/drivers/svga/svga_pipe_query.c
@@ -94,13 +94,17 @@ svga_create_query( struct pipe_context *pipe, unsigned
query_type )
sq-hwbuf = svga_winsys_buffer_create(svga, 1,
SVGA_BUFFER_USAGE_PINNED,
sizeof *sq-queryResult);
- if (!sq-hwbuf)
+ if (!sq-hwbuf) {
+ debug_printf(svga: failed to alloc query object!\n);
goto no_hwbuf;
+ }
sq-queryResult = (SVGA3dQueryResult *)
sws-buffer_map(sws, sq-hwbuf, PIPE_TRANSFER_WRITE);
- if (!sq-queryResult)
+ if (!sq-queryResult) {
+ debug_printf(svga: failed to map query object!\n);
goto no_query_result;
+ }
sq-queryResult-totalSize = sizeof *sq-queryResult;
sq-queryResult-state = SVGA3D_QUERYSTATE_NEW;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2] glsl: Allow overlapping locations for vertex input attributes
Currently overlapping locations of input variables are not allowed for all the shader types in OpenGL and OpenGL ES. From OpenGL ES 3.0 spec, page 56: Binding more than one attribute name to the same location is referred to as aliasing, and is not permitted in OpenGL ES Shading Language 3.00 vertex shaders. LinkProgram will fail when this condition exists. However, aliasing is possible in OpenGL ES Shading Language 1.00 vertex shaders. Taking in to account what different versions of OpenGL and OpenGL ES specs say about aliasing: - It is allowed only on vertex shader input attributes in OpenGL (2.0 and above) and OpenGL ES 2.0. - It is explictly disallowed in OpenGL ES 3.0. Fixes Khronos CTS failing test: explicit_attrib_location_vertex_input_aliased.test See more details about this at below mentioned khronos bug. V2: Fix the case where location exceeds the maximum allowed attribute location. Signed-off-by: Anuj Phogat anuj.pho...@gmail.com Cc: 9.2 10.0 10.1 mesa-sta...@lists.freedesktop.org Bugzilla: Khronos #9609 --- src/glsl/linker.cpp | 91 - 1 file changed, 76 insertions(+), 15 deletions(-) diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index 8019444..13947ce 100644 --- a/src/glsl/linker.cpp +++ b/src/glsl/linker.cpp @@ -1692,6 +1692,9 @@ assign_attribute_or_color_locations(gl_shader_program *prog, unsigned used_locations = (max_index = 32) ? ~0 : ~((1 max_index) - 1); + /* Initially both numbers are equal. */ + unsigned available_locations = used_locations; + assert((target_index == MESA_SHADER_VERTEX) || (target_index == MESA_SHADER_FRAGMENT)); @@ -1798,10 +1801,12 @@ assign_attribute_or_color_locations(gl_shader_program *prog, * active attribute array, both of which require multiple * contiguous generic attributes. * -* Previous versions of the spec contain similar language but omit -* the bit about attribute arrays. +* I think above text prohibits the aliasing of explicit and +* automatic assignments. But, aliasing is allowed in manual +* assignments of attribute locations. See below comments for +* the details. * -* Page 61 of the OpenGL 4.0 spec also says: +* From OpenGL 4.0 spec, page 61: * * It is possible for an application to bind more than one * attribute name to the same location. This is referred to as @@ -1814,29 +1819,85 @@ assign_attribute_or_color_locations(gl_shader_program *prog, * but implementations are not required to generate an error * in this case. * -* These two paragraphs are either somewhat contradictory, or I -* don't fully understand one or both of them. -*/ - /* FINISHME: The code as currently written does not support -* FINISHME: attribute location aliasing (see comment above). +* From GLSL 4.30 spec, page 54: +* +*A program will fail to link if any two non-vertex shader +* input variables are assigned to the same location. For +* vertex shaders, multiple input variables may be assigned +* to the same location using either layout qualifiers or via +* the OpenGL API. However, such aliasing is intended only to +* support vertex shaders where each execution path accesses +* at most one input per each location. Implementations are +* permitted, but not required, to generate link-time errors +* if they detect that every path through the vertex shader +* executable accesses multiple inputs assigned to any single +* location. For all shader types, a program will fail to link +* if explicit location assignments leave the linker unable +* to find space for other variables without explicit +* assignments. +* +* From OpenGL ES 3.0 spec, page 56: +* +*Binding more than one attribute name to the same location +* is referred to as aliasing, and is not permitted in OpenGL +* ES Shading Language 3.00 vertex shaders. LinkProgram will +* fail when this condition exists. However, aliasing is +* possible in OpenGL ES Shading Language 1.00 vertex shaders. +* This will only work if only one of the aliased attributes +* is active in the executable program, or if no path through +* the shader consumes more than one attribute of a set of +* attributes aliased to the same location. A link error can +* occur if the linker
Re: [Mesa-dev] [Mesa-stable] [PATCH] glsl: Allow overlapping locations for vertex input attributes
Sent out a V2 of this patch which fixes a bug I noticed recently. On Thu, Mar 13, 2014 at 3:39 PM, Anuj Phogat anuj.pho...@gmail.com wrote: On Tue, Mar 11, 2014 at 10:37 AM, Ian Romanick i...@freedesktop.org wrote: On 03/10/2014 04:15 PM, Anuj Phogat wrote: On Mon, Mar 10, 2014 at 3:27 PM, Ian Romanick i...@freedesktop.org mailto:i...@freedesktop.org wrote: On 03/10/2014 11:19 AM, Anuj Phogat wrote: Currently overlapping locations of input variables are not allowed for all the shader types in OpenGL and OpenGL ES. From OpenGL ES 3.0 spec, page 56: Binding more than one attribute name to the same location is referred to as aliasing, and is not permitted in OpenGL ES Shading Language 3.00 vertex shaders. LinkProgram will fail when this condition exists. However, aliasing is possible in OpenGL ES Shading Language 1.00 vertex shaders. Taking in to account what different versions of OpenGL and OpenGL ES specs say about aliasing: - It is allowed only on vertex shader input attributes in OpenGL (2.0 and above) and OpenGL ES 2.0. - It is explictly disallowed in OpenGL ES 3.0. Fixes Khronos CTS failing test: explicit_attrib_location_vertex_input_aliased.test See more details about this at below mentioned khronos bug. Signed-off-by: Anuj Phogat anuj.pho...@gmail.com mailto:anuj.pho...@gmail.com Cc: 9.2 10.0 10.1 mesa-sta...@lists.freedesktop.org mailto:mesa-sta...@lists.freedesktop.org Bugzilla: Khronos #9609 --- src/glsl/linker.cpp | 74 +++-- 1 file changed, 61 insertions(+), 13 deletions(-) diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index a619bc8..9bd698b 100644 --- a/src/glsl/linker.cpp +++ b/src/glsl/linker.cpp @@ -1798,10 +1798,12 @@ assign_attribute_or_color_locations(gl_shader_program *prog, * active attribute array, both of which require multiple * contiguous generic attributes. * - * Previous versions of the spec contain similar language but omit - * the bit about attribute arrays. + * I think above text prohibits the aliasing of explicit and + * automatic assignments. But, aliasing is allowed in manual + * assignments of attribute locations. See below comments for + * the details. The text above (outside the diff) forbids things like: layout(location=0) in mat4 m; layout(location=1) in vec4 v; where v and m now partially overlap because m consumes 4 slots (0 through 3, inclusive). This should not be a problem as along as there's only one active attribute in vertex shader. If a developer uses such locations, its his responsibility to use just one of them in any path in shader program. Khronos CTS test also expects linking to happen in above case. OpenGL 4.0 spec makes similar looking statements at two different places. First for vertex shader input locations at page 60: LinkProgram will fail if the attribute bindings assigned by BindAttri- bLocation do not leave not enough space to assign a location for an active matrix attribute or an active attribute array, both of which require multiple contiguous generic attributes. Somewhere in the intervening specs, the language was changed. In 4.4 it says: LinkProgram will fail if the attribute bindings specified either by BindAttribLocation or explicitly set within the shader text do not leave not enough space to assign a location for an active matrix attribute or an active attribute array, both of which require multiple contiguous generic attributes. This statement sounds little unclear to me. It doesn't say what happens if locations set in shader text don't leave enough space. It also doesn't make clear who assigns the location in to assign a location for an active matrix. explicit or automatic assignment? You may be right. We'll have to prod other implementations. I'll also do some spec archaeology. Piglit tests I posted on mailing list passes on NVIDIA's OpenGL 4.3 linux driver. NVIDIA allows the kind of overlapping you described above. Second for fragment output locations at page 233: if the explicit binding assigments do not leave enough space for the linker to automatically assign a location for a varying out array, which requires multiple contiguous locations. This statement makes the condition more clear for linking error. Notice the words 'explicit' and 'automatically' in text from page 233. So I interpreted the two statements as:
Re: [Mesa-dev] [PATCH] haiku: Fix build through scons corrections and viewport fixes
On 03/24/2014 04:59 PM, Ian Romanick wrote: On 03/22/2014 03:58 PM, Alexander von Gluck IV wrote: * Add HAVE_PTHREAD, we do have pthread support wrappers now for non-native Haiku threaded applications. * Viewport changed behavior recently breaking the build. We fix this by looking at the gl_context ViewportArray (Thanks Brian for the idea) The build fixes and the Viewport changes should be separate patches. With the changes split, the patch with the Viewport changes is Reviewed-by: Ian Romanick ian.d.roman...@intel.com I don't know anything about scons, so someone else will have to review that. Thanks :-) Brian reviewed it earlier, just pushed it before I saw your email. I'd like to get this into the 10.1.x branch as all of the changes are build fixes to issues present in 10.1.0 (even the pthread change, seems pthread support is a requirement now as without it Mesa won't build) -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 76489] Mesa git (011569b5b7) compilation issue: render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]
https://bugs.freedesktop.org/show_bug.cgi?id=76489 Dâniel Fraga frag...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #8 from Dâniel Fraga frag...@gmail.com --- SOLVED! Can you believe the problem was caused by an old version of indent lying around? Now I got one last compilation error, but it would be better to report in another bug report, so I'm marking this as invalid. Thanks! -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 76577] egl_dri2.c:507:27: error: 'EGL_OPENGL_ES3_BIT_KHR' undeclared (first use in this function)
https://bugs.freedesktop.org/show_bug.cgi?id=76577 Dâniel Fraga frag...@gmail.com changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Product|DRI |Mesa Version|XOrg CVS|git Component|General |EGL -- 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 76577] egl_dri2.c:507:27: error: 'EGL_OPENGL_ES3_BIT_KHR' undeclared (first use in this function)
https://bugs.freedesktop.org/show_bug.cgi?id=76577 Dâniel Fraga frag...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Dâniel Fraga frag...@gmail.com --- Forget it! Error caused by old EGL header files installed. I just removed it and it compiled fine. -- 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] gallivm: fix no-op n:n lp_build_resize()
From: Roland Scheidegger srol...@vmware.com
This can get called in some circumstances if both src type and dst type
have same width (seen with float32-unorm32). While this particular case
was bogus anyway let's just fix that as it can work trivially (due to the
way it was called it actually worked anyway apart from the assert).
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
index 22a4f5a8..2b0a1fb 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
@@ -710,9 +710,6 @@ lp_build_resize(struct gallivm_state *gallivm,
/* We must not loose or gain channels. Only precision */
assert(src_type.length * num_srcs == dst_type.length * num_dsts);
- /* We don't support M:N conversion, only 1:N, M:1, or 1:1 */
- assert(num_srcs == 1 || num_dsts == 1);
-
assert(src_type.length = LP_MAX_VECTOR_LENGTH);
assert(dst_type.length = LP_MAX_VECTOR_LENGTH);
assert(num_srcs = LP_MAX_VECTOR_LENGTH);
@@ -723,6 +720,7 @@ lp_build_resize(struct gallivm_state *gallivm,
* Truncate bit width.
*/
+ /* Conversion must be M:1 */
assert(num_dsts == 1);
if (src_type.width * src_type.length == dst_type.width *
dst_type.length) {
@@ -775,6 +773,7 @@ lp_build_resize(struct gallivm_state *gallivm,
* Expand bit width.
*/
+ /* Conversion must be 1:N */
assert(num_srcs == 1);
if (src_type.width * src_type.length == dst_type.width *
dst_type.length) {
@@ -813,10 +812,11 @@ lp_build_resize(struct gallivm_state *gallivm,
* No-op
*/
- assert(num_srcs == 1);
- assert(num_dsts == 1);
+ /* Conversion must be N:N */
+ assert(num_srcs == num_dsts);
- tmp[0] = src[0];
+ for(i = 0; i num_dsts; ++i)
+ tmp[i] = src[i];
}
for(i = 0; i num_dsts; ++i)
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 76579] New: [swrast] piglit glean fbo regression
https://bugs.freedesktop.org/show_bug.cgi?id=76579 Priority: medium Bug ID: 76579 Keywords: regression CC: bri...@vmware.com, chr...@ijw.co.nz Assignee: mesa-dev@lists.freedesktop.org Summary: [swrast] piglit glean fbo regression Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: 7683fce8781ef0169333c5ee1276392d058cfaa8 (master 10.2.0-devel) $ ./bin/glean -t fbo --quick GL_EXT_framebuffer_object is supported GL_ARB_framebuffer_object is supported FAILURE: All any buffer named by glDrawBuffers is missing, status should be GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER_EXT (at tfbo.cpp:1322) fbo: FAIL rgba8, db, z24, s8, win+pmap, id 33 5 tests passed, 1 tests failed. a419a1c5654ac4a4a46ec3a80d75926e26919c99 is the first bad commit commit a419a1c5654ac4a4a46ec3a80d75926e26919c99 Author: Chris Forbes chr...@ijw.co.nz Date: Sun Mar 23 22:41:28 2014 +1300 mesa: Generate FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT earlier The ARB_framebuffer_object spec lists this case before the FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER and FRAMEBUFFER_INCOMPLETE_READ_BUFFER cases. Fixes two broken cases in piglit's fbo-incomplete test, if ARB_ES2_compatibility is not advertised. (If it is, this is masked because the FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER / FRAMEBUFFER_INCOMPLETE_READ_BUFFER cases are removed by that extension) Signed-off-by: Chris Forbes chr...@ijw.co.nz Reviewed-by: Brian Paul bri...@vmware.com :04 04 cb5fa6fcaea7036f0792067e35567f9cc4147151 5b463f68f58afde0fed387526158acf0fd1fc26b Msrc bisect run success -- 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 76579] [swrast] piglit glean fbo regression
https://bugs.freedesktop.org/show_bug.cgi?id=76579 --- Comment #1 from Chris Forbes chr...@ijw.co.nz --- I believe the glean test is wrong. The completeness conditions are listed in this order in EXT_framebuffer_object, ARB_framebuffer_object, and the core spec. I'm not sure there's much point to keeping glean's fbo tests -- piglit's native fbo tests are pretty thorough now. If we do keep them though, I propose changing the FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER and FRAMEBUFFER_INCOMPLETE_READ_BUFFER tests to have one attachment, but not the one named by glDrawBuffer. I can send a patch for this. -- 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 no-op n:n lp_build_resize()
Looks good to me.
z
- Original Message -
From: Roland Scheidegger srol...@vmware.com
This can get called in some circumstances if both src type and dst type
have same width (seen with float32-unorm32). While this particular case
was bogus anyway let's just fix that as it can work trivially (due to the
way it was called it actually worked anyway apart from the assert).
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
index 22a4f5a8..2b0a1fb 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
@@ -710,9 +710,6 @@ lp_build_resize(struct gallivm_state *gallivm,
/* We must not loose or gain channels. Only precision */
assert(src_type.length * num_srcs == dst_type.length * num_dsts);
- /* We don't support M:N conversion, only 1:N, M:1, or 1:1 */
- assert(num_srcs == 1 || num_dsts == 1);
-
assert(src_type.length = LP_MAX_VECTOR_LENGTH);
assert(dst_type.length = LP_MAX_VECTOR_LENGTH);
assert(num_srcs = LP_MAX_VECTOR_LENGTH);
@@ -723,6 +720,7 @@ lp_build_resize(struct gallivm_state *gallivm,
* Truncate bit width.
*/
+ /* Conversion must be M:1 */
assert(num_dsts == 1);
if (src_type.width * src_type.length == dst_type.width *
dst_type.length) {
@@ -775,6 +773,7 @@ lp_build_resize(struct gallivm_state *gallivm,
* Expand bit width.
*/
+ /* Conversion must be 1:N */
assert(num_srcs == 1);
if (src_type.width * src_type.length == dst_type.width *
dst_type.length) {
@@ -813,10 +812,11 @@ lp_build_resize(struct gallivm_state *gallivm,
* No-op
*/
- assert(num_srcs == 1);
- assert(num_dsts == 1);
+ /* Conversion must be N:N */
+ assert(num_srcs == num_dsts);
- tmp[0] = src[0];
+ for(i = 0; i num_dsts; ++i)
+ tmp[i] = src[i];
}
for(i = 0; i num_dsts; ++i)
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 76579] [swrast] piglit glean fbo regression
https://bugs.freedesktop.org/show_bug.cgi?id=76579 --- Comment #2 from Chris Forbes chr...@ijw.co.nz --- Patch as promised: http://lists.freedesktop.org/archives/piglit/2014-March/010089.html -- 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
