Re: [Mesa-dev] [PATCH] intel: Fix initial MakeCurrent for single-buffer drawables
hi, Kristian:
This patch block the startup of desktop-shell client in weston.
Panel surface and background surface share a common context.
First when client redraw panel surface, _mesa_make_current will set
brw->ctx.ViewportInitialized to true.
Later when client redraw background surface, intelMakeCurrent() won't
call intel_prepare_render(). So there isn't drawbuffer for background
surface.
Please check!
thanks
On Tue, 2014-01-21 at 12:39 -0800, Kristian Høgsberg wrote:
> Commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39 attempts to eliminate the
> call to intel_update_renderbuffer() in the case where we already have a
> drawbuffer for the drawable. Unfortunately this only checks the
> back left renderbuffer, which breaks in case of single buffer drawables.
>
> This means that the initial viewport will not be set in that case. Instead,
> we now check whether the initial viewport has not been set and the
> drawable size is 0x0, in which case we call out to
> intel_update_renderbuffer().
> This gives us the correct behaviour but also further eliminates a
> call to intel_update_renderbuffer() in the case where we make a newly
> created drawable current with a context that already has an initial viewport.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=73862
>
> Signed-off-by: Kristian Høgsberg
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index d6c41e6..9183dda 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -917,7 +917,6 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> if (driContextPriv) {
>struct gl_context *ctx = &brw->ctx;
>struct gl_framebuffer *fb, *readFb;
> - struct intel_renderbuffer *rb = NULL;
>
>if (driDrawPriv == NULL && driReadPriv == NULL) {
> fb = _mesa_get_incomplete_framebuffer();
> @@ -925,7 +924,6 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
>} else {
> fb = driDrawPriv->driverPrivate;
> readFb = driReadPriv->driverPrivate;
> - rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
> driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
> driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
>}
> @@ -937,11 +935,11 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
>intel_gles3_srgb_workaround(brw, fb);
>intel_gles3_srgb_workaround(brw, readFb);
>
> - if (rb && !rb->mt) {
> - /* If we don't have buffers for the drawable yet, force a call to
> - * getbuffers here so we can have a default drawable size. */
> + /* If the context viewport hasn't been initialized, force a call out to
> + * the loader to get buffers so we have a drawable size for the initial
> + * viewport. */
> + if (!brw->ctx.ViewportInitialized && fb->Width == 0 && fb->Height == 0)
> intel_prepare_render(brw);
> - }
>
>_mesa_make_current(ctx, fb, readFb);
> } else {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Correct test for depth parameter for checking if dimension is legal
Fixes the tests for the depth parameter for TexImage3D calls when the
target type is GL_TEXTURE_2D_ARRAY or GL_TEXTURE_CUBE_MAP_ARRAY
so that a depth value of 0 is accepted. Previously, the check
incorrectly required the depth argument to be atleast 1.
---
src/mesa/main/teximage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 9c3f1e8..8e2f057 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1481,7 +1481,7 @@ _mesa_legal_texture_dimensions(struct gl_context *ctx,
GLenum target,
return GL_FALSE;
if (height < 2 * border || height > 2 * border + maxSize)
return GL_FALSE;
- if (depth < 1 || depth > ctx->Const.MaxArrayTextureLayers)
+ if (depth < 0 || depth > ctx->Const.MaxArrayTextureLayers)
return GL_FALSE;
if (!ctx->Extensions.ARB_texture_non_power_of_two) {
if (width > 0 && !_mesa_is_pow_two(width - 2 * border))
@@ -1498,7 +1498,7 @@ _mesa_legal_texture_dimensions(struct gl_context *ctx,
GLenum target,
return GL_FALSE;
if (height < 2 * border || height > 2 * border + maxSize)
return GL_FALSE;
- if (depth < 1 || depth > ctx->Const.MaxArrayTextureLayers || depth % 6)
+ if (depth < 0 || depth > ctx->Const.MaxArrayTextureLayers || depth % 6)
return GL_FALSE;
if (width != height)
return GL_FALSE;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/blorp: do not use unnecessary hw-blending support
This is really not needed as blorp blit programs already sample
XRGB normally and get alpha channel set to 1.0 automatically by
the sampler engine. This is simply copied directly to the payload
of the render target write message and hence there is no need for
any additional blending support from the pixel processing pipeline.
Fixes recently modified piglit test gl-3.2-layered-rendering-blit
on IVB. No regressions on IVB.
This is effectively revert of c0554141a9b831b4e614747104dcbbe0fe489b9d:
i965/blorp: Support overriding destination alpha to 1.0.
Currently, Blorp requires the source and destination formats to be
equal. However, we'd really like to be able to blit between XRGB and
ARGB formats; our BLT engine paths have supported this for a long time.
For ARGB -> XRGB, nothing needs to occur: the missing alpha is already
interpreted as 1.0. For XRGB -> ARGB, we need to smash the alpha
channel to 1.0 when writing the destination colors. This is fairly
straightforward with blending.
For now, this code is never used, as the source and destination formats
still must be equal. The next patch will relax that restriction.
NOTE: This is a candidate for the 9.1 branch.
CC: Ian Romanick
CC: Kenneth Graunke
CC: Martin Steigerwald
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 20
1 file changed, 20 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index 90b9fbb..4222fa8 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -254,26 +254,6 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
blend->blend1.write_disable_b = params->color_write_disable[2];
blend->blend1.write_disable_a = params->color_write_disable[3];
- /* When blitting from an XRGB source to a ARGB destination, we need to
-* interpret the missing channel as 1.0. Blending can do that for us:
-* we simply use the RGB values from the fragment shader ("source RGB"),
-* but smash the alpha channel to 1.
-*/
- if (params->src.mt &&
- _mesa_get_format_bits(params->dst.mt->format, GL_ALPHA_BITS) > 0 &&
- _mesa_get_format_bits(params->src.mt->format, GL_ALPHA_BITS) == 0) {
- blend->blend0.blend_enable = 1;
- blend->blend0.ia_blend_enable = 1;
-
- blend->blend0.blend_func = BRW_BLENDFUNCTION_ADD;
- blend->blend0.ia_blend_func = BRW_BLENDFUNCTION_ADD;
-
- blend->blend0.source_blend_factor = BRW_BLENDFACTOR_SRC_COLOR;
- blend->blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
- blend->blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
- blend->blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
- }
-
return cc_blend_state_offset;
}
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 14/16] radeonsi: We don't support indirect addressing of shader inputs/outputs
The function "emit_fetch" in radeon_setup_tgsi_llvm.c seems to implement indirect addressing of everything but constants. Marek On Mon, Jan 27, 2014 at 3:14 AM, Michel Dänzer wrote: > On Fre, 2014-01-24 at 23:54 +0100, Marek Olšák wrote: >> Please can this be done for the geometry shader only? > > I wrote it like this because I couldn't find any driver code dealing > with indirect addressing of inputs or outputs. Where is it? > > > -- > Earthling Michel Dänzer| http://www.amd.com > Libre software enthusiast |Mesa and X developer > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73946] scanout broken on radeon SI (OLAND)
https://bugs.freedesktop.org/show_bug.cgi?id=73946 --- Comment #9 from Marek Olšák --- (In reply to comment #8) > (In reply to comment #7) > > Could you tell me at which point exactly you added the PIPE_BIND_SCANOUT > > flag? > > I didn't. I modified > src/gallium/drivers/radeon/r600_texture.c:r600_surface_init() to set > RADEON_SURF_SCANOUT regardless of PIPE_BIND_SCANOUT. As that worked around > the problem, I assumed that PIPE_BIND_SCANOUT wasn't set when it should be. > > > Right now though, I'm not able to reproduce the weston problem even with an > unpatched radeonsi. Not sure what changed... I fixed Wayland/Weston with this patch: http://cgit.freedesktop.org/mesa/mesa/commit/?id=0b37737cc3e7042bffb7c8a0e6a5c822bb806977 -- 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] gallium/rtasm: handle mmap failures appropriately
Ping :)
On 19/01/14 23:53, Emil Velikov wrote:
> For a variety of reasons mmap (selinux and pax to name
> a few) and can fail and with current code. This will
> result in a crash in the driver, if not worse.
>
> This has been the case since the inception of the
> gallium copy of rtasm.
>
> Cc: 9.1 9.2 10.0
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73473
> Signed-off-by: Emil Velikov
> ---
> v2: droped the selinux part, leaving only the crucial mmap check
>
> Gents can someone take a look at this trivial patch.
>
> Cheers,
> Emil
> ---
> src/gallium/auxiliary/rtasm/rtasm_execmem.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> index edc1b66..8c3dbef 100644
> --- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> +++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> @@ -69,7 +69,7 @@ static struct mem_block *exec_heap = NULL;
> static unsigned char *exec_mem = NULL;
>
>
> -static void
> +static int
> init_heap(void)
> {
> if (!exec_heap)
> @@ -79,6 +79,8 @@ init_heap(void)
>exec_mem = (unsigned char *) mmap(0, EXEC_HEAP_SIZE,
> PROT_EXEC | PROT_READ | PROT_WRITE,
> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> +
> + return (exec_mem != MAP_FAILED);
> }
>
>
> @@ -90,7 +92,8 @@ rtasm_exec_malloc(size_t size)
>
> pipe_mutex_lock(exec_mutex);
>
> - init_heap();
> + if (!init_heap())
> + goto bail;
>
> if (exec_heap) {
>size = (size + 31) & ~31; /* next multiple of 32 bytes */
> @@ -101,7 +104,8 @@ rtasm_exec_malloc(size_t size)
>addr = exec_mem + block->ofs;
> else
>debug_printf("rtasm_exec_malloc failed\n");
> -
> +
> +bail:
> pipe_mutex_unlock(exec_mutex);
>
> return addr;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73631] es2tri fragment shader did not compile AMD ARUBA
https://bugs.freedesktop.org/show_bug.cgi?id=73631 Emil Velikov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Emil Velikov --- Thanks for the report Aaron, the issue should be fixed with commit 18a2f916afcb482458d03b468b46cf271953d789 Author: Emil Velikov Date: Sun Jan 19 16:28:33 2014 + opengles2/es2tri: add precision qualifier to the fragment shader The missing qualifier causes failure during the compilation stage. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73631 -- 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] gallium/rtasm: handle mmap failures appropriately
On Mon, Jan 27, 2014 at 12:57 PM, Emil Velikov wrote:
> Ping :)
>
> On 19/01/14 23:53, Emil Velikov wrote:
>> For a variety of reasons mmap (selinux and pax to name
>> a few) and can fail and with current code. This will
>> result in a crash in the driver, if not worse.
>>
>> This has been the case since the inception of the
>> gallium copy of rtasm.
>>
>> Cc: 9.1 9.2 10.0
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73473
>> Signed-off-by: Emil Velikov
>> ---
>> v2: droped the selinux part, leaving only the crucial mmap check
>>
>> Gents can someone take a look at this trivial patch.
>>
>> Cheers,
>> Emil
Reviewed-by: Jakob Bornecrantz
>> ---
>> src/gallium/auxiliary/rtasm/rtasm_execmem.c | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
>> b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
>> index edc1b66..8c3dbef 100644
>> --- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
>> +++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
>> @@ -69,7 +69,7 @@ static struct mem_block *exec_heap = NULL;
>> static unsigned char *exec_mem = NULL;
>>
>>
>> -static void
>> +static int
>> init_heap(void)
>> {
>> if (!exec_heap)
>> @@ -79,6 +79,8 @@ init_heap(void)
>>exec_mem = (unsigned char *) mmap(0, EXEC_HEAP_SIZE,
>> PROT_EXEC | PROT_READ | PROT_WRITE,
>> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>> +
>> + return (exec_mem != MAP_FAILED);
>> }
>>
>>
>> @@ -90,7 +92,8 @@ rtasm_exec_malloc(size_t size)
>>
>> pipe_mutex_lock(exec_mutex);
>>
>> - init_heap();
>> + if (!init_heap())
>> + goto bail;
>>
>> if (exec_heap) {
>>size = (size + 31) & ~31; /* next multiple of 32 bytes */
>> @@ -101,7 +104,8 @@ rtasm_exec_malloc(size_t size)
>>addr = exec_mem + block->ofs;
>> else
>>debug_printf("rtasm_exec_malloc failed\n");
>> -
>> +
>> +bail:
>> pipe_mutex_unlock(exec_mutex);
>>
>> return addr;
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos] opengles2/es2tri: add precision qualifier to the fragment shader
On 21/01/14 17:26, Emil Velikov wrote:
> On 20/01/14 15:16, Brian Paul wrote:
>> On 01/19/2014 08:34 AM, Emil Velikov wrote:
>>> The missing qualifier causes failure during the compilation stage.
>>>
>>> Bugzilla:
>>> https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D73631&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=XLIZ2HrbWqVFmoj1r3Eja4KyN0tfIdzTujHTgApHnYg%3D%0A&s=cb63d2bc49ebf80596286653cf46895006092b22e372dadff893fab49b71c6ff
>>>
>>> Signed-off-by: Emil Velikov
>>> ---
>>> src/egl/opengles2/es2tri.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/src/egl/opengles2/es2tri.c b/src/egl/opengles2/es2tri.c
>>> index 6dcc1b8..349a576 100644
>>> --- a/src/egl/opengles2/es2tri.c
>>> +++ b/src/egl/opengles2/es2tri.c
>>> @@ -139,6 +139,7 @@ static void
>>> create_shaders(void)
>>> {
>>> static const char *fragShaderText =
>>> + "precision mediump float;\n"
>>> "varying vec4 v_color;\n"
>>> "void main() {\n"
>>> " gl_FragColor = v_color;\n"
>>>
>>
>> Reviewed-by: Brian Paul
>>
>> I think I wrote some of those old tests. You might want to check the
>> rest for the same issue if you haven't already.
>>
> To be honest I haven't check. I'll look through the rest opengles 2.0
> demos later on this week.
>
AFAICS, this was the only opengles2 test that was having the issue.
Pushed to master
2ca4555..18a2f91 master -> master
-Emil
> -Emil
>> -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] loader: Get driver name from udev hwdb when available
Hi Kristian,
On 20/01/14 20:42, Kristian Høgsberg wrote:
> The udev hwdb is a mechanism for applying udev properties to devices at
> hotplug time. The hwdb text files are compiled into a binary database
> that lets udev efficiently look up and apply properties to devices that
> match a given modalias.
>
> This patch exports the mesa PCI ID tables as hwdb files and extends the
> loader code to try to look up the driver name from the DRI_DRIVER udev
> property. The benefits to this approach are:
>
> - No longer PCI specific, any device udev can match with a modalias can
>be assigned a DRI driver.
>
> - Available outside mesa; writing a DRI2 compatible generic DDX with
>glamor needs to know the DRI driver name to send to the client.
>
> - Can be overridden by custom udev rules.
>
> Signed-off-by: Kristian Høgsberg
> ---
> configure.ac | 14 ++
> src/loader/Makefile.am | 15 +++
> src/loader/dump-hwdb.c | 31 +++
> src/loader/loader.c| 33 +
> src/loader/loader.h| 2 +-
> 5 files changed, 86 insertions(+), 9 deletions(-)
> create mode 100644 src/loader/dump-hwdb.c
>
> diff --git a/configure.ac b/configure.ac
> index d9e1896..8670908 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -771,6 +771,20 @@ if test "x$have_libdrm" = xyes; then
> DEFINES="$DEFINES -DHAVE_LIBDRM"
> fi
>
> +# This /lib prefix does not change with 32/64 bits it's always /lib
> +case "$prefix" in
> +/usr) default_udevhwdbdir=/lib/udev/hwdb.d ;;
> +NONE) default_udevhwdbdir=${ac_default_prefix}/lib/udev/hwdb.d ;;
> +*)default_udevhwdbdir=$prefix/lib/udev/hwdb.d ;;
> +esac
> +
> +AC_ARG_WITH([udev-hwdb-dir],
> +[AS_HELP_STRING([--with-udev-hwdb-dir=DIR],
> +[directory for the udev hwdb @<:@/lib/udev/hwdb.d@:>@])],
> +[udevhwdbdir="$withval"],
> +[udevhwdbdir=$default_udevhwdbdir])
> +AC_SUBST([udevhwdbdir])
> +
> PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED],
>have_libudev=yes, have_libudev=no)
>
> diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am
> index 371dd57..bf3918b 100644
> --- a/src/loader/Makefile.am
> +++ b/src/loader/Makefile.am
> @@ -44,3 +44,18 @@ libloader_la_LIBADD += \
> endif
>
> libloader_la_SOURCES = $(LOADER_C_FILES)
> +
> +
> +noinst_PROGRAMS = dump-hwdb
> +dump_hwdb_SOURCES = dump-hwdb.c
> +dump_hwdb_CPPFLAGS = -I$(top_srcdir)/include
> +
> +dist_udevhwdb_DATA = 20-dri-driver.hwdb
> +
> +# Update hwdb on installation. Do not bother if installing
> +# in DESTDIR, since this is likely for packaging purposes.
> +install-data-hook:
> + -test -n "$(DESTDIR)" || udevadm hwdb --update
> +
> +20-dri-driver.hwdb : dump-hwdb
> + $(builddir)/dump-hwdb > $@
> diff --git a/src/loader/dump-hwdb.c b/src/loader/dump-hwdb.c
> new file mode 100644
> index 000..d48452d
> --- /dev/null
> +++ b/src/loader/dump-hwdb.c
> @@ -0,0 +1,31 @@
> +#include
> +#include
> +
> +#define DRIVER_MAP_DRI2_ONLY
Mesa does not need/make use of DRIVER_MAP* since the loader patches.
Feel free to drop the above define.
> +#define __IS_LOADER
> +
> +#include "loader.h"
> +#include "pci_ids/pci_id_driver_map.h"
> +
> +#define PROP_NAME "DRI_DRIVER"
> +
> +int main(int argc, char *argv[])
> +{
> + int i, j;
> +
> + for (i = 0; driver_map[i].driver; i++) {
> + if (driver_map[i].num_chips_ids == -1) {
> + /* Add a match for display base class (bc03) for drivers that don't
> + * export per-device IDs (nouveau) */
> + printf("pci:v%08x*bc03*\n " PROP_NAME "=%s\n\n",
> +driver_map[i].vendor_id, driver_map[i].driver);
> + continue;
> + }
> +
> + for (j = 0; j < driver_map[i].num_chips_ids; j++)
> + printf("pci:v%08xd%08x*\n " PROP_NAME "=%s\n\n",
> +driver_map[i].vendor_id,
> +driver_map[i].chip_ids[j],
> +driver_map[i].driver);
> + }
Can you please add a return 0; to silence compiler warnings.
Thanks
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] dri: Fix the logger error message handling.
On 23/01/14 23:12, Eric Anholt wrote:
> Since the loader changes, there has been a compiler warning that the
> prototype didn't match. It turns out that if a loader error message was
> ever thrown, you'd segfault because of trying to use the warning level as
> a format string.
Truly sorry about that one gents.
FWIW Reviewed-by: Emil Velikov
> ---
> src/glx/dri3_glx.c | 2 +-
> src/glx/dri_common.c | 25 +
> src/glx/dri_common.h | 10 --
> 3 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
> index 3e82965..2a9f0b7 100644
> --- a/src/glx/dri3_glx.c
> +++ b/src/glx/dri3_glx.c
> @@ -1803,7 +1803,7 @@ dri3_create_display(Display * dpy)
> pdp->base.destroyDisplay = dri3_destroy_display;
> pdp->base.createScreen = dri3_create_screen;
>
> - loader_set_logger(ErrorMessageF);
> + loader_set_logger(dri_message);
> i = 0;
>
> pdp->loader_extensions[i++] = &imageLoaderExtension.base;
> diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
> index b5058c9..93c45ea 100644
> --- a/src/glx/dri_common.c
> +++ b/src/glx/dri_common.c
> @@ -40,6 +40,7 @@
> #include
> #include "glxclient.h"
> #include "dri_common.h"
> +#include "loader.h"
>
> #ifndef RTLD_NOW
> #define RTLD_NOW 0
> @@ -48,6 +49,30 @@
> #define RTLD_GLOBAL 0
> #endif
>
> +_X_HIDDEN void
> +dri_message(int level, const char *f, ...)
> +{
> + va_list args;
> + int threshold = _LOADER_WARNING;
> + const char *libgl_debug;
> +
> + libgl_debug = getenv("LIBGL_DEBUG");
> + if (libgl_debug) {
> + if (strstr(libgl_debug, "quiet"))
> + threshold = _LOADER_FATAL;
> + else if (strstr(libgl_debug, "verbose"))
> + threshold = _LOADER_DEBUG;
> + }
> +
> + /* Note that the _LOADER_* levels are lower numbers for more severe. */
> + if (level <= threshold) {
> + fprintf(stderr, "libGL%s: ", level <= _LOADER_WARNING ? " error" : "");
> + va_start(args, f);
> + vfprintf(stderr, f, args);
> + va_end(args);
> + }
> +}
> +
> /**
> * Print informational message to stderr if LIBGL_DEBUG is set to
> * "verbose".
> diff --git a/src/glx/dri_common.h b/src/glx/dri_common.h
> index 4fe0d3f..425d89f 100644
> --- a/src/glx/dri_common.h
> +++ b/src/glx/dri_common.h
> @@ -39,6 +39,12 @@
> #include
> #include
>
> +#if (__GNUC__ >= 3)
> +#define PRINTFLIKE(f, a) __attribute__ ((format(__printf__, f, a)))
> +#else
> +#define PRINTFLIKE(f, a)
> +#endif
> +
> typedef struct __GLXDRIconfigPrivateRec __GLXDRIconfigPrivate;
>
> struct __GLXDRIconfigPrivateRec
> @@ -61,10 +67,10 @@ driReleaseDrawables(struct glx_context *gc);
>
> extern const __DRIsystemTimeExtension systemTimeExtension;
>
> -extern void InfoMessageF(const char *f, ...);
> +extern void dri_message(int level, const char *f, ...) PRINTFLIKE(2, 3);
>
> +extern void InfoMessageF(const char *f, ...);
> extern void ErrorMessageF(const char *f, ...);
> -
> extern void CriticalErrorMessageF(const char *f, ...);
>
> extern void *driOpenDriver(const char *driverName);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] loader: Add missing \n on message printing
Cover both loader and glx/dri_glx
Drop \n from the default loader logger
Signed-off-by: Emil Velikov
---
Hi Eric
The missing \n was inherited from the dri3_common.c which
on itself seems to have come from from the legacy dri_glx.c
codebase.
This patch should cover all the leftout cases.
Feel free to pick this patch if you're happy with it.
Emil
src/glx/dri_glx.c | 8
src/loader/loader.c | 23 +++
2 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index 2e00bf0..03ecc5b 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -418,7 +418,7 @@ CallCreateNewScreen(Display *dpy, int scrn, struct
dri_screen *psc,
&framebuffer.size, &framebuffer.stride,
&framebuffer.dev_priv_size,
&framebuffer.dev_priv)) {
- ErrorMessageF("XF86DRIGetDeviceInfo failed");
+ ErrorMessageF("XF86DRIGetDeviceInfo failed\n");
goto handle_error;
}
@@ -429,7 +429,7 @@ CallCreateNewScreen(Display *dpy, int scrn, struct
dri_screen *psc,
status = drmMap(fd, hFB, framebuffer.size,
(drmAddressPtr) & framebuffer.base);
if (status != 0) {
- ErrorMessageF("drmMap of framebuffer failed (%s)", strerror(-status));
+ ErrorMessageF("drmMap of framebuffer failed (%s)\n", strerror(-status));
goto handle_error;
}
@@ -438,7 +438,7 @@ CallCreateNewScreen(Display *dpy, int scrn, struct
dri_screen *psc,
*/
status = drmMap(fd, hSAREA, SAREA_MAX, &pSAREA);
if (status != 0) {
- ErrorMessageF("drmMap of SAREA failed (%s)", strerror(-status));
+ ErrorMessageF("drmMap of SAREA failed (%s)\n", strerror(-status));
goto handle_error;
}
@@ -453,7 +453,7 @@ CallCreateNewScreen(Display *dpy, int scrn, struct
dri_screen *psc,
&driver_configs, psc);
if (psp == NULL) {
- ErrorMessageF("Calling driver entry point failed");
+ ErrorMessageF("Calling driver entry point failed\n");
goto handle_error;
}
diff --git a/src/loader/loader.c b/src/loader/loader.c
index a5bd769..ceee6b7 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -83,7 +83,6 @@ static void default_logger(int level, const char *fmt, ...)
va_start(args, fmt);
vfprintf(stderr, fmt, args);
va_end(args);
- fprintf(stderr, "\n");
}
}
@@ -99,14 +98,14 @@ udev_device_new_from_fd(struct udev *udev, int fd)
struct stat buf;
if (fstat(fd, &buf) < 0) {
- log_(_LOADER_WARNING, "MESA-LOADER: failed to stat fd %d", fd);
+ log_(_LOADER_WARNING, "MESA-LOADER: failed to stat fd %d\n", fd);
return NULL;
}
device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
if (device == NULL) {
log_(_LOADER_WARNING,
- "MESA-LOADER: could not create udev device for fd %d", fd);
+ "MESA-LOADER: could not create udev device for fd %d\n", fd);
return NULL;
}
@@ -129,14 +128,14 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int
*chip_id)
parent = udev_device_get_parent(device);
if (parent == NULL) {
- log_(_LOADER_WARNING, "MESA-LOADER: could not get parent device");
+ log_(_LOADER_WARNING, "MESA-LOADER: could not get parent device\n");
goto out;
}
pci_id = udev_device_get_property_value(parent, "PCI_ID");
if (pci_id == NULL ||
sscanf(pci_id, "%x:%x", vendor_id, chip_id) != 2) {
- log_(_LOADER_WARNING, "MESA-LOADER: malformed or no PCI ID");
+ log_(_LOADER_WARNING, "MESA-LOADER: malformed or no PCI ID\n");
*chip_id = -1;
goto out;
}
@@ -166,11 +165,11 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int
*chip_id)
version = drmGetVersion(fd);
if (!version) {
- log_(_LOADER_WARNING, "MESA-LOADER: invalid drm fd");
+ log_(_LOADER_WARNING, "MESA-LOADER: invalid drm fd\n");
return FALSE;
}
if (!version->name) {
- log_(_LOADER_WARNING, "MESA-LOADER: unable to determine the driver
name");
+ log_(_LOADER_WARNING, "MESA-LOADER: unable to determine the driver
name\n");
drmFreeVersion(version);
return FALSE;
}
@@ -186,7 +185,7 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int
*chip_id)
gp.value = chip_id;
ret = drmCommandWriteRead(fd, DRM_I915_GETPARAM, &gp, sizeof(gp));
if (ret) {
- log_(_LOADER_WARNING, "MESA-LOADER: failed to get param for i915");
+ log_(_LOADER_WARNING, "MESA-LOADER: failed to get param for i915\n");
*chip_id = -1;
}
}
@@ -201,7 +200,7 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int
*chip_id)
info.value = (unsigned long) chip_id;
ret = drmCommandWriteRead(fd, DRM_RADEON_INFO, &info, sizeof(info));
if (ret) {
- log_(_LOADER_WARNING, "MESA-LOADER: failed to get info for radeon");
+ log_(
Re: [Mesa-dev] [PATCH 02/16] radeonsi: Initial geometry shader support
On Sat, Jan 25, 2014 at 2:21 AM, Marek Olšák wrote: > On Fri, Jan 24, 2014 at 10:19 PM, Marek Olšák wrote: >> 1) Do we really have to have so much code inside #if...#endif? Can we >> always compile everything and just not set the pipe_context functions >> if LLVM < 3.5 and the same for get_(shader_)param? You can even do it >> without the preprocessor, e.g. if (HAVE_LLVM >= 0x0305) ... >> >> 2) Sooner or later we'll have GL_ARB_shader_storage_buffer_object, >> which adds shader read-write resources. Maybe it would be better to >> put the ring buffers in a new array of descriptors and leave the >> constant buffers with the READ-only usage. The new array of >> descriptors could later be used for OpenGL read-write resources in >> addition to being used for ring buffers. > > Actually, my original plan was to put stream-out buffers after OpenGL > shader-storage buffers. We'll probably want to use the same array for > OpenGL shader atomic counters as well. > > 3) In si_init_gs_rings: > - could you please use readable decimal numbers for specifying the > sizes? Like 1024 * 1024 * ... > - could you please add an assertion to make sure the function is not > called twice to prevent potential memory leaks > - isn't 64 MB too many for a ring buffer? > > 4) If the GS is disabled, GS_OUT_PRIM_TYPE should be compatible with > the draw_info primitive for transform feedback to work properly. It > was a requirement on R600-Evergreen. Not sure if it applies to SI too. > > Please bear with me, I still haven't fully reviewed the whole file > si_shader.c, but it's too late to do it today. FYI, I'm done reviewing this. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74098] [clover] adaptor.hpp:47:16: error: function cannot return function type 'std::vector > (unsigned long, unsigned long)'
https://bugs.freedesktop.org/show_bug.cgi?id=74098 --- Comment #1 from Tom Stellard --- Which version of clang were you using? -- 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] r600g/compute: Emit DEALLOC_STATE on cayman after dispatching a compute shader.
From: Tom Stellard
This is necessary to prevent the next SURFACE_SYNC packet from
hanging the GPU.
https://bugs.freedesktop.org/show_bug.cgi?id=73418
CC: "9.2" "10.0"
---
src/gallium/drivers/r600/evergreen_compute.c | 9 -
src/gallium/drivers/r600/evergreend.h| 1 +
src/gallium/drivers/r600/r600_hw_context.c | 4 +---
src/gallium/drivers/r600/r600_pipe.h | 10 --
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index a2db69b..70efe5c 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -489,7 +489,14 @@ static void compute_emit_cs(struct r600_context *ctx,
const uint *block_layout,
ctx->b.flags = 0;
if (ctx->b.chip_class >= CAYMAN) {
- ctx->skip_surface_sync_on_next_cs_flush = true;
+ cs->buf[cs->cdw++] = PKT3(PKT3_EVENT_WRITE, 0, 0);
+ cs->buf[cs->cdw++] = EVENT_TYPE(EVENT_TYPE_CS_PARTIAL_FLUSH) |
EVENT_INDEX(4);
+ /* DEALLOC_STATE prevents the GPU from hanging when a
+* SURFACE_SYNC packet is emitted some time after a
DISPATCH_DIRECT
+* with any of the CB*_DEST_BASE_ENA or DB_DEST_BASE_ENA bits
set.
+*/
+ cs->buf[cs->cdw++] = PKT3C(PKT3_DEALLOC_STATE, 0, 0);
+ cs->buf[cs->cdw++] = 0;
}
#if 0
diff --git a/src/gallium/drivers/r600/evergreend.h
b/src/gallium/drivers/r600/evergreend.h
index 2f2e145..9ba3db7 100644
--- a/src/gallium/drivers/r600/evergreend.h
+++ b/src/gallium/drivers/r600/evergreend.h
@@ -63,6 +63,7 @@
#define R600_TEXEL_PITCH_ALIGNMENT_MASK0x7
#define PKT3_NOP 0x10
+#define PKT3_DEALLOC_STATE 0x14
#define PKT3_DISPATCH_DIRECT 0x15
#define PKT3_DISPATCH_INDIRECT 0x16
#define PKT3_INDIRECT_BUFFER_END 0x17
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index da90d63..7afd4b0 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -293,7 +293,7 @@ void r600_flush_emit(struct r600_context *rctx)
S_0085F0_SMX_ACTION_ENA(1);
}
- if (cp_coher_cntl && !rctx->skip_surface_sync_on_next_cs_flush) {
+ if (cp_coher_cntl) {
cs->buf[cs->cdw++] = PKT3(PKT3_SURFACE_SYNC, 3, 0);
cs->buf[cs->cdw++] = cp_coher_cntl; /* CP_COHER_CNTL */
cs->buf[cs->cdw++] = 0x; /* CP_COHER_SIZE */
@@ -354,8 +354,6 @@ void r600_context_flush(struct r600_context *ctx, unsigned
flags)
/* Flush the CS. */
ctx->b.ws->cs_flush(ctx->b.rings.gfx.cs, flags,
ctx->screen->cs_count++);
-
- ctx->skip_surface_sync_on_next_cs_flush = false;
}
void r600_begin_new_cs(struct r600_context *ctx)
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 7350479..88b0860 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -499,16 +499,6 @@ struct r600_context {
void*sb_context;
struct r600_isa *isa;
-
- /* Work-around for flushing problems with compute shaders on Cayman:
-* Emitting a SURFACE_SYNC packet with any of the CB*_DEST_BASE_ENA
-* or DB_DEST_BASE_ENA bits set after dispatching a compute shader
-* hangs the GPU.
-*
-* Setting this to true will prevent r600_flush_emit() from emitting
-* a SURFACE_SYNC packet. This field will be cleared by
-* by r600_context_flush() after flushing the command stream. */
- boolean skip_surface_sync_on_next_cs_flush;
};
static INLINE void r600_emit_command_buffer(struct radeon_winsys_cs *cs,
--
1.8.1.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/compute: Emit DEALLOC_STATE on cayman after dispatching a compute shader.
Reviewed-by: Marek Olšák
Marek
On Mon, Jan 27, 2014 at 3:05 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> This is necessary to prevent the next SURFACE_SYNC packet from
> hanging the GPU.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=73418
>
> CC: "9.2" "10.0"
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 9 -
> src/gallium/drivers/r600/evergreend.h| 1 +
> src/gallium/drivers/r600/r600_hw_context.c | 4 +---
> src/gallium/drivers/r600/r600_pipe.h | 10 --
> 4 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c
> b/src/gallium/drivers/r600/evergreen_compute.c
> index a2db69b..70efe5c 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.c
> +++ b/src/gallium/drivers/r600/evergreen_compute.c
> @@ -489,7 +489,14 @@ static void compute_emit_cs(struct r600_context *ctx,
> const uint *block_layout,
> ctx->b.flags = 0;
>
> if (ctx->b.chip_class >= CAYMAN) {
> - ctx->skip_surface_sync_on_next_cs_flush = true;
> + cs->buf[cs->cdw++] = PKT3(PKT3_EVENT_WRITE, 0, 0);
> + cs->buf[cs->cdw++] = EVENT_TYPE(EVENT_TYPE_CS_PARTIAL_FLUSH)
> | EVENT_INDEX(4);
> + /* DEALLOC_STATE prevents the GPU from hanging when a
> +* SURFACE_SYNC packet is emitted some time after a
> DISPATCH_DIRECT
> +* with any of the CB*_DEST_BASE_ENA or DB_DEST_BASE_ENA bits
> set.
> +*/
> + cs->buf[cs->cdw++] = PKT3C(PKT3_DEALLOC_STATE, 0, 0);
> + cs->buf[cs->cdw++] = 0;
> }
>
> #if 0
> diff --git a/src/gallium/drivers/r600/evergreend.h
> b/src/gallium/drivers/r600/evergreend.h
> index 2f2e145..9ba3db7 100644
> --- a/src/gallium/drivers/r600/evergreend.h
> +++ b/src/gallium/drivers/r600/evergreend.h
> @@ -63,6 +63,7 @@
> #define R600_TEXEL_PITCH_ALIGNMENT_MASK0x7
>
> #define PKT3_NOP 0x10
> +#define PKT3_DEALLOC_STATE 0x14
> #define PKT3_DISPATCH_DIRECT 0x15
> #define PKT3_DISPATCH_INDIRECT 0x16
> #define PKT3_INDIRECT_BUFFER_END 0x17
> diff --git a/src/gallium/drivers/r600/r600_hw_context.c
> b/src/gallium/drivers/r600/r600_hw_context.c
> index da90d63..7afd4b0 100644
> --- a/src/gallium/drivers/r600/r600_hw_context.c
> +++ b/src/gallium/drivers/r600/r600_hw_context.c
> @@ -293,7 +293,7 @@ void r600_flush_emit(struct r600_context *rctx)
> S_0085F0_SMX_ACTION_ENA(1);
> }
>
> - if (cp_coher_cntl && !rctx->skip_surface_sync_on_next_cs_flush) {
> + if (cp_coher_cntl) {
> cs->buf[cs->cdw++] = PKT3(PKT3_SURFACE_SYNC, 3, 0);
> cs->buf[cs->cdw++] = cp_coher_cntl; /* CP_COHER_CNTL */
> cs->buf[cs->cdw++] = 0x; /* CP_COHER_SIZE */
> @@ -354,8 +354,6 @@ void r600_context_flush(struct r600_context *ctx,
> unsigned flags)
>
> /* Flush the CS. */
> ctx->b.ws->cs_flush(ctx->b.rings.gfx.cs, flags,
> ctx->screen->cs_count++);
> -
> - ctx->skip_surface_sync_on_next_cs_flush = false;
> }
>
> void r600_begin_new_cs(struct r600_context *ctx)
> diff --git a/src/gallium/drivers/r600/r600_pipe.h
> b/src/gallium/drivers/r600/r600_pipe.h
> index 7350479..88b0860 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -499,16 +499,6 @@ struct r600_context {
>
> void*sb_context;
> struct r600_isa *isa;
> -
> - /* Work-around for flushing problems with compute shaders on Cayman:
> -* Emitting a SURFACE_SYNC packet with any of the CB*_DEST_BASE_ENA
> -* or DB_DEST_BASE_ENA bits set after dispatching a compute shader
> -* hangs the GPU.
> -*
> -* Setting this to true will prevent r600_flush_emit() from emitting
> -* a SURFACE_SYNC packet. This field will be cleared by
> -* by r600_context_flush() after flushing the command stream. */
> - boolean skip_surface_sync_on_next_cs_flush;
> };
>
> static INLINE void r600_emit_command_buffer(struct radeon_winsys_cs *cs,
> --
> 1.8.1.5
>
> ___
> 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] R600/SI: Add pattern for truncating i32 to i1
On Mon, Jan 27, 2014 at 04:43:14PM +0900, Michel Dänzer wrote: > On Fre, 2014-01-24 at 07:40 -0800, Tom Stellard wrote: > > On Fri, Jan 24, 2014 at 01:27:00PM +0900, Michel Dänzer wrote: > > > From: Michel Dänzer > > > > > > Fixes half a dozen piglit tests with radeonsi. > > > > > > Signed-off-by: Michel Dänzer > > > --- > > > lib/Target/R600/SIInstructions.td | 5 + > > > test/CodeGen/R600/trunc.ll| 10 ++ > > > 2 files changed, 15 insertions(+) > > > > > > diff --git a/lib/Target/R600/SIInstructions.td > > > b/lib/Target/R600/SIInstructions.td > > > index 03e7e32..b7b710f 100644 > > > --- a/lib/Target/R600/SIInstructions.td > > > +++ b/lib/Target/R600/SIInstructions.td > > > @@ -2126,6 +2126,11 @@ def : Pat < > > >(EXTRACT_SUBREG $a, sub0) > > > >; > > > > > > +def : Pat < > > > + (i1 (trunc i32:$a)), > > > + (V_CMP_EQ_I32_e64 (V_AND_B32_e32 (i32 1), $a), 1) > > > +>; > > > + > > > > I'm guessing you added V_CMP_EQ_I32_e64 in order to make the types match. > > Not really. The truncation is used for testing whether the LSB of an i32 > value is set, and storing the resulting boolean as an i1 value. My > pattern does this for the VGPRs in all thread of a wavefront in > parallel, storing the resulting boolean bits in a 64-bit SGPR. > Ok, I didn't realize this pattern was meant to be used with control flow instructions. The pattern is fine as is. The patch is: Reviewed-by: Tom Stellard > > > Try this pattern instead: > > > > def : Pat < > > (i1 (trunc i32:$a)), > > (COPY_TO_REGCLASS (V_AND_B32_e32 (i32 1), $a), VReg_32) > > I don't understand the idea behind your suggestion, can you elaborate? > Without the COPY_TO_REGCLASS, LLVM tablegen will complain because the output register of V_AND_V32_e32 (VReg_32) does not support i1 types. Adding the COPY_TO_REGCLASS allows tablegen to accept the pattern, because COPY_TO_REGCLASS is untyped. > Anyway, it fails for one of the relevant piglit tests: > > amd_vertex_shader_layer-layered-2d-texture-render: > /home/daenzer/src/llvm-git/llvm/lib/Target/R600/SIInstrInfo.cpp:133: virtual > void llvm::SIInstrInfo::copyPhysReg(llvm::MachineBasicBlock&, > llvm::MachineBasicBlock::iterator, llvm::DebugLoc, unsigned int, unsigned > int, bool) const: Assertion `AMDGPU::VReg_64RegClass.contains(SrcReg) || > AMDGPU::SReg_64RegClass.contains(SrcReg)' failed. > > > -- > Earthling Michel Dänzer| http://www.amd.com > Libre software enthusiast |Mesa and X developer > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/compute: Emit DEALLOC_STATE on cayman after dispatching a compute shader.
On Mon, Jan 27, 2014 at 9:05 AM, Tom Stellard wrote:
> From: Tom Stellard
>
> This is necessary to prevent the next SURFACE_SYNC packet from
> hanging the GPU.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=73418
>
> CC: "9.2" "10.0"
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 9 -
> src/gallium/drivers/r600/evergreend.h| 1 +
> src/gallium/drivers/r600/r600_hw_context.c | 4 +---
> src/gallium/drivers/r600/r600_pipe.h | 10 --
> 4 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c
> b/src/gallium/drivers/r600/evergreen_compute.c
> index a2db69b..70efe5c 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.c
> +++ b/src/gallium/drivers/r600/evergreen_compute.c
> @@ -489,7 +489,14 @@ static void compute_emit_cs(struct r600_context *ctx,
> const uint *block_layout,
> ctx->b.flags = 0;
>
> if (ctx->b.chip_class >= CAYMAN) {
> - ctx->skip_surface_sync_on_next_cs_flush = true;
> + cs->buf[cs->cdw++] = PKT3(PKT3_EVENT_WRITE, 0, 0);
> + cs->buf[cs->cdw++] = EVENT_TYPE(EVENT_TYPE_CS_PARTIAL_FLUSH)
> | EVENT_INDEX(4);
> + /* DEALLOC_STATE prevents the GPU from hanging when a
> +* SURFACE_SYNC packet is emitted some time after a
> DISPATCH_DIRECT
> +* with any of the CB*_DEST_BASE_ENA or DB_DEST_BASE_ENA bits
> set.
> +*/
> + cs->buf[cs->cdw++] = PKT3C(PKT3_DEALLOC_STATE, 0, 0);
> + cs->buf[cs->cdw++] = 0;
> }
>
> #if 0
> diff --git a/src/gallium/drivers/r600/evergreend.h
> b/src/gallium/drivers/r600/evergreend.h
> index 2f2e145..9ba3db7 100644
> --- a/src/gallium/drivers/r600/evergreend.h
> +++ b/src/gallium/drivers/r600/evergreend.h
> @@ -63,6 +63,7 @@
> #define R600_TEXEL_PITCH_ALIGNMENT_MASK0x7
>
> #define PKT3_NOP 0x10
> +#define PKT3_DEALLOC_STATE 0x14
> #define PKT3_DISPATCH_DIRECT 0x15
> #define PKT3_DISPATCH_INDIRECT 0x16
> #define PKT3_INDIRECT_BUFFER_END 0x17
> diff --git a/src/gallium/drivers/r600/r600_hw_context.c
> b/src/gallium/drivers/r600/r600_hw_context.c
> index da90d63..7afd4b0 100644
> --- a/src/gallium/drivers/r600/r600_hw_context.c
> +++ b/src/gallium/drivers/r600/r600_hw_context.c
> @@ -293,7 +293,7 @@ void r600_flush_emit(struct r600_context *rctx)
> S_0085F0_SMX_ACTION_ENA(1);
> }
>
> - if (cp_coher_cntl && !rctx->skip_surface_sync_on_next_cs_flush) {
> + if (cp_coher_cntl) {
> cs->buf[cs->cdw++] = PKT3(PKT3_SURFACE_SYNC, 3, 0);
> cs->buf[cs->cdw++] = cp_coher_cntl; /* CP_COHER_CNTL */
> cs->buf[cs->cdw++] = 0x; /* CP_COHER_SIZE */
> @@ -354,8 +354,6 @@ void r600_context_flush(struct r600_context *ctx,
> unsigned flags)
>
> /* Flush the CS. */
> ctx->b.ws->cs_flush(ctx->b.rings.gfx.cs, flags,
> ctx->screen->cs_count++);
> -
> - ctx->skip_surface_sync_on_next_cs_flush = false;
> }
>
> void r600_begin_new_cs(struct r600_context *ctx)
> diff --git a/src/gallium/drivers/r600/r600_pipe.h
> b/src/gallium/drivers/r600/r600_pipe.h
> index 7350479..88b0860 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -499,16 +499,6 @@ struct r600_context {
>
> void*sb_context;
> struct r600_isa *isa;
> -
> - /* Work-around for flushing problems with compute shaders on Cayman:
> -* Emitting a SURFACE_SYNC packet with any of the CB*_DEST_BASE_ENA
> -* or DB_DEST_BASE_ENA bits set after dispatching a compute shader
> -* hangs the GPU.
> -*
> -* Setting this to true will prevent r600_flush_emit() from emitting
> -* a SURFACE_SYNC packet. This field will be cleared by
> -* by r600_context_flush() after flushing the command stream. */
> - boolean skip_surface_sync_on_next_cs_flush;
> };
>
> static INLINE void r600_emit_command_buffer(struct radeon_winsys_cs *cs,
> --
> 1.8.1.5
>
> ___
> 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 1/2] pipe-loader: Add auth_x parameter to pipe_loader_drm_probe_fd()
From: Tom Stellard
The caller can use this boolean to parameter to tell the pipe-loader
to authenticate with the X server when probing a file descriptor.
---
src/gallium/auxiliary/pipe-loader/pipe_loader.h | 6 +-
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 8 +---
src/gallium/targets/gbm/gbm.c | 2 +-
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index e0525df..40c87eb 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -128,9 +128,13 @@ pipe_loader_drm_probe(struct pipe_loader_device **devs,
int ndev);
* This function is platform-specific.
*
* \sa pipe_loader_probe
+ *
+ * \param auth_x If true, the pipe-loader will attenpt to
+ * authenticate with the X server.
*/
boolean
-pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, int fd);
+pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, int fd,
+ boolean auth_x);
#endif
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index d6869fd..9484db8 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -113,7 +113,8 @@ disconnect:
}
boolean
-pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, int fd)
+pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, int fd,
+ boolean auth_x)
{
struct pipe_loader_drm_device *ddev = CALLOC_STRUCT(pipe_loader_drm_device);
int vendor_id, chip_id;
@@ -128,7 +129,8 @@ pipe_loader_drm_probe_fd(struct pipe_loader_device **dev,
int fd)
ddev->base.ops = &pipe_loader_drm_ops;
ddev->fd = fd;
- pipe_loader_drm_x_auth(fd);
+ if (auth_x)
+ pipe_loader_drm_x_auth(fd);
ddev->base.driver_name = loader_get_driver_for_fd(fd, _LOADER_GALLIUM);
if (!ddev->base.driver_name)
@@ -160,7 +162,7 @@ pipe_loader_drm_probe(struct pipe_loader_device **devs, int
ndev)
if (fd < 0)
continue;
- if (j >= ndev || !pipe_loader_drm_probe_fd(&devs[j], fd))
+ if (j >= ndev || !pipe_loader_drm_probe_fd(&devs[j], fd, true))
close(fd);
j++;
diff --git a/src/gallium/targets/gbm/gbm.c b/src/gallium/targets/gbm/gbm.c
index 8f46057..deaa401 100644
--- a/src/gallium/targets/gbm/gbm.c
+++ b/src/gallium/targets/gbm/gbm.c
@@ -52,7 +52,7 @@ gallium_screen_create(struct gbm_gallium_drm_device *gdrm)
#ifdef HAVE_PIPE_LOADER_DRM
int ret;
- ret = pipe_loader_drm_probe_fd(&dev, gdrm->base.base.fd);
+ ret = pipe_loader_drm_probe_fd(&dev, gdrm->base.base.fd, true);
if (!ret)
return -1;
#endif /* HAVE_PIPE_LOADER_DRM */
--
1.8.1.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] pipe-loader: Add support for render nodes v2
From: Tom Stellard
v2:
- Add missing call to pipe_loader_drm_release()
- Fix render node macros
- Drop render-node configure option
---
For reference, version 1 of this patch:
http://lists.freedesktop.org/archives/mesa-dev/2013-October/047296.html
.../auxiliary/pipe-loader/pipe_loader_drm.c| 80 +-
1 file changed, 77 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index 9484db8..7a1af91 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -49,6 +49,11 @@
#include "util/u_dl.h"
#include "util/u_debug.h"
+#define DRM_RENDER_NODE_DEV_NAME_FORMAT "%s/renderD%d"
+#define DRM_RENDER_NODE_MAX_NODES 63
+#define DRM_RENDER_NODE_MIN_MINOR 128
+#define DRM_RENDER_NODE_MAX_MINOR (DRM_RENDER_NODE_MIN_MINOR +
DRM_RENDER_NODE_MAX_NODES)
+
struct pipe_loader_drm_device {
struct pipe_loader_device base;
struct util_dl_library *lib;
@@ -152,18 +157,87 @@ open_drm_minor(int minor)
return open(path, O_RDWR, 0);
}
+static int
+open_drm_render_node_minor(int minor)
+{
+ char path[PATH_MAX];
+ snprintf(path, sizeof(path), DRM_RENDER_NODE_DEV_NAME_FORMAT, DRM_DIR_NAME,
+minor);
+ return open(path, O_RDWR, 0);
+}
+
int
pipe_loader_drm_probe(struct pipe_loader_device **devs, int ndev)
{
- int i, j, fd;
+ int i, k, fd, num_render_node_devs;
+ int j = 0;
+
+ struct {
+ unsigned vendor_id;
+ unsigned chip_id;
+ } render_node_devs[DRM_RENDER_NODE_MAX_NODES];
+
+ /* Look for render nodes first */
+ for (i = DRM_RENDER_NODE_MIN_MINOR, j = 0;
+i <= DRM_RENDER_NODE_MAX_MINOR; i++) {
+ fd = open_drm_render_node_minor(i);
+ struct pipe_loader_device *dev;
+ if (fd < 0)
+ continue;
- for (i = 0, j = 0; i < DRM_MAX_MINOR; i++) {
+ if (!pipe_loader_drm_probe_fd(&dev, fd, false)) {
+ close(fd);
+ continue;
+ }
+
+ render_node_devs[j].vendor_id = dev->u.pci.vendor_id;
+ render_node_devs[j].chip_id = dev->u.pci.chip_id;
+
+ if (j < ndev) {
+ devs[j] = dev;
+ } else {
+ close(fd);
+ dev->ops->release(&dev);
+ }
+ j++;
+ }
+
+ num_render_node_devs = j;
+
+ /* Next look for drm devices. */
+ for (i = 0; i < DRM_MAX_MINOR; i++) {
+ struct pipe_loader_device *dev;
+ boolean duplicate = FALSE;
fd = open_drm_minor(i);
if (fd < 0)
continue;
- if (j >= ndev || !pipe_loader_drm_probe_fd(&devs[j], fd, true))
+ if (!pipe_loader_drm_probe_fd(&dev, fd, true)) {
close(fd);
+ continue;
+ }
+
+ /* Check to make sure we aren't already accessing this device via
+ * render nodes.
+ */
+ for (k = 0; k < num_render_node_devs; k++) {
+ if (dev->u.pci.vendor_id == render_node_devs[k].vendor_id &&
+ dev->u.pci.chip_id == render_node_devs[k].chip_id) {
+close(fd);
+dev->ops->release(&dev);
+duplicate = TRUE;
+break;
+ }
+ }
+
+ if (duplicate)
+ continue;
+
+ if (j < ndev) {
+ devs[j] = dev;
+ } else {
+ dev->ops->release(&dev);
+ }
j++;
}
--
1.8.1.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] pipe-loader: Add auth_x parameter to pipe_loader_drm_probe_fd()
On Mon, Jan 27, 2014 at 5:13 PM, Tom Stellard wrote: > From: Tom Stellard > > The caller can use this boolean to parameter to tell the pipe-loader Boolean to parameter? A superfluous "to", perhaps? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/7] dri: Reuse dri_message to implement our other message handlers.
Kristian Høgsberg writes: > On Thu, Jan 23, 2014 at 3:12 PM, Eric Anholt wrote: > > Entire series > > Reviewed-by: Kristian Høgsberg > > The only thing that came to mind was that we should move the code to > open with O_CLOEXEC to its own wrapper function. Of course there's > really no reason that needs to be part of this series. Yeah, there's more stuff that's common between loaders, and hopefully we can move it here. I've got a half-done series laying around for driver extension resolution logic, too. pgpsRtTqR0rA8.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74098] [clover] adaptor.hpp:47:16: error: function cannot return function type 'std::vector > (unsigned long, unsigned long)'
https://bugs.freedesktop.org/show_bug.cgi?id=74098 Chad Harris changed: What|Removed |Added CC||chad.har...@lmco.com -- 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 5/7] glsl: add gl_InvocationID variable for ARB_gpu_shader5
Paul pointed out that that gl_InvocationID should be a system value variable. Therefore, patches 5 and 6 are self-NAK'd. -Jordan On Sun, Jan 26, 2014 at 12:52 PM, Jordan Justen wrote: > Signed-off-by: Jordan Justen > --- > src/glsl/builtin_variables.cpp | 2 ++ > src/mesa/main/mtypes.h | 2 ++ > src/mesa/program/prog_print.c | 10 ++ > 3 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp > index d6bc3c0..ef5bd96 100644 > --- a/src/glsl/builtin_variables.cpp > +++ b/src/glsl/builtin_variables.cpp > @@ -782,6 +782,8 @@ builtin_variable_generator::generate_gs_special_vars() > add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer"); > if (state->ARB_viewport_array_enable) >add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex"); > + if (state->ARB_gpu_shader5_enable) > + add_input(VARYING_SLOT_INVOCATION_ID, int_t, "gl_InvocationID"); > > /* Although gl_PrimitiveID appears in tessellation control and > tessellation > * evaluation shaders, it has a different function there than it has in > diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h > index d92bb88..5d2e7d1 100644 > --- a/src/mesa/main/mtypes.h > +++ b/src/mesa/main/mtypes.h > @@ -236,6 +236,7 @@ typedef enum > VARYING_SLOT_PRIMITIVE_ID, /* Does not appear in VS */ > VARYING_SLOT_LAYER, /* Appears as VS or GS output */ > VARYING_SLOT_VIEWPORT, /* Appears as VS or GS output */ > + VARYING_SLOT_INVOCATION_ID, /* Appears as a GS input */ > VARYING_SLOT_FACE, /* FS only */ > VARYING_SLOT_PNTC, /* FS only */ > VARYING_SLOT_VAR0, /* First generic varying slot */ > @@ -272,6 +273,7 @@ typedef enum > #define VARYING_BIT_PRIMITIVE_ID BITFIELD64_BIT(VARYING_SLOT_PRIMITIVE_ID) > #define VARYING_BIT_LAYER BITFIELD64_BIT(VARYING_SLOT_LAYER) > #define VARYING_BIT_VIEWPORT BITFIELD64_BIT(VARYING_SLOT_VIEWPORT) > +#define VARYING_BIT_INVOCATION_ID BITFIELD64_BIT(VARYING_SLOT_INVOCATION_ID) > #define VARYING_BIT_FACE BITFIELD64_BIT(VARYING_SLOT_FACE) > #define VARYING_BIT_PNTC BITFIELD64_BIT(VARYING_SLOT_PNTC) > #define VARYING_BIT_VAR(V) BITFIELD64_BIT(VARYING_SLOT_VAR0 + (V)) > diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c > index 02ba01e..1d60f8b 100644 > --- a/src/mesa/program/prog_print.c > +++ b/src/mesa/program/prog_print.c > @@ -145,8 +145,9 @@ arb_input_attrib_string(GLint index, GLenum progType) >"fragment.(nineteen)", /* VARYING_SLOT_PRIMITIVE_ID */ >"fragment.(twenty)", /* VARYING_SLOT_LAYER */ >"fragment.(twenty-one)", /* VARYING_SLOT_VIEWPORT */ > - "fragment.(twenty-two)", /* VARYING_SLOT_FACE */ > - "fragment.(twenty-three)", /* VARYING_SLOT_PNTC */ > + "fragment.(twenty-two)", /* VARYING_SLOT_INVOCATION_ID */ > + "fragment.(twenty-three)", /* VARYING_SLOT_FACE */ > + "fragment.(twenty-four)", /* VARYING_SLOT_PNTC */ >"fragment.varying[0]", >"fragment.varying[1]", >"fragment.varying[2]", > @@ -270,8 +271,9 @@ arb_output_attrib_string(GLint index, GLenum progType) >"result.(nineteen)", /* VARYING_SLOT_PRIMITIVE_ID */ >"result.(twenty)", /* VARYING_SLOT_LAYER */ >"result.(twenty-one)", /* VARYING_SLOT_VIEWPORT */ > - "result.(twenty-two)", /* VARYING_SLOT_FACE */ > - "result.(twenty-three)", /* VARYING_SLOT_PNTC */ > + "result.(twenty-two)", /* VARYING_SLOT_INVOCATION_ID */ > + "result.(twenty-three)", /* VARYING_SLOT_FACE */ > + "result.(twenty-four)", /* VARYING_SLOT_PNTC */ >"result.varying[0]", >"result.varying[1]", >"result.varying[2]", > -- > 1.8.5.3 > > ___ > 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] Correct test for depth parameter for checking if dimension is legal
Okay if we make this the subject? > mesa: Allow depth = 0 parameter for TexImage3D. I'll also mark it for stable when I commit it. Reviewed-by: Matt Turner On Mon, Jan 27, 2014 at 2:16 AM, Kevin Rogovin wrote: > Fixes the tests for the depth parameter for TexImage3D calls when the > target type is GL_TEXTURE_2D_ARRAY or GL_TEXTURE_CUBE_MAP_ARRAY > so that a depth value of 0 is accepted. Previously, the check > incorrectly required the depth argument to be atleast 1. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/blorp: do not use unnecessary hw-blending support
Topi Pohjolainen writes: > This is really not needed as blorp blit programs already sample > XRGB normally and get alpha channel set to 1.0 automatically by > the sampler engine. This is simply copied directly to the payload > of the render target write message and hence there is no need for > any additional blending support from the pixel processing pipeline. > > Fixes recently modified piglit test gl-3.2-layered-rendering-blit > on IVB. No regressions on IVB. What about when you have a RGB-but-not-alpha gl format that's been promoted to an ARGB Mesa and BRW surface format? I don't think blorp's samplers have any overrides going on there. pgp7LAymNpZuE.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] i965/blorp: do not use unnecessary hw-blending support
Topi Pohjolainen writes: > This is really not needed as blorp blit programs already sample > XRGB normally and get alpha channel set to 1.0 automatically by > the sampler engine. This is simply copied directly to the payload > of the render target write message and hence there is no need for > any additional blending support from the pixel processing pipeline. > > Fixes recently modified piglit test gl-3.2-layered-rendering-blit > on IVB. No regressions on IVB. What about when you have a RGB-but-not-alpha gl format that's been promoted to an ARGB Mesa and BRW surface format by texformat.c? I don't think blorp's samplers have any overrides going on there. pgpvuTRjif604.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] i965/blorp: do not use unnecessary hw-blending support
On 01/27/2014 02:46 AM, Topi Pohjolainen wrote: > This is really not needed as blorp blit programs already sample > XRGB normally and get alpha channel set to 1.0 automatically by > the sampler engine. This is simply copied directly to the payload > of the render target write message and hence there is no need for > any additional blending support from the pixel processing pipeline. > > Fixes recently modified piglit test gl-3.2-layered-rendering-blit > on IVB. No regressions on IVB. > > This is effectively revert of c0554141a9b831b4e614747104dcbbe0fe489b9d: > > i965/blorp: Support overriding destination alpha to 1.0. > > Currently, Blorp requires the source and destination formats to be > equal. However, we'd really like to be able to blit between XRGB and > ARGB formats; our BLT engine paths have supported this for a long time. > > For ARGB -> XRGB, nothing needs to occur: the missing alpha is already > interpreted as 1.0. For XRGB -> ARGB, we need to smash the alpha > channel to 1.0 when writing the destination colors. This is fairly > straightforward with blending. > > For now, this code is never used, as the source and destination formats > still must be equal. The next patch will relax that restriction. > > NOTE: This is a candidate for the 9.1 branch. > > CC: Ian Romanick > CC: Kenneth Graunke > CC: Martin Steigerwald > Signed-off-by: Topi Pohjolainen I'm still not sure why deleting this would fix your test, but it does and this code is definitely not necessary to make ARGB -> XRGB blits work. Cc: mesa-sta...@lists.freedesktop.org (perhaps?) Reviewed-by: Kenneth Graunke signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74122] New: loader.c:71:19: fatal error: dlfcn.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=74122 Priority: medium Bug ID: 74122 Keywords: regression CC: alexandre.f.dem...@gmail.com, e...@anholt.net, kei...@keithp.com, m...@fireburn.co.uk Assignee: mesa-dev@lists.freedesktop.org Summary: loader.c:71:19: fatal error: dlfcn.h: No such file or directory Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: 3f3aafbfeeb3939cb5cf710954ccefb8bbe9cff9 $ scons platform=windows toolchain=crossmingw machine=x86_64 [...] Compiling src/loader/loader.c ... src/loader/loader.c:71:19: fatal error: dlfcn.h: No such file or directory #include ^ 4556c734700da2dd95d4f148d6929a537882bade is the first bad commit commit 4556c734700da2dd95d4f148d6929a537882bade Author: Eric Anholt Date: Thu Jan 23 13:12:26 2014 -0800 loader: Use dlsym to get our udev symbols instead of explicit linking. Steam links against libudev.so.0, while we're linking against libudev.so.1. The result is that the symbol names (which are the same in the two libraries) end up conflicting, and some of the usage of .so.1 calls the .so.0 bits, which have different internal structures, and segfaults happen. By using a dlopen() with RTLD_LOCAL, we can explicitly look for the symbols we want, while they get the symbols they want. Reviewed-by: Keith Packard Reviewed-by: Kristian Høgsberg Tested-by: Alexandre Demers Tested-by: Mike Lothian :100644 100644 33ac92259485ffdbd572f1d1d515f4b0912d2eda d266d96b67478c8b86498d2851a925b0ecd774c9 Mconfigure.ac :04 04 b182b18567800d07af87ee1fc6ea0cf3240b2843 984c15307040226fd44d1cd84fa0e09e5ac26a90 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 74122] loader.c:71:19: fatal error: dlfcn.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=74122 --- Comment #1 from Eric Anholt --- Why is DRI code being built for a windows target? Sounds like scons's windows build is wrong. -- 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] glsl: Avoid combining statements from different basic blocks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74113
---
src/glsl/opt_vectorize.cpp | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/glsl/opt_vectorize.cpp b/src/glsl/opt_vectorize.cpp
index 9ca811a..6d2bd13 100644
--- a/src/glsl/opt_vectorize.cpp
+++ b/src/glsl/opt_vectorize.cpp
@@ -82,6 +82,7 @@ public:
virtual ir_visitor_status visit_enter(ir_assignment *);
virtual ir_visitor_status visit_enter(ir_swizzle *);
+ virtual ir_visitor_status visit_enter(ir_if *);
virtual ir_visitor_status visit_leave(ir_assignment *);
@@ -276,6 +277,24 @@ ir_vectorize_visitor::visit_enter(ir_swizzle *ir)
return visit_continue;
}
+/* Since there is no statement to visit between the "then" and "else"
+ * instructions try to vectorize before, in between, and after them to avoid
+ * combining statements from different basic blocks.
+ */
+ir_visitor_status
+ir_vectorize_visitor::visit_enter(ir_if *ir)
+{
+ try_vectorize();
+
+ visit_list_elements(this, &ir->then_instructions);
+ try_vectorize();
+
+ visit_list_elements(this, &ir->else_instructions);
+ try_vectorize();
+
+ return visit_continue_with_parent;
+}
+
/**
* Upon leaving an ir_assignment, save a pointer to it in ::assignment[] if
* the swizzle mask(s) found were appropriate. Also save a pointer in
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74098] [clover] adaptor.hpp:47:16: error: function cannot return function type 'std::vector > (unsigned long, unsigned long)'
https://bugs.freedesktop.org/show_bug.cgi?id=74098 --- Comment #2 from Vinson Lee --- (In reply to comment #1) > Which version of clang were you using? $ clang++ --version Ubuntu clang version 3.4-1ubuntu2 (tags/RELEASE_34/final) (based on LLVM 3.4) Target: x86_64-pc-linux-gnu Thread model: posix -- 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] i965/blorp: do not use unnecessary hw-blending support
On Mon, Jan 27, 2014 at 10:20:54AM -0800, Eric Anholt wrote: > Topi Pohjolainen writes: > > > This is really not needed as blorp blit programs already sample > > XRGB normally and get alpha channel set to 1.0 automatically by > > the sampler engine. This is simply copied directly to the payload > > of the render target write message and hence there is no need for > > any additional blending support from the pixel processing pipeline. > > > > Fixes recently modified piglit test gl-3.2-layered-rendering-blit > > on IVB. No regressions on IVB. > > What about when you have a RGB-but-not-alpha gl format that's been > promoted to an ARGB Mesa and BRW surface format? I don't think blorp's > samplers have any overrides going on there. I relied on the restriction that only blits from RGBX to RGBA and vice versa are allowed. Otherwise the formats must match. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] What use do swap interval > 1 and OML_sync_control divisor and remainder have?
On 01/24/2014 04:32 AM, Pekka Paalanen wrote: > Hi, > > I am investigating what kind of Wayland protocol extensions would be > needed to support proper presentation timing. Looking at existing > works, I am wondering about two things whether they have any real use. > > Where is swap interval (e.g. eglSwapInterval) greater than one useful? > Intervals 0 and 1 I understand, and Mesa EGL Wayland already supports > those. But when would you like to make your framerate a fraction of the > display's? There are a number of theoretical uses, but I don't know that we've ever seen any in the wild. One is video playback. You likely want 30fps there. Imagine that you have a game that only needs 30fps to be playable. When you're running on battery, you may want the system to throttle you to a lower framerate to save battery. You could also have a game that can always hit at least 30fps, but sometimes it may go higher. Using a swap interval of 2 gives the the game a consistent framerate. Sometimes that is better. 120Hz monitors. > When are the target-MSC related remainder and divisor parameters as > defined in the GLX_OML_sync_control useful? Why does also X11 Present > protocol include remainder and divisor? X11 Present has it to support GLX_OML_sync_control. I believe that GLX_OML_sync_control has it to support playback of content on monitors that aren't 60Hz. There used to be these things called CRTs, and some of them had wonkey refresh rates... like 72Hz. > GLX_OML_sync_control defines that for interlaced displays MSC is > incremented for each field. With divisor and remainder you could then > target only top or bottom fields. Is that useful, and do we care about > interlaced displays anymore? > > I am contemplating on not supporting these, because I am going to > propose using an UST-like clock as the "standard clock language" in > Wayland present extension. Supporting MSC-based timings would add > complexity. Therefore I would like to know where and how the above > mentioned are useful, because I cannot imagine it myself. > > Please, let me know of real actual use cases and existing software, > where these features offer a visible benefit and what that benefit is > exactly. I am not interested in what one might do in theory, I am > interested in real-world examples where they have proved useful. Well, > maybe also theories if they allow taking advantage of some new cool > technology. > > Btw. if you think that using UST for presentation timing and feedback > is nonsense, and MSC is the only right way, let me know and I can start > another email thread about that detail after preparing my material. > > > Thanks, > pq > ___ > 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] Correct test for depth parameter for checking if dimension is legal
On 01/27/2014 03:16 AM, Kevin Rogovin wrote:
> Fixes the tests for the depth parameter for TexImage3D calls when the
> target type is GL_TEXTURE_2D_ARRAY or GL_TEXTURE_CUBE_MAP_ARRAY
> so that a depth value of 0 is accepted. Previously, the check
> incorrectly required the depth argument to be atleast 1.
Oof. It looks like that function could use some significant
refactoring. This patch, however, is
Reviewed-by: Ian Romanick
We should also have a piglit test that tries various combinations of
width / height / depth being zero.
> ---
> src/mesa/main/teximage.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 9c3f1e8..8e2f057 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1481,7 +1481,7 @@ _mesa_legal_texture_dimensions(struct gl_context *ctx,
> GLenum target,
> return GL_FALSE;
>if (height < 2 * border || height > 2 * border + maxSize)
> return GL_FALSE;
> - if (depth < 1 || depth > ctx->Const.MaxArrayTextureLayers)
> + if (depth < 0 || depth > ctx->Const.MaxArrayTextureLayers)
> return GL_FALSE;
>if (!ctx->Extensions.ARB_texture_non_power_of_two) {
> if (width > 0 && !_mesa_is_pow_two(width - 2 * border))
> @@ -1498,7 +1498,7 @@ _mesa_legal_texture_dimensions(struct gl_context *ctx,
> GLenum target,
> return GL_FALSE;
>if (height < 2 * border || height > 2 * border + maxSize)
> return GL_FALSE;
> - if (depth < 1 || depth > ctx->Const.MaxArrayTextureLayers || depth % 6)
> + if (depth < 0 || depth > ctx->Const.MaxArrayTextureLayers || depth % 6)
> return GL_FALSE;
>if (width != height)
> return GL_FALSE;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glsl: Add constant evaluation of ir_binop_bfm.
---
src/glsl/ir_constant_expression.cpp | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index f811fd1..7fa5a09 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -1397,6 +1397,23 @@ ir_expression::constant_expression_value(struct
hash_table *variable_context)
break;
}
+ case ir_binop_bfm: {
+ int bits = op[0]->value.i[0];
+ int offset = op[1]->value.i[0];
+
+ for (unsigned c = 0; c < components; c++) {
+ if (bits == 0)
+data.u[c] = op[0]->value.u[c];
+ else if (offset < 0 || bits < 0)
+data.u[c] = 0; /* Undefined for bitfieldInsert, per spec. */
+ else if (offset + bits > 32)
+data.u[c] = 0; /* Undefined for bitfieldInsert, per spec. */
+ else
+data.u[c] = ((1 << bits) - 1) << offset;
+ }
+ break;
+ }
+
case ir_binop_ldexp:
for (unsigned c = 0; c < components; c++) {
data.f[c] = ldexp(op[0]->value.f[c], op[1]->value.i[c]);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl: Use bitfieldInsert in ldexp() lowering.
Shaves a few instructions off of lowered ldexp(). --- src/glsl/lower_instructions.cpp | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp index 8f8d448..44a6e80 100644 --- a/src/glsl/lower_instructions.cpp +++ b/src/glsl/lower_instructions.cpp @@ -384,10 +384,10 @@ lower_instructions_visitor::ldexp_to_arith(ir_expression *ir) /* Constants */ ir_constant *zeroi = ir_constant::zero(ir, ivec); - ir_constant *sign_mantissa_mask = new(ir) ir_constant(0x807fu, vec_elem); ir_constant *sign_mask = new(ir) ir_constant(0x8000u, vec_elem); ir_constant *exp_shift = new(ir) ir_constant(23u, vec_elem); + ir_constant *exp_width = new(ir) ir_constant(8u, vec_elem); /* Temporary variables */ ir_variable *x = new(ir) ir_variable(ir->type, "x", ir_var_temporary); @@ -449,11 +449,17 @@ lower_instructions_visitor::ldexp_to_arith(ir_expression *ir) */ ir_constant *exp_shift_clone = exp_shift->clone(ir, NULL); - ir->operation = ir_unop_bitcast_u2f; - ir->operands[0] = bit_or(bit_and(bitcast_f2u(x), sign_mantissa_mask), -lshift(i2u(resulting_biased_exp), exp_shift_clone)); + ir->operation = ir_unop_bitcast_i2f; + ir->operands[0] = bitfield_insert(bitcast_f2i(x), resulting_biased_exp, + exp_shift_clone, exp_width); ir->operands[1] = NULL; + /* Don't generate new IR that would need to be lowered in an additional +* pass. +*/ + if (lowering(BITFIELD_INSERT_TO_BFM_BFI)) + bitfield_insert_to_bfm_bfi(ir->operands[0]->as_expression()); + this->progress = true; } -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv30: don't overwrite blend color setting for r32/r16 float formats
Signed-off-by: Ilia Mirkin --- Untested. Happened to see this when I was reading this file (don't ask). I can't imagine the current situation to be the intended one, based on this code... src/gallium/drivers/nouveau/nv30/nv30_state_validate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nv30/nv30_state_validate.c b/src/gallium/drivers/nouveau/nv30/nv30_state_validate.c index f227559..b5584c8 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_state_validate.c +++ b/src/gallium/drivers/nouveau/nv30/nv30_state_validate.c @@ -190,7 +190,7 @@ nv30_validate_blend_colour(struct nv30_context *nv30) BEGIN_NV04(push, SUBC_3D(0x037c), 1); PUSH_DATA (push, (util_float_to_half(rgba[2]) << 0) | (util_float_to_half(rgba[3]) << 16)); - break; + return; default: break; } -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74127] New: [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=74127 Priority: medium Bug ID: 74127 Assignee: mesa-dev@lists.freedesktop.org Summary: [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed." Severity: normal Classification: Unclassified OS: All Reporter: ore...@gmail.com Hardware: Other Status: NEW Version: git Component: Other Product: Mesa With latest mesa 3f3aafbfeeb3939cb5cf710954ccefb8bbe9cff9, all gl clients fail with the message "loader.c:112: asserted_dlsym: Assertion `result' failed." I bisected to find the last good commit was d51dbe048afd2131eb3675e9cd868ce73325a61d. With 4556c734700da2dd95d4f148d6929a537882bade, x11 gl clients work without error but fail on wayland. Since 7bd95ec437a5b1052fa17780a9d66677ec1fdc35, both x11 and wayland gl clients fail with this error. Building with latest dri3 stack, installing mesa into a nonstandard prefix and setting LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH. -- 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] glsl: Add constant evaluation of ir_binop_bfm.
On 01/27/2014 01:02 PM, Matt Turner wrote:
> ---
> src/glsl/ir_constant_expression.cpp | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/src/glsl/ir_constant_expression.cpp
> b/src/glsl/ir_constant_expression.cpp
> index f811fd1..7fa5a09 100644
> --- a/src/glsl/ir_constant_expression.cpp
> +++ b/src/glsl/ir_constant_expression.cpp
> @@ -1397,6 +1397,23 @@ ir_expression::constant_expression_value(struct
> hash_table *variable_context)
>break;
> }
>
> + case ir_binop_bfm: {
> + int bits = op[0]->value.i[0];
> + int offset = op[1]->value.i[0];
> +
> + for (unsigned c = 0; c < components; c++) {
> + if (bits == 0)
> +data.u[c] = op[0]->value.u[c];
> + else if (offset < 0 || bits < 0)
> +data.u[c] = 0; /* Undefined for bitfieldInsert, per spec. */
> + else if (offset + bits > 32)
> +data.u[c] = 0; /* Undefined for bitfieldInsert, per spec. */
In the front end we ought to generate a warning. That would obviously
be a separate patch.
Reviewed-by: Ian Romanick
> + else
> +data.u[c] = ((1 << bits) - 1) << offset;
> + }
> + break;
> + }
> +
> case ir_binop_ldexp:
>for (unsigned c = 0; c < components; c++) {
> data.f[c] = ldexp(op[0]->value.f[c], op[1]->value.i[c]);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: Use bitfieldInsert in ldexp() lowering.
On 01/27/2014 01:02 PM, Matt Turner wrote: > Shaves a few instructions off of lowered ldexp(). > --- > src/glsl/lower_instructions.cpp | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp > index 8f8d448..44a6e80 100644 > --- a/src/glsl/lower_instructions.cpp > +++ b/src/glsl/lower_instructions.cpp > @@ -384,10 +384,10 @@ > lower_instructions_visitor::ldexp_to_arith(ir_expression *ir) > /* Constants */ > ir_constant *zeroi = ir_constant::zero(ir, ivec); > > - ir_constant *sign_mantissa_mask = new(ir) ir_constant(0x807fu, > vec_elem); > ir_constant *sign_mask = new(ir) ir_constant(0x8000u, vec_elem); > > ir_constant *exp_shift = new(ir) ir_constant(23u, vec_elem); > + ir_constant *exp_width = new(ir) ir_constant(8u, vec_elem); > > /* Temporary variables */ > ir_variable *x = new(ir) ir_variable(ir->type, "x", ir_var_temporary); > @@ -449,11 +449,17 @@ > lower_instructions_visitor::ldexp_to_arith(ir_expression *ir) > */ > > ir_constant *exp_shift_clone = exp_shift->clone(ir, NULL); > - ir->operation = ir_unop_bitcast_u2f; > - ir->operands[0] = bit_or(bit_and(bitcast_f2u(x), sign_mantissa_mask), > -lshift(i2u(resulting_biased_exp), > exp_shift_clone)); > + ir->operation = ir_unop_bitcast_i2f; > + ir->operands[0] = bitfield_insert(bitcast_f2i(x), resulting_biased_exp, > + exp_shift_clone, exp_width); > ir->operands[1] = NULL; > > + /* Don't generate new IR that would need to be lowered in an additional > +* pass. > +*/ > + if (lowering(BITFIELD_INSERT_TO_BFM_BFI)) > + bitfield_insert_to_bfm_bfi(ir->operands[0]->as_expression()); > + I was waffling about ways to do this without as_expression, but meh. Reviewed-by: Ian Romanick > this->progress = true; > } > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glcpp: Check version_resolved in the proper place.
Matt Turner writes: > The check was in the wrong place, such that if a shader incorrectly put > a preprocessor token before the #version declaration, the version would > be resolved twice, leading to a segmentation fault when attempting to > redefine the __VERSION__ macro. This fix looks good. And the renamed does help, so thanks! While you're at it, you might fix the typo in the comment above that function: /* GLSL version is no version is explicitly specified. */ #define IMPLICIT_GLSL_VERSION 110 (The first "is" should be "if"). And the fact that this segmentation-fault has been there with a late #version suggestions that we haven't had any piglit test for this case. Presumably we should emit a warning that the late #version is being ignored? Regardless, Reviewed-by: Carl Worth -Carl -- carl.d.wo...@intel.com pgpuUfXf1fD1_.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glcpp: Check version_resolved in the proper place.
On 01/26/2014 07:14 PM, Matt Turner wrote:
> The check was in the wrong place, such that if a shader incorrectly put
> a preprocessor token before the #version declaration, the version would
> be resolved twice, leading to a segmentation fault when attempting to
> redefine the __VERSION__ macro.
>
> #define GL_ARB_sample_shading
> #version 130
> void main() {}
This is an invalid shader. Segfaulting is bad, and fixing it is good.
Is the compile error still generated?
> Also, rename glcpp_parser_resolve_version to
> glcpp_parser_resolve_implicit_version to avoid confusion.
> ---
> I couldn't come up with something better to clarify the naming. Feel free
> to suggest something better.
>
> src/glsl/glcpp/glcpp-parse.y | 22 +++---
> src/glsl/glcpp/glcpp.h | 2 +-
> src/glsl/glcpp/pp.c | 2 +-
> 3 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> index 184e5c2..efcf139 100644
> --- a/src/glsl/glcpp/glcpp-parse.y
> +++ b/src/glsl/glcpp/glcpp-parse.y
> @@ -194,7 +194,7 @@ line:
> ralloc_asprintf_rewrite_tail (&parser->output,
> &parser->output_length, "\n");
> }
> |HASH_LINE {
> - glcpp_parser_resolve_version(parser);
> + glcpp_parser_resolve_implicit_version(parser);
> } pp_tokens NEWLINE {
>
> if (parser->skip_stack == NULL ||
> @@ -254,10 +254,10 @@ define:
>
> control_line:
> HASH_DEFINE {
> - glcpp_parser_resolve_version(parser);
> + glcpp_parser_resolve_implicit_version(parser);
> } define
> |HASH_UNDEF {
> - glcpp_parser_resolve_version(parser);
> + glcpp_parser_resolve_implicit_version(parser);
> } IDENTIFIER NEWLINE {
> macro_t *macro = hash_table_find (parser->defines, $3);
> if (macro) {
> @@ -267,7 +267,7 @@ control_line:
> ralloc_free ($3);
> }
> |HASH_IF {
> - glcpp_parser_resolve_version(parser);
> + glcpp_parser_resolve_implicit_version(parser);
> } conditional_tokens NEWLINE {
> /* Be careful to only evaluate the 'if' expression if
>* we are not skipping. When we are skipping, we
> @@ -299,14 +299,14 @@ control_line:
> _glcpp_parser_skip_stack_push_if (parser, & @1, 0);
> }
> |HASH_IFDEF {
> - glcpp_parser_resolve_version(parser);
> + glcpp_parser_resolve_implicit_version(parser);
> } IDENTIFIER junk NEWLINE {
> macro_t *macro = hash_table_find (parser->defines, $3);
> ralloc_free ($3);
> _glcpp_parser_skip_stack_push_if (parser, & @1, macro != NULL);
> }
> |HASH_IFNDEF {
> - glcpp_parser_resolve_version(parser);
> + glcpp_parser_resolve_implicit_version(parser);
> } IDENTIFIER junk NEWLINE {
> macro_t *macro = hash_table_find (parser->defines, $3);
> ralloc_free ($3);
> @@ -380,7 +380,7 @@ control_line:
> _glcpp_parser_handle_version_declaration(parser, $2, $3, true);
> }
> |HASH NEWLINE {
> - glcpp_parser_resolve_version(parser);
> + glcpp_parser_resolve_implicit_version(parser);
> }
> ;
>
> @@ -2024,6 +2024,9 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t
> *parser, intmax_t versio
> {
> const struct gl_extensions *extensions = parser->extensions;
>
> + if (parser->version_resolved)
> + return;
> +
> parser->version_resolved = true;
>
> add_builtin_define (parser, "__VERSION__", version);
> @@ -2144,11 +2147,8 @@
> _glcpp_parser_handle_version_declaration(glcpp_parser_t *parser, intmax_t
> versio
> #define IMPLICIT_GLSL_VERSION 110
>
> void
> -glcpp_parser_resolve_version(glcpp_parser_t *parser)
> +glcpp_parser_resolve_implicit_version(glcpp_parser_t *parser)
> {
> - if (parser->version_resolved)
> - return;
> -
> _glcpp_parser_handle_version_declaration(parser, IMPLICIT_GLSL_VERSION,
>NULL, false);
> }
> diff --git a/src/glsl/glcpp/glcpp.h b/src/glsl/glcpp/glcpp.h
> index 4aa200a..9d85c16 100644
> --- a/src/glsl/glcpp/glcpp.h
> +++ b/src/glsl/glcpp/glcpp.h
> @@ -203,7 +203,7 @@ void
> glcpp_parser_destroy (glcpp_parser_t *parser);
>
> void
> -glcpp_parser_resolve_version(glcpp_parser_t *parser);
> +glcpp_parser_resolve_implicit_version(glcpp_parser_t *parser);
>
> int
> glcpp_preprocess(void *ralloc_ctx, const char **shader, char **info_log,
> diff --git a/src/glsl/glcpp/pp.c b/src/glsl/glcpp/pp.c
> index 637a58f..fc645f7 100644
> --- a/src/glsl/glcpp/pp.c
> +++ b/src/glsl/glcpp/pp.c
> @@ -151,7 +151,7 @@ glcpp_preprocess(void *ralloc_ctx, const char **shader,
> char **info_log,
> if (parser->skip_stack)
> glcpp_error (&parser->ski
[Mesa-dev] [PATCH] glsl: Avoid combining statements from different basic blocks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74113
---
src/glsl/opt_vectorize.cpp | 35 +++
1 file changed, 35 insertions(+)
diff --git a/src/glsl/opt_vectorize.cpp b/src/glsl/opt_vectorize.cpp
index ac43a29..5ad1320 100644
--- a/src/glsl/opt_vectorize.cpp
+++ b/src/glsl/opt_vectorize.cpp
@@ -82,6 +82,8 @@ public:
virtual ir_visitor_status visit_enter(ir_assignment *);
virtual ir_visitor_status visit_enter(ir_swizzle *);
+ virtual ir_visitor_status visit_enter(ir_if *);
+ virtual ir_visitor_status visit_enter(ir_loop *);
virtual ir_visitor_status visit_leave(ir_assignment *);
@@ -285,6 +287,39 @@ ir_vectorize_visitor::visit_enter(ir_swizzle *ir)
return visit_continue;
}
+/* Since there is no statement to visit between the "then" and "else"
+ * instructions try to vectorize before, in between, and after them to avoid
+ * combining statements from different basic blocks.
+ */
+ir_visitor_status
+ir_vectorize_visitor::visit_enter(ir_if *ir)
+{
+ try_vectorize();
+
+ visit_list_elements(this, &ir->then_instructions);
+ try_vectorize();
+
+ visit_list_elements(this, &ir->else_instructions);
+ try_vectorize();
+
+ return visit_continue_with_parent;
+}
+
+/* Since there is no statement to visit between the instructions in the body of
+ * the loop and the instructions after it try to vectorize before and after the
+ * body to avoid combining statements from different basic blocks.
+ */
+ir_visitor_status
+ir_vectorize_visitor::visit_enter(ir_loop *ir)
+{
+ try_vectorize();
+
+ visit_list_elements(this, &ir->body_instructions);
+ try_vectorize();
+
+ return visit_continue_with_parent;
+}
+
/**
* Upon leaving an ir_assignment, save a pointer to it in ::assignment[] if
* the swizzle mask(s) found were appropriate. Also save a pointer in
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glcpp: Check version_resolved in the proper place.
On Mon, Jan 27, 2014 at 3:14 PM, Ian Romanick wrote:
> On 01/26/2014 07:14 PM, Matt Turner wrote:
>> The check was in the wrong place, such that if a shader incorrectly put
>> a preprocessor token before the #version declaration, the version would
>> be resolved twice, leading to a segmentation fault when attempting to
>> redefine the __VERSION__ macro.
>>
>> #define GL_ARB_sample_shading
>> #version 130
>> void main() {}
>
> This is an invalid shader. Segfaulting is bad, and fixing it is good.
> Is the compile error still generated?
Yeah, after fixing #define GL... -> #extension GL_... : require:
> Failed to compile fragment shader version.frag: 0:2(1): error: syntax error,
> unexpected VERSION_TOK
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glcpp: Check version_resolved in the proper place.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 03:34 PM, Carl Worth wrote: > Matt Turner writes: >> The check was in the wrong place, such that if a shader >> incorrectly put a preprocessor token before the #version >> declaration, the version would be resolved twice, leading to a >> segmentation fault when attempting to redefine the __VERSION__ >> macro. > > This fix looks good. And the renamed does help, so thanks! > > While you're at it, you might fix the typo in the comment above > that function: > > /* GLSL version is no version is explicitly specified. */ #define > IMPLICIT_GLSL_VERSION 110 > > (The first "is" should be "if"). That's in patch #2. :) > And the fact that this segmentation-fault has been there with a > late #version suggestions that we haven't had any piglit test for > this case. Presumably we should emit a warning that the late > #version is being ignored? > > Regardless, > > Reviewed-by: Carl Worth > > -Carl ___ mesa-dev > mailing list mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlLm6S8ACgkQX1gOwKyEAw+jGQCfQdNXo9XKURHbjXLGOIiyTzOk V6wAn08O+q4XtrY2gURT3EyVSL9m0GhZ =P2gX -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glcpp: Resolve implicit GLSL version to 100 if the API is ES.
On 01/26/2014 07:14 PM, Matt Turner wrote:
> Fixes a regression since b2d1c579 where ES shaders without a #version
> declaration would fail to compile if their precision declaration was
> wrapped in the standard #ifdef GL_ES check.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73978
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74066
One tiny nit below, but otherwise this is
Reviewed-by: Ian Romanick
> ---
> I didn't realize that ES 1.00 shaders weren't required to specify a
> version, so I missed handling this in b2d1c579.
>
> src/glsl/glcpp/glcpp-parse.y | 16 +---
> src/glsl/glcpp/glcpp.c | 1 +
> src/glsl/glcpp/glcpp.h | 3 ++-
> src/glsl/glcpp/pp.c | 2 +-
> 4 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> index efcf139..57ffd49 100644
> --- a/src/glsl/glcpp/glcpp-parse.y
> +++ b/src/glsl/glcpp/glcpp-parse.y
> @@ -30,6 +30,7 @@
>
> #include "glcpp.h"
> #include "main/core.h" /* for struct gl_extensions */
> +#include "main/mtypes.h" /* for gl_api enum */
>
> static void
> yyerror (YYLTYPE *locp, glcpp_parser_t *parser, const char *error);
> @@ -1186,7 +1187,7 @@ static void add_builtin_define(glcpp_parser_t *parser,
> }
>
> glcpp_parser_t *
> -glcpp_parser_create (const struct gl_extensions *extensions)
> +glcpp_parser_create (const struct gl_extensions *extensions, gl_api api)
> {
> glcpp_parser_t *parser;
>
> @@ -1215,6 +1216,7 @@ glcpp_parser_create (const struct gl_extensions
> *extensions)
> parser->error = 0;
>
> parser->extensions = extensions;
> +parser->api = api;
> parser->version_resolved = false;
>
> parser->has_new_line_number = 0;
> @@ -2143,12 +2145,20 @@
> _glcpp_parser_handle_version_declaration(glcpp_parser_t *parser, intmax_t
> versio
> }
> }
>
> -/* GLSL version is no version is explicitly specified. */
> +/* GLSL version if no version is explicitly specified. */
> #define IMPLICIT_GLSL_VERSION 110
>
> +/* GLSL ES version if no version is explicitly specified. */
> +#define IMPLICIT_GLSL_ES_VERSION 100
> +
> void
> glcpp_parser_resolve_implicit_version(glcpp_parser_t *parser)
> {
> - _glcpp_parser_handle_version_declaration(parser, IMPLICIT_GLSL_VERSION,
> + int language_version = parser->api == API_OPENGLES2 ?
> +IMPLICIT_GLSL_ES_VERSION :
> +IMPLICIT_GLSL_VERSION;
> +
> + _glcpp_parser_handle_version_declaration(parser, language_version,
>NULL, false);
> +
Extra blank line here.
> }
> diff --git a/src/glsl/glcpp/glcpp.c b/src/glsl/glcpp/glcpp.c
> index c9c2ff2..6994d7b 100644
> --- a/src/glsl/glcpp/glcpp.c
> +++ b/src/glsl/glcpp/glcpp.c
> @@ -101,6 +101,7 @@ load_text_file(void *ctx, const char *filename)
> static void
> init_fake_gl_context (struct gl_context *gl_ctx)
> {
> + gl_ctx->API = API_OPENGL_COMPAT;
> gl_ctx->Const.DisableGLSLLineContinuations = false;
> }
>
> diff --git a/src/glsl/glcpp/glcpp.h b/src/glsl/glcpp/glcpp.h
> index 9d85c16..79ccb23 100644
> --- a/src/glsl/glcpp/glcpp.h
> +++ b/src/glsl/glcpp/glcpp.h
> @@ -183,6 +183,7 @@ struct glcpp_parser {
> size_t info_log_length;
> int error;
> const struct gl_extensions *extensions;
> + gl_api api;
> bool version_resolved;
> bool has_new_line_number;
> int new_line_number;
> @@ -194,7 +195,7 @@ struct glcpp_parser {
> struct gl_extensions;
>
> glcpp_parser_t *
> -glcpp_parser_create (const struct gl_extensions *extensions);
> +glcpp_parser_create (const struct gl_extensions *extensions, gl_api api);
>
> int
> glcpp_parser_parse (glcpp_parser_t *parser);
> diff --git a/src/glsl/glcpp/pp.c b/src/glsl/glcpp/pp.c
> index fc645f7..4a623f8 100644
> --- a/src/glsl/glcpp/pp.c
> +++ b/src/glsl/glcpp/pp.c
> @@ -139,7 +139,7 @@ glcpp_preprocess(void *ralloc_ctx, const char **shader,
> char **info_log,
> const struct gl_extensions *extensions, struct gl_context *gl_ctx)
> {
> int errors;
> - glcpp_parser_t *parser = glcpp_parser_create (extensions);
> + glcpp_parser_t *parser = glcpp_parser_create (extensions, gl_ctx->API);
>
> if (! gl_ctx->Const.DisableGLSLLineContinuations)
> *shader = remove_line_continuations(parser, *shader);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glcpp: Check version_resolved in the proper place.
On 01/27/2014 04:18 PM, Matt Turner wrote:
> On Mon, Jan 27, 2014 at 3:14 PM, Ian Romanick wrote:
>> On 01/26/2014 07:14 PM, Matt Turner wrote:
>>> The check was in the wrong place, such that if a shader incorrectly put
>>> a preprocessor token before the #version declaration, the version would
>>> be resolved twice, leading to a segmentation fault when attempting to
>>> redefine the __VERSION__ macro.
>>>
>>> #define GL_ARB_sample_shading
>>> #version 130
>>> void main() {}
>>
>> This is an invalid shader. Segfaulting is bad, and fixing it is good.
>> Is the compile error still generated?
>
> Yeah, after fixing #define GL... -> #extension GL_... : require:
>
>> Failed to compile fragment shader version.frag: 0:2(1): error: syntax error,
>> unexpected VERSION_TOK
Okay. Then this patch is also
Reviewed-by: Ian Romanick
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glcpp: Check version_resolved in the proper place.
Ian Romanick writes: >> (The first "is" should be "if"). > > That's in patch #2. :) Yeah, that's what I get for reviewing patches in the order they arrive on the list... :-) -Carl pgpWgJ3mrTEsx.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] r200: move driContextSetFlags(ctx) call after ctx var is initialized
From: Brian Paul Otherwise, ctx was a garbage value. CC: "10.0" --- src/mesa/drivers/dri/r200/r200_context.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/r200/r200_context.c b/src/mesa/drivers/dri/r200/r200_context.c index a7021f2..88be4f0 100644 --- a/src/mesa/drivers/dri/r200/r200_context.c +++ b/src/mesa/drivers/dri/r200/r200_context.c @@ -279,12 +279,13 @@ GLboolean r200CreateContext( gl_api api, return GL_FALSE; } - driContextSetFlags(ctx, flags); - rmesa->radeon.swtcl.RenderIndex = ~0; rmesa->radeon.hw.all_dirty = 1; ctx = &rmesa->radeon.glCtx; + + driContextSetFlags(ctx, flags); + /* Initialize the software rasterizer and helper modules. */ _swrast_CreateContext( ctx ); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radeon: move driContextSetFlags(ctx) call after ctx var is initialized
From: Brian Paul CC: "10.0" --- src/mesa/drivers/dri/radeon/radeon_context.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/radeon/radeon_context.c b/src/mesa/drivers/dri/radeon/radeon_context.c index 73fd188..14dc3b2 100644 --- a/src/mesa/drivers/dri/radeon/radeon_context.c +++ b/src/mesa/drivers/dri/radeon/radeon_context.c @@ -242,12 +242,13 @@ r100CreateContext( gl_api api, return GL_FALSE; } - driContextSetFlags(ctx, flags); - rmesa->radeon.swtcl.RenderIndex = ~0; rmesa->radeon.hw.all_dirty = GL_TRUE; ctx = &rmesa->radeon.glCtx; + + driContextSetFlags(ctx, flags); + /* Initialize the software rasterizer and helper modules. */ _swrast_CreateContext( ctx ); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] mesa: remove unused _mesa_select_tex_object() function
From: Brian Paul
The _mesa_get_current_tex_object() function is now used everywhere that
_mesa_select_tex_object() was formerly used.
---
src/mesa/main/teximage.c | 28 ++--
src/mesa/main/teximage.h | 5 -
2 files changed, 6 insertions(+), 27 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 8aac54e..c052620 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -737,20 +737,14 @@ _mesa_get_proxy_target(GLenum target)
/**
- * Get the texture object that corresponds to the target of the given
- * texture unit. The target should have already been checked for validity.
- *
- * \param ctx GL context.
- * \param texUnit texture unit.
- * \param target texture target.
- *
- * \return pointer to the texture object on success, or NULL on failure.
+ * Return a pointer to the current texture object for the given target
+ * on the current texture unit.
+ * Note: all error checking should have been done by this point.
*/
struct gl_texture_object *
-_mesa_select_tex_object(struct gl_context *ctx,
-const struct gl_texture_unit *texUnit,
-GLenum target)
+_mesa_get_current_tex_object(struct gl_context *ctx, GLenum target)
{
+ struct gl_texture_unit *texUnit = _mesa_get_current_tex_unit(ctx);
const GLboolean arrayTex = ctx->Extensions.EXT_texture_array;
switch (target) {
@@ -818,22 +812,12 @@ _mesa_select_tex_object(struct gl_context *ctx,
return ctx->Extensions.ARB_texture_multisample
? ctx->Texture.ProxyTex[TEXTURE_2D_MULTISAMPLE_ARRAY_INDEX] : NULL;
default:
- _mesa_problem(NULL, "bad target in _mesa_select_tex_object()");
+ _mesa_problem(NULL, "bad target in _mesa_get_current_tex_object()");
return NULL;
}
}
-/**
- * Return pointer to texture object for given target on current texture unit.
- */
-struct gl_texture_object *
-_mesa_get_current_tex_object(struct gl_context *ctx, GLenum target)
-{
- struct gl_texture_unit *texUnit = _mesa_get_current_tex_unit(ctx);
- return _mesa_select_tex_object(ctx, texUnit, target);
-}
-
/**
* Get a texture image pointer from a texture object, given a texture
diff --git a/src/mesa/main/teximage.h b/src/mesa/main/teximage.h
index 80a0a57..b733cf5 100644
--- a/src/mesa/main/teximage.h
+++ b/src/mesa/main/teximage.h
@@ -103,11 +103,6 @@ _mesa_clear_texture_image(struct gl_context *ctx,
extern struct gl_texture_object *
-_mesa_select_tex_object(struct gl_context *ctx,
-const struct gl_texture_unit *texUnit,
-GLenum target);
-
-extern struct gl_texture_object *
_mesa_get_current_tex_object(struct gl_context *ctx, GLenum target);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] st/mesa: use _mesa_get_current_tex_object() in st_context_teximage()
From: Brian Paul
---
src/mesa/state_tracker/st_manager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index 8158450..ac37fa2 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -469,7 +469,6 @@ st_context_teximage(struct st_context_iface *stctxi,
{
struct st_context *st = (struct st_context *) stctxi;
struct gl_context *ctx = st->ctx;
- struct gl_texture_unit *texUnit = _mesa_get_current_tex_unit(ctx);
struct gl_texture_object *texObj;
struct gl_texture_image *texImage;
struct st_texture_object *stObj;
@@ -495,7 +494,8 @@ st_context_teximage(struct st_context_iface *stctxi,
return FALSE;
}
- texObj = _mesa_select_tex_object(ctx, texUnit, target);
+ texObj = _mesa_get_current_tex_object(ctx, target);
+
_mesa_lock_texture(ctx, texObj);
stObj = st_texture_object(texObj);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] r200: use _mesa_get_current_tex_object() in r200SetTexBuffer2()
From: Brian Paul
---
src/mesa/drivers/dri/r200/r200_texstate.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_texstate.c
b/src/mesa/drivers/dri/r200/r200_texstate.c
index f655bc1..311fc1f 100644
--- a/src/mesa/drivers/dri/r200/r200_texstate.c
+++ b/src/mesa/drivers/dri/r200/r200_texstate.c
@@ -712,7 +712,6 @@ static GLboolean r200UpdateTextureEnv( struct gl_context
*ctx, int unit, int slo
void r200SetTexBuffer2(__DRIcontext *pDRICtx, GLint target, GLint
texture_format,
__DRIdrawable *dPriv)
{
- struct gl_texture_unit *texUnit;
struct gl_texture_object *texObj;
struct gl_texture_image *texImage;
struct radeon_renderbuffer *rb;
@@ -726,9 +725,8 @@ void r200SetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
GLint texture_format
radeon = pDRICtx->driverPrivate;
rfb = dPriv->driverPrivate;
-texUnit =
&radeon->glCtx.Texture.Unit[radeon->glCtx.Texture.CurrentUnit];
- texObj = _mesa_select_tex_object(&radeon->glCtx, texUnit, target);
-texImage = _mesa_get_tex_image(&radeon->glCtx, texObj, target, 0);
+ texObj = _mesa_get_current_tex_object(&radeon->glCtx, target);
+ texImage = _mesa_get_tex_image(&radeon->glCtx, texObj, target, 0);
rImage = get_radeon_texture_image(texImage);
t = radeon_tex_obj(texObj);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] swrast: use _mesa_get_current_tex_object() in swrastSetTexBuffer2()
From: Brian Paul --- src/mesa/drivers/dri/swrast/swrast.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/mesa/drivers/dri/swrast/swrast.c b/src/mesa/drivers/dri/swrast/swrast.c index 30e6805..a25013a 100644 --- a/src/mesa/drivers/dri/swrast/swrast.c +++ b/src/mesa/drivers/dri/swrast/swrast.c @@ -71,7 +71,6 @@ static void swrastSetTexBuffer2(__DRIcontext *pDRICtx, GLint target, struct dri_context *dri_ctx; int x, y, w, h; __DRIscreen *sPriv = dPriv->driScreenPriv; -struct gl_texture_unit *texUnit; struct gl_texture_object *texObj; struct gl_texture_image *texImage; struct swrast_texture_image *swImage; @@ -82,8 +81,7 @@ static void swrastSetTexBuffer2(__DRIcontext *pDRICtx, GLint target, internalFormat = (texture_format == __DRI_TEXTURE_FORMAT_RGB ? 3 : 4); -texUnit = _mesa_get_current_tex_unit(&dri_ctx->Base); -texObj = _mesa_select_tex_object(&dri_ctx->Base, texUnit, target); +texObj = _mesa_get_current_tex_object(&dri_ctx->Base, target); texImage = _mesa_get_tex_image(&dri_ctx->Base, texObj, target, 0); swImage = swrast_texture_image(texImage); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] mesa: use _mesa_get_current_tex_object() in GetTexLevelParameteriv()
From: Brian Paul
And update a related comment.
---
src/mesa/main/texparam.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 7c59d11..dbcc6c8 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -118,8 +118,8 @@ validate_texture_wrap_mode(struct gl_context * ctx, GLenum
target, GLenum wrap)
/**
* Get current texture object for given target.
* Return NULL if any error (and record the error).
- * Note that this is different from _mesa_select_tex_object() in that proxy
- * targets are not accepted.
+ * Note that this is different from _mesa_get_current_tex_object() in that
+ * proxy targets are not accepted.
* Only the glGetTexLevelParameter() functions accept proxy targets.
*/
static struct gl_texture_object *
@@ -1356,7 +1356,6 @@ void GLAPIENTRY
_mesa_GetTexLevelParameteriv( GLenum target, GLint level,
GLenum pname, GLint *params )
{
- const struct gl_texture_unit *texUnit;
struct gl_texture_object *texObj;
GLint maxLevels;
GET_CURRENT_CONTEXT(ctx);
@@ -1367,8 +1366,6 @@ _mesa_GetTexLevelParameteriv( GLenum target, GLint level,
return;
}
- texUnit = _mesa_get_current_tex_unit(ctx);
-
if (!legal_get_tex_level_parameter_target(ctx, target)) {
_mesa_error(ctx, GL_INVALID_ENUM,
"glGetTexLevelParameter[if]v(target=0x%x)", target);
@@ -1383,7 +1380,7 @@ _mesa_GetTexLevelParameteriv( GLenum target, GLint level,
return;
}
- texObj = _mesa_select_tex_object(ctx, texUnit, target);
+ texObj = _mesa_get_current_tex_object(ctx, target);
if (target == GL_TEXTURE_BUFFER)
get_tex_level_parameter_buffer(ctx, texObj, pname, params);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] radeon: use _mesa_get_current_tex_object() in radeonSetTexBuffer2()
From: Brian Paul
---
src/mesa/drivers/dri/radeon/radeon_texstate.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_texstate.c
b/src/mesa/drivers/dri/radeon/radeon_texstate.c
index 09a7ccb..ee87f82 100644
--- a/src/mesa/drivers/dri/radeon/radeon_texstate.c
+++ b/src/mesa/drivers/dri/radeon/radeon_texstate.c
@@ -589,7 +589,6 @@ static GLboolean radeonUpdateTextureEnv( struct gl_context
*ctx, int unit )
void radeonSetTexBuffer2(__DRIcontext *pDRICtx, GLint target, GLint
texture_format,
__DRIdrawable *dPriv)
{
- struct gl_texture_unit *texUnit;
struct gl_texture_object *texObj;
struct gl_texture_image *texImage;
struct radeon_renderbuffer *rb;
@@ -603,9 +602,8 @@ void radeonSetTexBuffer2(__DRIcontext *pDRICtx, GLint
target, GLint texture_form
radeon = pDRICtx->driverPrivate;
rfb = dPriv->driverPrivate;
-texUnit = _mesa_get_current_tex_unit(&radeon->glCtx);
- texObj = _mesa_select_tex_object(&radeon->glCtx, texUnit, target);
-texImage = _mesa_get_tex_image(&radeon->glCtx, texObj, target, 0);
+ texObj = _mesa_get_current_tex_object(&radeon->glCtx, target);
+ texImage = _mesa_get_tex_image(&radeon->glCtx, texObj, target, 0);
rImage = get_radeon_texture_image(texImage);
t = radeon_tex_obj(texObj);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r200: move driContextSetFlags(ctx) call after ctx var is initialized
On Mon, Jan 27, 2014 at 3:08 PM, Brian Paul wrote: > From: Brian Paul > > Otherwise, ctx was a garbage value. > > CC: "10.0" For the series: Reviewed-by: Alex Deucher > --- > src/mesa/drivers/dri/r200/r200_context.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/src/mesa/drivers/dri/r200/r200_context.c > b/src/mesa/drivers/dri/r200/r200_context.c > index a7021f2..88be4f0 100644 > --- a/src/mesa/drivers/dri/r200/r200_context.c > +++ b/src/mesa/drivers/dri/r200/r200_context.c > @@ -279,12 +279,13 @@ GLboolean r200CreateContext( gl_api api, > return GL_FALSE; > } > > - driContextSetFlags(ctx, flags); > - > rmesa->radeon.swtcl.RenderIndex = ~0; > rmesa->radeon.hw.all_dirty = 1; > > ctx = &rmesa->radeon.glCtx; > + > + driContextSetFlags(ctx, flags); > + > /* Initialize the software rasterizer and helper modules. > */ > _swrast_CreateContext( ctx ); > -- > 1.8.3.2 > > ___ > 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] [V4 PATCH 0/7] mesa: Naming MESA_FORMATs to a specification
Tested with piglit and pushed. Nice work! Marek On Mon, Jan 27, 2014 at 1:10 AM, Mark Mueller wrote: > Thanks Marek, > I sent out a new set of patches, otherwise there is a branch called > NewStartAMF at fdo:~mmueller/mesa with everything in. > > Mark > > > On Sun, Jan 26, 2014 at 3:03 PM, Marek Olšák wrote: >> >> Mark, >> >> I will do it if you send me a git link to your branch which merges >> cleanly and compiles successfully. >> >> Marek >> >> On Sun, Jan 26, 2014 at 10:27 PM, Brian Paul >> wrote: >> > On Sun, Jan 26, 2014 at 11:45 AM, Mark Mueller >> > wrote: >> >> >> >> >> >> >> >> >> >> On Fri, Jan 24, 2014 at 2:50 AM, Marek Olšák wrote: >> >>> >> >>> On Thu, Jan 23, 2014 at 8:36 PM, Kenneth Graunke >> >>> >> >>> wrote: >> >>> > On 01/23/2014 11:19 AM, Mark Mueller wrote: >> >>> >> That works for sRGB, but what about other color spaces that may be >> >>> >> added in >> >>> >> the future? I'm fine with leaving that to another day and with >> >>> >> using >> >>> >> the >> >>> >> _SRGB decoration, as you say. >> >>> > >> >>> > Oy. Let's not worry about things that hypothetically could be >> >>> > someday. >> >>> > We need to do what makes sense today. >> >>> >> >>> Yeah, let's commit this. We can discuss the other things later, >> >>> including if SRGB should be a type or a modifier. The series is >> >>> already pretty good. >> >>> >> >>> Marek >> >> >> >> >> >> I'm not sure if further acknowledgement is needed to push the series, >> >> but, either way, I'm not authorized to push these. >> > >> > >> > The series looks good to me too, but I'd also like to see the _UNORM8 -> >> > _SRGB suffix change in a follow-up patch. >> > >> > I tried applying the patch series to my local tree but it doesn't apply >> > cleanly. My recent "mesa: add missing ETC2_SRGB cases in formats.c" >> > change, >> > and possibly others are at fault. Sorry. >> > >> > If you can rebase the series on top of master I can apply them, unless >> > Marek >> > beats me to it (I'm in the midst of traveling today). >> > >> > -Brian >> > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74127] [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=74127 --- Comment #1 from Scott Moreau --- I discovered this stems from the fact that libudev.so.1 does not exist on the system, since there is no systemd installed. -- 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 74127] [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=74127 Emil Velikov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from Emil Velikov --- libudev.so.1 is part of the libudev1/systemd/systemd-lib package. Install it and add the package as runtime dependency in your build script. -- 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 74127] [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=74127 --- Comment #3 from Scott Moreau --- Should there be a configure check added to make it clear? -- 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 74127] [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=74127 --- Comment #4 from Emil Velikov --- (In reply to comment #3) > Should there be a configure check added to make it clear? Currently we check if libudev is available during compile/build time, and build the "offending" code only if it's present. Seems like you've built mesa on a system(environment) with libudev, and then ran it on another one that lacks the library. -- 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 74127] [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=74127 --- Comment #5 from Scott Moreau --- (In reply to comment #4) > (In reply to comment #3) > > Should there be a configure check added to make it clear? > Currently we check if libudev is available during compile/build time, and > build the "offending" code only if it's present. > > Seems like you've built mesa on a system(environment) with libudev, and then > ran it on another one that lacks the library. I have libudev standalone package that provides libudev.so.0. Replacing the lib string in the code allows it to work. So it's checking for libudev but not explicitly what version, or if the library that is needed exists. -- 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 74127] [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=74127 Emil Velikov changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG |--- --- Comment #6 from Emil Velikov --- Indeed, mesa requires libudev v151, which provides libudev.so.0. So we can either bump the minimum required version or fall-back to libudev.so.0. I believe that Eric will be the judge of that. -- 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] i965/blorp: do not use unnecessary hw-blending support
On 01/27/2014 11:06 AM, Pohjolainen, Topi wrote: > On Mon, Jan 27, 2014 at 10:20:54AM -0800, Eric Anholt wrote: >> Topi Pohjolainen writes: >> >>> This is really not needed as blorp blit programs already sample >>> XRGB normally and get alpha channel set to 1.0 automatically by >>> the sampler engine. This is simply copied directly to the payload >>> of the render target write message and hence there is no need for >>> any additional blending support from the pixel processing pipeline. >>> >>> Fixes recently modified piglit test gl-3.2-layered-rendering-blit >>> on IVB. No regressions on IVB. >> >> What about when you have a RGB-but-not-alpha gl format that's been >> promoted to an ARGB Mesa and BRW surface format? I don't think blorp's >> samplers have any overrides going on there. > > I relied on the restriction that only blits from RGBX to RGBA and vice > versa are allowed. Otherwise the formats must match. I think Eric's right. Technically, it works for BlitFramebuffer because of what you say...but...we allow nearly arbitrary format conversions for CopyTexSubImage today, so I think dropping this could break things there. Plus, we hope to add that for BlitFramebuffer too (it's trivial). So, I think this code may need to stay after all...sorry for the confusion. --Ken signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Generate correct error code in glDrawBuffers()
OpenGL 3.3 spec expects GL_INVALID_OPERATION:
"For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT AND BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID OPERATION."
But OpenGL 4.0 spec changed the error code to GL_INVALID_ENUM:
"For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID_ENUM."
This patch changes the behaviour to match OpenGL 4.0 spec
Fixes Khronos OpenGL CTS draw_buffers_api.test.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat
---
src/mesa/main/buffers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 2bdbf41..cdae7c5 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -369,7 +369,7 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
* table 4.4."
*/
if (_mesa_bitcount(destMask[output]) > 1) {
-_mesa_error(ctx, GL_INVALID_OPERATION, "glDrawBuffersARB(buffer)");
+_mesa_error(ctx, GL_INVALID_ENUM, "glDrawBuffersARB(buffer)");
return;
}
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73946] scanout broken on radeon SI (OLAND)
https://bugs.freedesktop.org/show_bug.cgi?id=73946 --- Comment #10 from Michel Dänzer --- (In reply to comment #9) > I fixed Wayland/Weston with this patch: > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=0b37737cc3e7042bffb7c8a0e6a5c822bb806977 I had that fix when I reproduced the problem last week. -- 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 73746] Gallum HUD not always visible with Rust
https://bugs.freedesktop.org/show_bug.cgi?id=73746 Thomas Rohloff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Thomas Rohloff --- There was a update of libdrm in my distro + a Rust update on Steam and while I don't know which of the two fixed it the problem is gone. -- 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] glsl: Avoid combining statements from different basic blocks.
On 01/27/2014 03:17 PM, Matt Turner wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74113
> ---
> src/glsl/opt_vectorize.cpp | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/src/glsl/opt_vectorize.cpp b/src/glsl/opt_vectorize.cpp
> index ac43a29..5ad1320 100644
> --- a/src/glsl/opt_vectorize.cpp
> +++ b/src/glsl/opt_vectorize.cpp
> @@ -82,6 +82,8 @@ public:
>
> virtual ir_visitor_status visit_enter(ir_assignment *);
> virtual ir_visitor_status visit_enter(ir_swizzle *);
> + virtual ir_visitor_status visit_enter(ir_if *);
> + virtual ir_visitor_status visit_enter(ir_loop *);
>
> virtual ir_visitor_status visit_leave(ir_assignment *);
>
> @@ -285,6 +287,39 @@ ir_vectorize_visitor::visit_enter(ir_swizzle *ir)
> return visit_continue;
> }
>
> +/* Since there is no statement to visit between the "then" and "else"
> + * instructions try to vectorize before, in between, and after them to avoid
> + * combining statements from different basic blocks.
> + */
> +ir_visitor_status
> +ir_vectorize_visitor::visit_enter(ir_if *ir)
> +{
> + try_vectorize();
> +
> + visit_list_elements(this, &ir->then_instructions);
> + try_vectorize();
> +
> + visit_list_elements(this, &ir->else_instructions);
> + try_vectorize();
> +
> + return visit_continue_with_parent;
> +}
> +
> +/* Since there is no statement to visit between the instructions in the body
> of
> + * the loop and the instructions after it try to vectorize before and after
> the
> + * body to avoid combining statements from different basic blocks.
> + */
> +ir_visitor_status
> +ir_vectorize_visitor::visit_enter(ir_loop *ir)
> +{
> + try_vectorize();
> +
> + visit_list_elements(this, &ir->body_instructions);
> + try_vectorize();
> +
> + return visit_continue_with_parent;
> +}
> +
> /**
> * Upon leaving an ir_assignment, save a pointer to it in ::assignment[] if
> * the swizzle mask(s) found were appropriate. Also save a pointer in
>
Looks good to me. Thanks Matt.
Reviewed-by: Kenneth Graunke
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 3/5] glcpp: Set extension defines after resolving the GLSL version.
On Fri, Jan 17, 2014 at 9:08 PM, Matt Turner wrote: > Cc: mesa-sta...@lists.freedesktop.org Unless there are objections, I think we should probably skip this patch going to the stable branches. It wound up causing a couple of regressions, and fixed a pretty minor (at least in my opinion) issue. If we do want to pick it over, the following commits should be squashed in: 73c3c7e3 3e0e9e3b c59a605c ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 04/11] glsl: add dead branch analysis
On 22 January 2014 09:16, Connor Abbott wrote:
> Dead branch analysis determines when the then or else branches of an
> if statement will always terminate in a loop jump or return statement,
> and hence once we enter that branch we will never get to the statements
> after the if. This is useful for determining the dominance tree, which
> is needed for the conversion to SSA, as well as various other SSA-based
> optimizations.
> ---
> src/glsl/Makefile.sources | 1 +
> src/glsl/ir_dead_branches.cpp | 226
> ++
> src/glsl/ir_dead_branches.h | 78 +++
> 3 files changed, 305 insertions(+)
> create mode 100644 src/glsl/ir_dead_branches.cpp
> create mode 100644 src/glsl/ir_dead_branches.h
>
> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
> index e69c1ac..a43bfa7 100644
> --- a/src/glsl/Makefile.sources
> +++ b/src/glsl/Makefile.sources
> @@ -33,6 +33,7 @@ LIBGLSL_FILES = \
> $(GLSL_SRCDIR)/ir_clone.cpp \
> $(GLSL_SRCDIR)/ir_constant_expression.cpp \
> $(GLSL_SRCDIR)/ir.cpp \
> + $(GLSL_SRCDIR)/ir_dead_branches.cpp \
> $(GLSL_SRCDIR)/ir_equals.cpp \
> $(GLSL_SRCDIR)/ir_expression_flattening.cpp \
> $(GLSL_SRCDIR)/ir_function_can_inline.cpp \
> diff --git a/src/glsl/ir_dead_branches.cpp b/src/glsl/ir_dead_branches.cpp
> new file mode 100644
> index 000..f86f009
> --- /dev/null
> +++ b/src/glsl/ir_dead_branches.cpp
> @@ -0,0 +1,226 @@
> +/*
> + * Copyright © 2013 Connor Abbott (con...@abbott.cx)
> + *
> + * 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 "ir.h"
> +#include "ir_visitor.h"
> +#include "ir_dead_branches.h"
> +#include "main/hash_table.h"
> +
> +/**
> + * \file ir_dead_branches.h
> + *
> + * Provides a visitor which determines, for each if instruction, whether
> + * control will never flow the from the then-block or else-block
> + * to the next instruction due to jump statements (break, continue,
> return,
> + * discard).
> + */
> +
> +/*
> + * Note that we keep track of whether a given branch is dead due to a
> return-
> + * like statement (return or discard) or due to a loop jump. For example,
> + * imagine you have a control flow like the following:
> + *
> + * if (...) {
> + *while (...) {
> + * if (...) {
> + * ...
> + * continue;
> + * } else {
> + * ...
> + * return;
> + * }
> + *}
> + * }
> + *
> + * After processing the inner if statement, we see that both branches are
> dead;
> + * normally, this would result in declaring the then-branch of the outer
> if
> + * statement dead, but in this case, there is a loop in between the inner
> and
> + * outer if statement, so the branch can in fact be taken. However, if the
> + * continue statement were a discard or return instead, then control would
> + * always leave the function as soon as the while loop was reached, so in
> this
> + * case the dead branch must "skip" across the loop. So we keep track of
> whether
> + * the immediately enclosing control statement is a loop (in_loop), and
> if we
> + * are, then after processing an if statement, we only propagate the dead
> branch
> + * through the loop if both branches of the inner if statement are dead
> due to
> + * a return or discard statement (then_dead_return and else_dead_return).
> + */
> +
> +ir_dead_branches_visitor::ir_dead_branches_visitor()
> +{
> + this->ht = _mesa_hash_table_create(NULL, _mesa_key_pointer_equal);
> + this->in_loop = false;
> + this->outer_if = NULL;
> + this->in_then = false;
> +}
> +
> +static void
> +free_entry(struct hash_entry *entry)
> +{
> + ir_dead_branches *dead_branches = (ir_dead_branches *) entry->data;
> + delete dead_branches;
> +}
> +
> +ir_dead_branches_visitor::~ir_dead_branches_visitor()
> +{
> + _mesa_hash_table_dest
Re: [Mesa-dev] [PATCH RFC 05/11] glsl: add loop jump visitor
On 22 January 2014 09:16, Connor Abbott wrote:
> +class ir_loop_jumps_visitor : public ir_hierarchical_visitor
> +{
> +public:
> + ir_loop_jumps_visitor();
> + ~ir_loop_jumps_visitor();
> +
> + virtual ir_visitor_status visit_enter(ir_loop *);
> + virtual ir_visitor_status visit(ir_loop_jump *);
> +
> + ir_loop_jumps *get_loop_jumps(ir_loop *ir);
> +
> +private:
> + ir_loop *outer_loop;
>
As with outer_if in the previous patch, I think we could save some
unnecessary hashtable lookups if we simply stored the ir_loop_jumps * here
instead of storing the ir_loop *. But I don't feel terribly strongly about
it.
Either way, the patch is:
Reviewed-by: Paul Berry
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] loader: fix running with --disable-egl builds
From: Dave Airlie I sometimes build without EGL just for speed purposes, however it no longer finds my drivers when I do due to the HAVE_LIBUDEV defines being wrong. Signed-off-by: Dave Airlie --- configure.ac | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index d266d96..ba158e8 100644 --- a/configure.ac +++ b/configure.ac @@ -867,6 +867,10 @@ xyesno) ;; esac +if test "$have_libudev" = yes; then +DEFINES="$DEFINES -DHAVE_LIBUDEV" +fi + # This is outside the case (above) so that it is invoked even for non-GLX # builds. AM_CONDITIONAL(HAVE_XF86VIDMODE, test "x$HAVE_XF86VIDMODE" = xyes) @@ -1203,9 +1207,6 @@ if test "x$enable_egl" = xyes; then if test "$enable_static" != yes; then # build egl_glx when libGL is built -if test "$have_libudev" = yes; then -DEFINES="$DEFINES -DHAVE_LIBUDEV" -fi if test "x$enable_dri" = xyes; then HAVE_EGL_DRIVER_DRI2=1 -- 1.8.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gbm: Make libgbm.so.1 symlink.
--- src/gbm/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am index 4030cc6..de5126c 100644 --- a/src/gbm/Makefile.am +++ b/src/gbm/Makefile.am @@ -50,3 +50,4 @@ endif all-local: libgbm.la $(MKDIR_P) $(top_builddir)/$(LIB_DIR); ln -f .libs/libgbm.so.1.0.0 $(top_builddir)/$(LIB_DIR)/libgbm.so + ln -f .libs/libgbm.so.1.0.0 $(top_builddir)/$(LIB_DIR)/libgbm.so.1 -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Make libgbm.so.1 symlink.
On 01/27/2014 10:19 PM, Matt Turner wrote: > --- > src/gbm/Makefile.am | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am > index 4030cc6..de5126c 100644 > --- a/src/gbm/Makefile.am > +++ b/src/gbm/Makefile.am > @@ -50,3 +50,4 @@ endif > all-local: libgbm.la > $(MKDIR_P) $(top_builddir)/$(LIB_DIR); > ln -f .libs/libgbm.so.1.0.0 $(top_builddir)/$(LIB_DIR)/libgbm.so > + ln -f .libs/libgbm.so.1.0.0 $(top_builddir)/$(LIB_DIR)/libgbm.so.1 > I don't know how much time I've wasted because of this. Thanks for the fix. Reviewed-by: Kenneth Graunke signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl: vectorize pass probably needs to change types of scalar constants as well?
The new vectorization pass (added in 4bd6e0d7c69) properly changes types of
scalar dereferences. Doesn't it need to change types of scalar constants as
well?
Consider this shader:
uniform sampler2D maintex;
uniform float factor;
varying vec2 uv;
void main() {
vec4 c = texture2D(maintex, uv);
vec4 r;
r.x = max(0.123, c.x);
r.y = max(0.123, c.y);
r.z = min(c.z, factor);
r.w = min(c.w, factor);
gl_FragColor = r;
}
Scalar dereference gets properly vectorized into:
r.zw = min (c.zw, vec2(factor));
However scalar constant is vectorized into:
r.xy = max (0.123, c.xy); // type mismatch
It seems that handling ir_constant same way as ir_dereference inside
opt_vectorize.cpp rewrite_swizzle() should fix the issue.
--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] can we have gl_framebuffer _NumColorDrawBuffers = 1 and all the entries in the array NULL
I've just been playing with layered rendering on r600g and the depth test Marek wrote, and I noticed I'm sometimes getting a gallium framebuffer state with 1 cbuf but no defined cbuf, this comes direct from the Mesa state in the gl_framebuffer object, is this legal? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71543] [mesa] Source-based games segfault
https://bugs.freedesktop.org/show_bug.cgi?id=71543 Fabio Pedretti changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Fabio Pedretti --- Fix pushed: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4556c734700da2dd95d4f148d6929a537882bade Reopen if needed. -- 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
