[Mesa-dev] [PATCH] mesa: fix error reported on gTexSubImage2D when level not valid
Signed-off-by: Tapani Pälli
---
src/mesa/main/teximage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 647d28a..c0298af 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -2449,7 +2449,7 @@ texsubimage_error_check(struct gl_context *ctx, GLuint
dimensions,
/* level check */
if (level < 0 || level >= _mesa_max_texture_levels(ctx, target)) {
- _mesa_error(ctx, GL_INVALID_ENUM, "glTexSubImage%uD(level=%d)",
+ _mesa_error(ctx, GL_INVALID_VALUE, "glTexSubImage%uD(level=%d)",
dimensions, level);
return GL_TRUE;
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] util: Use reg_belongs_to_class instead of BITSET_TEST
This shouldn't be a functional change since reg_belongs_to_class is just a
wrapper around BITSET_TEST. It just makes the code a little easier to
read.
Signed-off-by: Jason Ekstrand
---
src/util/register_allocate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c
index afab9dd..6cf7ce7 100644
--- a/src/util/register_allocate.c
+++ b/src/util/register_allocate.c
@@ -335,7 +335,7 @@ ra_set_finalize(struct ra_regs *regs, unsigned int
**q_values)
for (i = 0; i < regs->regs[rc].num_conflicts; i++) {
unsigned int rb = regs->regs[rc].conflict_list[i];
- if (BITSET_TEST(regs->classes[b]->regs, rb))
+ if (reg_belongs_to_class(rb, regs->classes[b]))
conflicts++;
}
max_conflicts = MAX2(max_conflicts, conflicts);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] i965/fs: Add another use of MAX_VGRF_SIZE
Signed-off-by: Jason Ekstrand
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index 32669f6..fd34941 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -102,7 +102,7 @@ brw_alloc_reg_set(struct intel_screen *screen, int
reg_width)
* regs).
*/
int class_count;
- int class_sizes[BRW_MAX_MRF];
+ int class_sizes[MAX_VGRF_SIZE];
if (devinfo->gen >= 7) {
for (class_count = 0; class_count < MAX_VGRF_SIZE; class_count++)
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] i965/fs: Don't interfere with too many base registers
On older GENs in SIMD16 mode, we were accidentally building too much
interference into our register classes. Since everything is divided by 2,
the reigster allocator thinks we have 64 base registers instead of 128.
The actual GRF mapping still needs to be doubled, but as far as the ra_set
is concerned, we only have 64. We were accidentally adding way too much
interference.
Signed-off-by: Jason Ekstrand
Cc: Connor Abbot
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index fd34941..b23ddc5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -179,8 +179,8 @@ brw_alloc_reg_set(struct intel_screen *screen, int
reg_width)
ra_reg_to_grf[reg] = j * 2;
-for (int base_reg = j * 2;
- base_reg < j * 2 + class_sizes[i];
+for (int base_reg = j;
+ base_reg < j + (class_sizes[i] + 1) / 2;
base_reg++) {
ra_add_transitive_reg_conflict(regs, base_reg, reg);
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4] radeonsi: Add CIK SDMA support
From: Michel Dänzer
Based on the corresponding SI support.
Signed-off-by: Michel Dänzer
---
v4:
* Assert in cik_sdma_copy_tile that either the source or destination is linear
* Fall back if dimensions are not aligned to (macro)tiles for
cik_sdma_do_copy_buffer
* Fall back if dst_y != src_y for cik_sdma_copy_tile
src/gallium/drivers/radeonsi/Makefile.sources | 1 +
src/gallium/drivers/radeonsi/cik_sdma.c | 334 ++
src/gallium/drivers/radeonsi/si_dma.c | 20 --
src/gallium/drivers/radeonsi/si_pipe.h| 9 +
src/gallium/drivers/radeonsi/si_state.c | 49 +++-
src/gallium/drivers/radeonsi/si_state.h | 2 +
src/gallium/drivers/radeonsi/sid.h| 31 +++
7 files changed, 425 insertions(+), 21 deletions(-)
create mode 100644 src/gallium/drivers/radeonsi/cik_sdma.c
diff --git a/src/gallium/drivers/radeonsi/Makefile.sources
b/src/gallium/drivers/radeonsi/Makefile.sources
index 0c998f4..9cbd028 100644
--- a/src/gallium/drivers/radeonsi/Makefile.sources
+++ b/src/gallium/drivers/radeonsi/Makefile.sources
@@ -1,4 +1,5 @@
C_SOURCES := \
+ cik_sdma.c \
si_blit.c \
si_commands.c \
si_compute.c \
diff --git a/src/gallium/drivers/radeonsi/cik_sdma.c
b/src/gallium/drivers/radeonsi/cik_sdma.c
new file mode 100644
index 000..ab56b72
--- /dev/null
+++ b/src/gallium/drivers/radeonsi/cik_sdma.c
@@ -0,0 +1,334 @@
+/*
+ * Copyright 2010 Jerome Glisse
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * 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
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, 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 NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHOR(S) AND/OR THEIR SUPPLIERS 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.
+ *
+ * Authors:
+ * Jerome Glisse
+ */
+
+#include "sid.h"
+#include "si_pipe.h"
+#include "../radeon/r600_cs.h"
+
+#include "util/u_format.h"
+
+static uint32_t cik_micro_tile_mode(struct si_screen *sscreen, unsigned
tile_mode)
+{
+ if (sscreen->b.info.si_tile_mode_array_valid) {
+ uint32_t gb_tile_mode =
sscreen->b.info.si_tile_mode_array[tile_mode];
+
+ return G_009910_MICRO_TILE_MODE_NEW(gb_tile_mode);
+ }
+
+ /* The kernel cannod return the tile mode array. Guess? */
+ return V_009910_ADDR_SURF_THIN_MICRO_TILING;
+}
+
+static void cik_sdma_do_copy_buffer(struct si_context *ctx,
+ struct pipe_resource *dst,
+ struct pipe_resource *src,
+ uint64_t dst_offset,
+ uint64_t src_offset,
+ uint64_t size)
+{
+ struct radeon_winsys_cs *cs = ctx->b.rings.dma.cs;
+ unsigned i, ncopy, csize;
+ struct r600_resource *rdst = (struct r600_resource*)dst;
+ struct r600_resource *rsrc = (struct r600_resource*)src;
+
+ dst_offset += r600_resource(dst)->gpu_address;
+ src_offset += r600_resource(src)->gpu_address;
+
+ ncopy = (size / CIK_SDMA_COPY_MAX_SIZE) + !!(size %
CIK_SDMA_COPY_MAX_SIZE);
+
+ r600_need_dma_space(&ctx->b, ncopy * 7);
+
+ r600_context_bo_reloc(&ctx->b, &ctx->b.rings.dma, rsrc,
RADEON_USAGE_READ,
+ RADEON_PRIO_MIN);
+ r600_context_bo_reloc(&ctx->b, &ctx->b.rings.dma, rdst,
RADEON_USAGE_WRITE,
+ RADEON_PRIO_MIN);
+
+ for (i = 0; i < ncopy; i++) {
+ csize = size < CIK_SDMA_COPY_MAX_SIZE ? size :
CIK_SDMA_COPY_MAX_SIZE;
+ cs->buf[cs->cdw++] = CIK_SDMA_PACKET(CIK_SDMA_OPCODE_COPY,
+
CIK_SDMA_COPY_SUB_OPCODE_LINEAR,
+0);
+ cs->buf[cs->cdw++] = csize;
+ cs->buf[cs->cdw++] = 0; /* src/dst endian swap */
+ cs->buf[cs->cdw++] = src_offset;
+ cs->buf[cs->cdw++] = src_offset >> 32;
+ cs->buf[cs->cdw++] = dst_offset;
+ cs->buf[cs->cdw++] = dst_offset >>
Re: [Mesa-dev] [PATCH 3/4] radeonsi: Catch more cases that can't be handled by si_dma_copy_buffer/tile
On 01.10.2014 23:13, Grigori Goronzy wrote:
On 30.09.2014 05:58, Michel Dänzer wrote:
}
/* the x test here are currently useless (because we don't support
partial blit)
* but keep them around so we don't forget about those
*/
- if ((src_pitch % 8) || (src_box->x % 8) || (dst_x % 8) || (src_box->y %
8) || (dst_y % 8)) {
+ if ((src_pitch % 8) || (src_box->x % 8) || (dst_x % 8) ||
+ (src_box->y % 8) || (dst_y % 8) || (src_box->height % 8)) {
goto fallback;
}
That will only allow DMA copies for heights with a multiple of 8. That
isn't requirement of the DMA engines AFAICT, size is always specified in
DWs anyway.
I think the intended purpose of this code is to make sure things are
aligned to tile boundaries. That's still necessary when using
si_dma_copy_buffer for tiled resources, but it's not strict enough for
2D tiled resources. See v4 of my 'Add CIK SDMA support' patch.
--
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 02/10] gallium: Add PIPE_SHADER_IR_NATIVE to enum pipe_shader_ir
Tom Stellard writes:
> Drivers can return this value for PIPE_COMPUTE_CAP_IR_TARGET
> if they want clover to give them native object code.
Looks good to me,
Reviewed-by: Francisco Jerez
> ---
> src/gallium/docs/source/screen.rst | 4 ++--
> src/gallium/include/pipe/p_defines.h | 3 ++-
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/docs/source/screen.rst
> b/src/gallium/docs/source/screen.rst
> index c83be12..0f989eb 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -320,8 +320,8 @@ pipe_screen::get_compute_param.
>
> * ``PIPE_COMPUTE_CAP_IR_TARGET``: A description of the target of the form
>``processor-arch-manufacturer-os`` that will be passed on to the compiler.
> - This CAP is only relevant for drivers that specify PIPE_SHADER_IR_LLVM for
> - their preferred IR.
> + This CAP is only relevant for drivers that specify PIPE_SHADER_IR_LLVM
> + or PIPE_SHADER_IR_NATIVE for their preferred IR.
>Value type: null-terminated string.
> * ``PIPE_COMPUTE_CAP_GRID_DIMENSION``: Number of supported dimensions
>for grid and block coordinates. Value type: ``uint64_t``.
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> index 93156b9..d9b1547 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -638,7 +638,8 @@ enum pipe_shader_cap
> enum pipe_shader_ir
> {
> PIPE_SHADER_IR_TGSI,
> - PIPE_SHADER_IR_LLVM
> + PIPE_SHADER_IR_LLVM,
> + PIPE_SHADER_IR_NATIVE
> };
>
> /**
> --
> 1.8.5.5
pgpewCKd4YbqW.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 01/10] clover: Factor kernel argument parsing into its own function
Tom Stellard writes:
> ---
> .../state_trackers/clover/llvm/invocation.cpp | 142
> +++--
> 1 file changed, 75 insertions(+), 67 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 7bca0d6..3137591 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -293,96 +293,104 @@ namespace {
>PM.run(*mod);
> }
>
> - module
> - build_module_llvm(llvm::Module *mod,
> - const std::vector &kernels,
> - clang::LangAS::Map& address_spaces) {
> -
> - module m;
> - struct pipe_llvm_program_header header;
> -
> - llvm::SmallVector llvm_bitcode;
> - llvm::raw_svector_ostream bitcode_ostream(llvm_bitcode);
> - llvm::BitstreamWriter writer(llvm_bitcode);
> - llvm::WriteBitcodeToFile(mod, bitcode_ostream);
> - bitcode_ostream.flush();
> -
> - for (unsigned i = 0; i < kernels.size(); ++i) {
> - llvm::Function *kernel_func;
> - std::string kernel_name;
> - compat::vector args;
> + void
> + get_kernel_args(llvm::Module *mod, const std::string &kernel_name,
> + clang::LangAS::Map& address_spaces,
> + compat::vector &args) {
>
Style nit: As "args" is logically the result of this function, wouldn't
it be clearer to make it the return value? Like:
| compat::vector
| get_kernel_args(llvm::Module *mod, const std::string &kernel_name,
| clang::LangAS::Map& address_spaces);
(This is implemented by passing a pointer to the return object as an
implicit parameter anyway so it should be about as efficient)
> - kernel_func = kernels[i];
> - kernel_name = kernel_func->getName();
> + llvm::Function *kernel_func = mod->getFunction(kernel_name);
>
> - for (llvm::Function::arg_iterator I = kernel_func->arg_begin(),
> + for (llvm::Function::arg_iterator I = kernel_func->arg_begin(),
>E = kernel_func->arg_end(); I != E;
> ++I) {
> -llvm::Argument &arg = *I;
> + llvm::Argument &arg = *I;
> #if HAVE_LLVM < 0x0302
> -llvm::TargetData TD(kernel_func->getParent());
> + llvm::TargetData TD(kernel_func->getParent());
> #elif HAVE_LLVM < 0x0305
> -llvm::DataLayout TD(kernel_func->getParent()->getDataLayout());
> + llvm::DataLayout TD(kernel_func->getParent()->getDataLayout());
> #else
> -llvm::DataLayout TD(mod);
> + llvm::DataLayout TD(mod);
> #endif
>
> -llvm::Type *arg_type = arg.getType();
> -const unsigned arg_store_size = TD.getTypeStoreSize(arg_type);
> + llvm::Type *arg_type = arg.getType();
> + const unsigned arg_store_size = TD.getTypeStoreSize(arg_type);
>
> -// OpenCL 1.2 specification, Ch. 6.1.5: "A built-in data
> -// type that is not a power of two bytes in size must be
> -// aligned to the next larger power of two". We need this
> -// alignment for three element vectors, which have
> -// non-power-of-2 store size.
> -const unsigned arg_api_size =
> - util_next_power_of_two(arg_store_size);
> + // OpenCL 1.2 specification, Ch. 6.1.5: "A built-in data
> + // type that is not a power of two bytes in size must be
> + // aligned to the next larger power of two". We need this
> + // alignment for three element vectors, which have
> + // non-power-of-2 store size.
> + const unsigned arg_api_size =
> util_next_power_of_two(arg_store_size);
>
> -llvm::Type *target_type = arg_type->isIntegerTy() ?
> + llvm::Type *target_type = arg_type->isIntegerTy() ?
> TD.getSmallestLegalIntType(mod->getContext(), arg_store_size
> * 8)
> : arg_type;
> -unsigned target_size = TD.getTypeStoreSize(target_type);
> -unsigned target_align = TD.getABITypeAlignment(target_type);
> + unsigned target_size = TD.getTypeStoreSize(target_type);
> + unsigned target_align = TD.getABITypeAlignment(target_type);
>
> -if (llvm::isa(arg_type) &&
> arg.hasByValAttr()) {
> - arg_type =
> + if (llvm::isa(arg_type) && arg.hasByValAttr()) {
> +arg_type =
>
> llvm::dyn_cast(arg_type)->getElementType();
> -}
> + }
>
> -if (arg_type->isPointerTy()) {
> - unsigned address_space =
> llvm::cast(arg_type)->getAddressSpace();
> - if (address_space ==
> address_spaces[clang::LangAS::opencl_local
> + if (arg_type->isPointerTy()) {
> +unsigned address_space =
> llvm::cast(arg_type)->getAddressSpace();
> +if (address_space == ad
[Mesa-dev] [PATCH] mesa/main: Fix unpack_R5G6B5_UNORM.
There is a comment warning about the fact that this is not doing what we
expect, so fix it. This should be doing the same as unpack_B5G6R5_UNORM
but swapping B and R.
---
Jason started some work to auto-generate the format_pack.c and
format_unpack.c files which I think has this fixed. I am continuing his
work on this at the moment, but I guess it might make sense to fix this in
the current code too while that work is on-going.
No piglit regressions observed.
src/mesa/main/format_unpack.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index d5628a9..11b028c 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -207,16 +207,12 @@ unpack_B5G6R5_UNORM(const void *src, GLfloat dst[][4],
GLuint n)
static void
unpack_R5G6B5_UNORM(const void *src, GLfloat dst[][4], GLuint n)
{
- /* Warning: this function does not match the current Mesa definition
-* of MESA_FORMAT_R5G6B5_UNORM.
-*/
const GLushort *s = ((const GLushort *) src);
GLuint i;
for (i = 0; i < n; i++) {
- GLuint t = (s[i] >> 8) | (s[i] << 8); /* byte swap */
- dst[i][RCOMP] = UBYTE_TO_FLOAT( ((t >> 8) & 0xf8) | ((t >> 13) & 0x7) );
- dst[i][GCOMP] = UBYTE_TO_FLOAT( ((t >> 3) & 0xfc) | ((t >> 9) & 0x3) );
- dst[i][BCOMP] = UBYTE_TO_FLOAT( ((t << 3) & 0xf8) | ((t >> 2) & 0x7) );
+ dst[i][RCOMP] = ((s[i] ) & 0x1f) * (1.0F / 31.0F);
+ dst[i][GCOMP] = ((s[i] >> 5 ) & 0x3f) * (1.0F / 63.0F);
+ dst[i][BCOMP] = ((s[i] >> 11) & 0x1f) * (1.0F / 31.0F);
dst[i][ACOMP] = 1.0F;
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] egl: Fix pbuffer and pixmap gpu rendering
With pbuffers and pixmaps we were getting zero color buffers
available for drawing. This patch allow to do for example
glClear for pbuffers and pixmaps.
Signed-off-by: Juha-Pekka Heikkila
---
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 1ee2009..dfbe75c 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -100,7 +100,7 @@ draw_buffer_enum_to_bitmask(const struct gl_context *ctx,
GLenum buffer)
case GL_FRONT:
return BUFFER_BIT_FRONT_LEFT | BUFFER_BIT_FRONT_RIGHT;
case GL_BACK:
- if (_mesa_is_gles(ctx)) {
+ if (_mesa_is_gles(ctx) || _mesa_is_winsys_fbo(ctx->DrawBuffer)) {
/* Page 181 (page 192 of the PDF) in section 4.2.1 of the OpenGL
* ES 3.0.1 specification says:
*
--
1.8.5.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] egl: Fix for eglpbuffers
Currently pbuffers fail on drawing operations (for example glClear to clear pbuffer). This patch fixes pbuffers as well as pixmaps for same issue. In Piglit only change I see is egl-nok-texture-from-pixmap start to pass but not 100% confident this is the correct solution, mainly because display buffers are also winsys fbo. Someone who has insight maybe could comment if there is better way to know if fbo is pbuffer or pixmap. /Juha-Pekka Juha-Pekka Heikkila (1): egl: Fix pbuffer and pixmap gpu rendering src/mesa/main/buffers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.5.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert "configure: ask vdpau.pc for the default location of the vdpau drivers"
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
Well, that was the whole point of the change. For OMX you don't have a
standardized sub directory where to put the loadable modules, e.g. it's
named libomxil-bellagio0 on Ubuntu and completely different on Fedora.
So what I did was just to use the $pluginsdir from libomxil-bellagio.pc
to determine where to install the OMX files and ignored $prefix. But
Emil wanted all generated plugins to be installed consistently so he
changed VDPAU to the same behavior as OMX.
I'm perfectly fine with either approach, but it should just be consistent.
Regards,
Christian.
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
On Mon, Oct 6, 2014 at 11:31 AM, Emil Velikov wrote:
On 05/10/14 01:26, Ilia Mirkin wrote:
On Fri, Oct 3, 2014 at 3:43 AM, Christian König wrote:
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov
wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov
wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as
a
volunteer for the following, even if the chances of it happening are
zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
Pretty much everyone that reports a bug/send an email to the ML/posts a
big and flashy "review" along the lines of "vdpau/omx/va is
useless/broken" like YKW.
The numbers/reports will be low (if any), but the encounters are likely
to be quite "interesting".
I'm more than happy to enlighten people as to why what they're doing
is wrong. I guess this patch is good then?
You need to implement the same for the OMX target as well, since the
intention was to get a consistent behavior.
Unfortunately I don't know anything about OMX.
Do I take that you've missed that my volunteer request covers vdpau, omx and va
?
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
I'm getting this >< close to just not building vdpau anymore due to
this breakage.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert "configure: ask vdpau.pc for the default location of the vdpau drivers"
On Tue, Oct 7, 2014 at 9:04 AM, Christian König wrote: > Am 07.10.2014 um 03:11 schrieb Ilia Mirkin: >> >> I'm under the assumption that OMX/etc don't do anything ridiculous. If >> they do, it's a bug just like this vdpau situation, and should be >> addressed as such. However addressing them should not preclude vdpau >> from being fixed. > > > Well, that was the whole point of the change. For OMX you don't have a > standardized sub directory where to put the loadable modules, e.g. it's > named libomxil-bellagio0 on Ubuntu and completely different on Fedora. > > So what I did was just to use the $pluginsdir from libomxil-bellagio.pc to > determine where to install the OMX files and ignored $prefix. But Emil > wanted all generated plugins to be installed consistently so he changed > VDPAU to the same behavior as OMX. > > I'm perfectly fine with either approach, but it should just be consistent. How about just failing the configure if you enable OMX (or anything else we don't know what to do with) but don't specify an install dir? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/10] clover: Add support for compiling to native object code
Tom Stellard writes:
> ---
> .../state_trackers/clover/llvm/invocation.cpp | 173
> -
> src/gallium/targets/opencl/Makefile.am | 1 +
> 2 files changed, 167 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 3137591..088039a 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -45,12 +45,18 @@
> #include
> #include
> #endif
> +#if HAVE_LLVM < 0x0305
> +#include
> +#endif
> #include
> +#include
> #include
> #include
> #if HAVE_LLVM < 0x0303
> #include
> #endif
> +#include
> +#include
> #include
> #include
>
> @@ -61,6 +67,13 @@
> #else
> #include
> #endif
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
>
> #include "pipe/p_state.h"
> #include "util/u_memory.h"
> @@ -71,6 +84,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> using namespace clover;
>
> @@ -120,7 +135,8 @@ namespace {
> compile(llvm::LLVMContext &llvm_ctx, const std::string &source,
> const std::string &name, const std::string &triple,
> const std::string &processor, const std::string &opts,
> - clang::LangAS::Map& address_spaces, compat::string &r_log) {
> + clang::LangAS::Map& address_spaces, unsigned &optimization_level,
> +compat::string &r_log) {
>
>clang::CompilerInstance c;
>clang::EmitLLVMOnlyAction act(&llvm_ctx);
> @@ -228,6 +244,8 @@ namespace {
>// that is no executed by all threads) during its optimizaton passes.
>c.getCodeGenOpts().LinkBitcodeFile = libclc_path;
>
> + optimization_level = c.getCodeGenOpts().OptimizationLevel;
> +
>// Compile the code
>bool ExecSuccess = c.ExecuteAction(act);
>r_log = log;
> @@ -264,8 +282,8 @@ namespace {
> }
>
> void
> - internalize_functions(llvm::Module *mod,
> -const std::vector &kernels) {
> + optimize(llvm::Module *mod, unsigned optimization_level,
> +const std::vector &kernels) {
>
>llvm::PassManager PM;
>// Add a function internalizer pass.
> @@ -289,7 +307,14 @@ namespace {
> llvm::Function *kernel = *I;
> export_list.push_back(kernel->getName().data());
>}
> + PM.add(new llvm::DataLayoutPass());
>PM.add(llvm::createInternalizePass(export_list));
> +
> + llvm::PassManagerBuilder PMB;
> + PMB.OptLevel = optimization_level;
> + PMB.LibraryInfo = new llvm::TargetLibraryInfo(
> +llvm::Triple(mod->getTargetTriple()));
> + PMB.populateModulePassManager(PM);
>PM.run(*mod);
> }
>
> @@ -405,6 +430,125 @@ namespace {
>
>return m;
> }
> +
> + module
> + build_module_native(llvm::Module *mod,
> + const std::vector &kernels,
> + clang::LangAS::Map& address_spaces,
> + std::string triple, std::string processor,
> + compat::string &r_log) {
> + std::string log;
> + LLVMTargetRef target;
> + char *error_message;
> + LLVMMemoryBufferRef out_buffer;
> + unsigned buffer_size;
> + const char *buffer_data;
> + LLVMBool err;
> + LLVMModuleRef mod_ref = wrap(mod);
> +
> + if (LLVMGetTargetFromTriple(triple.c_str(), &target, &error_message)) {
> + r_log = std::string(error_message);
> + LLVMDisposeMessage(error_message);
> + throw build_error();
> + }
> +
> + LLVMTargetMachineRef tm = LLVMCreateTargetMachine(
> +target, triple.c_str(), processor.c_str(), "",
> +LLVMCodeGenLevelDefault, LLVMRelocDefault, LLVMCodeModelDefault);
> +
> + if (!tm) {
nn> + r_log = "Could not create TargetMachine: " + triple;
> + throw build_error();
> + }
> +
> + err = LLVMTargetMachineEmitToMemoryBuffer(tm, mod_ref, LLVMObjectFile,
> +&error_message, &out_buffer);
> +
> + if (err) {
> + LLVMDisposeTargetMachine(tm);
> + r_log = std::string(error_message);
> + LLVMDisposeMessage(error_message);
> + throw build_error();
> + }
> +
This function seems pretty big and complex to me. Apparently it's
taking care of three different things: calling LLVM to emit machine code
From the IR, reading back metadata from the ELF headers and building a
clover::module for the binary. Maybe structuring it in two or maybe
three functions for each separate task would make it a bit easier to
follow?
> + buffer_size = LLVMGetBufferSize(out_buffer);
> + buffer_data = LLVMGetBufferStart(out_buffer);
> +
It seems like buffer_data is only used once? It's probably not worth
defining separate variables for these.
> + // One of the libelf
Re: [Mesa-dev] [PATCH] Revert "configure: ask vdpau.pc for the default location of the vdpau drivers"
Am 07.10.2014 um 15:07 schrieb Ilia Mirkin:
On Tue, Oct 7, 2014 at 9:04 AM, Christian König wrote:
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
Well, that was the whole point of the change. For OMX you don't have a
standardized sub directory where to put the loadable modules, e.g. it's
named libomxil-bellagio0 on Ubuntu and completely different on Fedora.
So what I did was just to use the $pluginsdir from libomxil-bellagio.pc to
determine where to install the OMX files and ignored $prefix. But Emil
wanted all generated plugins to be installed consistently so he changed
VDPAU to the same behavior as OMX.
I'm perfectly fine with either approach, but it should just be consistent.
How about just failing the configure if you enable OMX (or anything
else we don't know what to do with) but don't specify an install dir?
Would work for me as well, but doesn't sounds like the ideal solution.
Looking into the libomxil-bellagio.pc we have a whole chain of
definitions like:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
toolsdir=${exec_prefix}/bin
pluginsdir=${libdir}/libomxil-bellagio0
Isn't it somehow possible to let pkg-config assume a different $prefix
while evaluating the $pluginsdir variable (I honestly have no idea how
pkg-config works)?
That would solve the problem for OMX and make the behavior consistent again.
Regards,
Christian.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert "configure: ask vdpau.pc for the default location of the vdpau drivers"
On Tue, Oct 7, 2014 at 9:13 AM, Christian König wrote:
> Am 07.10.2014 um 15:07 schrieb Ilia Mirkin:
>
>> On Tue, Oct 7, 2014 at 9:04 AM, Christian König
>> wrote:
>>>
>>> Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
>>>
>>>
>>> Well, that was the whole point of the change. For OMX you don't have a
>>> standardized sub directory where to put the loadable modules, e.g. it's
>>> named libomxil-bellagio0 on Ubuntu and completely different on Fedora.
>>>
>>> So what I did was just to use the $pluginsdir from libomxil-bellagio.pc
>>> to
>>> determine where to install the OMX files and ignored $prefix. But Emil
>>> wanted all generated plugins to be installed consistently so he changed
>>> VDPAU to the same behavior as OMX.
>>>
>>> I'm perfectly fine with either approach, but it should just be
>>> consistent.
>>
>> How about just failing the configure if you enable OMX (or anything
>> else we don't know what to do with) but don't specify an install dir?
>
>
> Would work for me as well, but doesn't sounds like the ideal solution.
>
> Looking into the libomxil-bellagio.pc we have a whole chain of definitions
> like:
> prefix=/usr
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
> toolsdir=${exec_prefix}/bin
> pluginsdir=${libdir}/libomxil-bellagio0
>
> Isn't it somehow possible to let pkg-config assume a different $prefix while
> evaluating the $pluginsdir variable (I honestly have no idea how pkg-config
> works)?
>
> That would solve the problem for OMX and make the behavior consistent again.
Not sure about pkg-config either, but seems like defaulting it to
${libdir}/libomxil-bellagio0 is the right thing then (similarly to
vdpau defaulting to ${libdir}/vdpau). That way you can set --libdir to
/usr/lib/weirdo/place/that/debian/likes and everything will work out
as expected. Right?
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/10] clover: Register an llvm diagnostic handler to catch internal compiler errors
Tom Stellard writes:
> ---
> .../state_trackers/clover/llvm/invocation.cpp | 30
> ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 088039a..a1a54e0 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -33,6 +33,8 @@
> #include
> #else
> #include
> +#include
> +#include
> #endif
> #if HAVE_LLVM < 0x0303
> #include
> @@ -551,6 +553,22 @@ namespace {
> }
> } // End anonymous namespace
>
> +#if HAVE_LLVM >= 0x0305
> +
> +static void diagnostic_handler(const llvm::DiagnosticInfo &di, void
> *err_string) {
> + if (di.getSeverity() == llvm::DS_Error) {
> + std::string message;
> + llvm::raw_string_ostream stream(message);
> + llvm::DiagnosticPrinterRawOStream dp(stream);
> + di.print(dp);
> + stream.flush();
> + std::string *out_string = (std::string*)err_string;
> + *out_string = message;
> + }
> +}
> +
> +#endif
> +
> module
> clover::compile_program_llvm(const compat::string &source,
> enum pipe_shader_ir ir,
> @@ -578,6 +596,11 @@ clover::compile_program_llvm(const compat::string
> &source,
> llvm::LLVMContext llvm_ctx;
> unsigned optimization_level;
>
> +#if HAVE_LLVM >= 0x0305
> + std::string diagnostic_message;
> + llvm_ctx.setDiagnosticHandler(diagnostic_handler, &diagnostic_message);
Maybe you could directly pass a pointer to r_log as argument to the
diagnostic handler so you can avoid the problem below?
> +#endif
> +
> // The input file name must have the .cl extension in order for the
> // CompilerInvocation class to recognize it as an OpenCL source file.
> llvm::Module *mod = compile(llvm_ctx, source, "input.cl", triple,
> processor,
> @@ -607,5 +630,12 @@ clover::compile_program_llvm(const compat::string
> &source,
> // LLVM 3.6 and newer, the user takes ownership of the module.
> delete mod;
> #endif
> +#if HAVE_LLVM >= 0x0305
> + if (diagnostic_message.size()) {
> + r_log = diagnostic_message;
This is probably not executed if the compilation fails throwing an
exception.
And don't we want to append to the log instead of overwriting its
previous contents?
Thanks.
> + throw build_error();
> + }
> +#endif
> +
> return m;
> }
> --
> 1.8.5.5
pgpP8dpdFasdP.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 04/10] clover: Register an llvm diagnostic handler to catch internal compiler errors
Francisco Jerez writes:
> Tom Stellard writes:
>
>> ---
>> .../state_trackers/clover/llvm/invocation.cpp | 30
>> ++
>> 1 file changed, 30 insertions(+)
>>
>> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> index 088039a..a1a54e0 100644
>> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> @@ -33,6 +33,8 @@
>> #include
>> #else
>> #include
>> +#include
>> +#include
>> #endif
>> #if HAVE_LLVM < 0x0303
>> #include
>> @@ -551,6 +553,22 @@ namespace {
>> }
>> } // End anonymous namespace
>>
>> +#if HAVE_LLVM >= 0x0305
>> +
>> +static void diagnostic_handler(const llvm::DiagnosticInfo &di, void
>> *err_string) {
Oh, and can you define this function inside the anonymous namespace and
write the return type in a separate line as we're doing elsewhere?
>> + if (di.getSeverity() == llvm::DS_Error) {
>> + std::string message;
>> + llvm::raw_string_ostream stream(message);
>> + llvm::DiagnosticPrinterRawOStream dp(stream);
>> + di.print(dp);
>> + stream.flush();
>> + std::string *out_string = (std::string*)err_string;
>> + *out_string = message;
>> + }
>> +}
>> +
>> +#endif
>> +
>> module
>> clover::compile_program_llvm(const compat::string &source,
>> enum pipe_shader_ir ir,
>> @@ -578,6 +596,11 @@ clover::compile_program_llvm(const compat::string
>> &source,
>> llvm::LLVMContext llvm_ctx;
>> unsigned optimization_level;
>>
>> +#if HAVE_LLVM >= 0x0305
>> + std::string diagnostic_message;
>> + llvm_ctx.setDiagnosticHandler(diagnostic_handler, &diagnostic_message);
>
> Maybe you could directly pass a pointer to r_log as argument to the
> diagnostic handler so you can avoid the problem below?
>
>> +#endif
>> +
>> // The input file name must have the .cl extension in order for the
>> // CompilerInvocation class to recognize it as an OpenCL source file.
>> llvm::Module *mod = compile(llvm_ctx, source, "input.cl", triple,
>> processor,
>> @@ -607,5 +630,12 @@ clover::compile_program_llvm(const compat::string
>> &source,
>> // LLVM 3.6 and newer, the user takes ownership of the module.
>> delete mod;
>> #endif
>> +#if HAVE_LLVM >= 0x0305
>> + if (diagnostic_message.size()) {
>> + r_log = diagnostic_message;
>
> This is probably not executed if the compilation fails throwing an
> exception.
>
> And don't we want to append to the log instead of overwriting its
> previous contents?
>
> Thanks.
>
>> + throw build_error();
>> + }
>> +#endif
>> +
>> return m;
>> }
>> --
>> 1.8.5.5
pgpIIimRo7X83.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix error reported on gTexSubImage2D when level not valid
Reviewed-by: Juha-Pekka Heikkila
On 07.10.2014 10:56, Tapani Pälli wrote:
> Signed-off-by: Tapani Pälli
> ---
> src/mesa/main/teximage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 647d28a..c0298af 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -2449,7 +2449,7 @@ texsubimage_error_check(struct gl_context *ctx, GLuint
> dimensions,
>
> /* level check */
> if (level < 0 || level >= _mesa_max_texture_levels(ctx, target)) {
> - _mesa_error(ctx, GL_INVALID_ENUM, "glTexSubImage%uD(level=%d)",
> + _mesa_error(ctx, GL_INVALID_VALUE, "glTexSubImage%uD(level=%d)",
>dimensions, level);
>return GL_TRUE;
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert "configure: ask vdpau.pc for the default location of the vdpau drivers"
On Tue, Oct 7, 2014 at 9:36 AM, Christian König wrote:
> Am 07.10.2014 um 15:19 schrieb Ilia Mirkin:
>
>> On Tue, Oct 7, 2014 at 9:13 AM, Christian König
>> wrote:
>>>
>>> Am 07.10.2014 um 15:07 schrieb Ilia Mirkin:
>>>
On Tue, Oct 7, 2014 at 9:04 AM, Christian König
wrote:
>
> Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
>>
>> I'm under the assumption that OMX/etc don't do anything ridiculous. If
>> they do, it's a bug just like this vdpau situation, and should be
>> addressed as such. However addressing them should not preclude vdpau
>> from being fixed.
>
>
> Well, that was the whole point of the change. For OMX you don't have a
> standardized sub directory where to put the loadable modules, e.g. it's
> named libomxil-bellagio0 on Ubuntu and completely different on Fedora.
>
> So what I did was just to use the $pluginsdir from libomxil-bellagio.pc
> to
> determine where to install the OMX files and ignored $prefix. But Emil
> wanted all generated plugins to be installed consistently so he changed
> VDPAU to the same behavior as OMX.
>
> I'm perfectly fine with either approach, but it should just be
> consistent.
How about just failing the configure if you enable OMX (or anything
else we don't know what to do with) but don't specify an install dir?
>>>
>>>
>>> Would work for me as well, but doesn't sounds like the ideal solution.
>>>
>>> Looking into the libomxil-bellagio.pc we have a whole chain of
>>> definitions
>>> like:
>>> prefix=/usr
>>> exec_prefix=${prefix}
>>> libdir=${exec_prefix}/lib
>>> includedir=${prefix}/include
>>> toolsdir=${exec_prefix}/bin
>>> pluginsdir=${libdir}/libomxil-bellagio0
>>>
>>> Isn't it somehow possible to let pkg-config assume a different $prefix
>>> while
>>> evaluating the $pluginsdir variable (I honestly have no idea how
>>> pkg-config
>>> works)?
>>>
>>> That would solve the problem for OMX and make the behavior consistent
>>> again.
>>
>> Not sure about pkg-config either, but seems like defaulting it to
>> ${libdir}/libomxil-bellagio0 is the right thing then (similarly to
>> vdpau defaulting to ${libdir}/vdpau). That way you can set --libdir to
>> /usr/lib/weirdo/place/that/debian/likes and everything will work out
>> as expected. Right?
>
>
> Nope, that won't work neither for Ubuntu nor Fedora.
>
> Ubuntu usually sets $libdir to /usr/lib/x86_64-linux-gnu/ but the OMX dir is
> /usr/lib/libomxil-bellagio0/. And for Fedora the subdirectory is named
> differently than libomxil-bellagio0.
So... Ubuntu sets libdir differently for bellagio than for all their
other packages? That's a little odd. But... do we care? Ubuntu can
have an installation script that deals with their... peculiarities.
Much like we have a --libdir option, it seems reasonable to have a
--omx-plugin-dir or whatever, which Ubuntu and Fedora can set to their
heart's content.
>
> I've checked the pkg-config man page in the meantime, all we need to do is
> using "--define-variable=prefix=$prefix" for OMX.
>
> At least on Ubuntu running "pkg-config --variable=pluginsdir
> --define-variable=prefix=/foo libomxil-bellagio" gives me
> "/foo/lib/libomxil-bellagio0" which is exactly what we wanted to know.
>
> I'm pretty sure that's the right approach here,
IMO the right approach is for people who do weird things to suffer the
consequences of their weirdness. Of course 'weird' is in the eye of
the beholder, but I think that setting libdir's differently between
packages fits nicely into that definition. In this case, it seems like
feeding the libdir in if it's specified is the correct thing, which
would yield the same result as just defauting the way I had suggested
without involving pkg-config.
However I'm happy to accept any approach that results in a
./configure --prefix=/path/to/dir
make install
not installing to a directory outside of the prefix. That's my #1
concern. My personal inclination, however, would be to just default it
to ${libdir}/whatever.
Cheers,
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84711] [libva] gallium_drv_video.so ignores --with-dri-driverdir setting
https://bugs.freedesktop.org/show_bug.cgi?id=84711 LoneVVolf changed: What|Removed |Added Summary|[VA] gallium_drv_video.so |[libva] |ignores |gallium_drv_video.so |--with-dri-driverdir|ignores |setting |--with-dri-driverdir ||setting -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/main: Fix unpack_R5G6B5_UNORM.
On 10/07/2014 04:04 AM, Iago Toral Quiroga wrote:
There is a comment warning about the fact that this is not doing what we
expect, so fix it. This should be doing the same as unpack_B5G6R5_UNORM
but swapping B and R.
---
Jason started some work to auto-generate the format_pack.c and
format_unpack.c files which I think has this fixed. I am continuing his
work on this at the moment, but I guess it might make sense to fix this in
the current code too while that work is on-going.
No piglit regressions observed.
src/mesa/main/format_unpack.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index d5628a9..11b028c 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -207,16 +207,12 @@ unpack_B5G6R5_UNORM(const void *src, GLfloat dst[][4],
GLuint n)
static void
unpack_R5G6B5_UNORM(const void *src, GLfloat dst[][4], GLuint n)
{
- /* Warning: this function does not match the current Mesa definition
-* of MESA_FORMAT_R5G6B5_UNORM.
-*/
const GLushort *s = ((const GLushort *) src);
GLuint i;
for (i = 0; i < n; i++) {
- GLuint t = (s[i] >> 8) | (s[i] << 8); /* byte swap */
- dst[i][RCOMP] = UBYTE_TO_FLOAT( ((t >> 8) & 0xf8) | ((t >> 13) & 0x7) );
- dst[i][GCOMP] = UBYTE_TO_FLOAT( ((t >> 3) & 0xfc) | ((t >> 9) & 0x3) );
- dst[i][BCOMP] = UBYTE_TO_FLOAT( ((t << 3) & 0xf8) | ((t >> 2) & 0x7) );
+ dst[i][RCOMP] = ((s[i] ) & 0x1f) * (1.0F / 31.0F);
+ dst[i][GCOMP] = ((s[i] >> 5 ) & 0x3f) * (1.0F / 63.0F);
+ dst[i][BCOMP] = ((s[i] >> 11) & 0x1f) * (1.0F / 31.0F);
dst[i][ACOMP] = 1.0F;
}
}
Candidate for stable branches?
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: check for libexpat when no pkg-config is available
Previously, when no pkg-config was available for libexpat we would just add the needed linking flags without any extra check. Now, we check that the library and the headers are also installed in the building environment. --- configure.ac | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 2a5c143..a8f814d 100644 --- a/configure.ac +++ b/configure.ac @@ -1126,14 +1126,13 @@ if test "x$enable_dri" = xyes; then fi # Check for expat -PKG_CHECK_EXISTS([expat], [have_expat=yes], [have_expat=no]) -if test "x$have_expat" = "xyes"; then - PKG_CHECK_MODULES([EXPAT], [expat], [], - AC_MSG_ERROR([Expat required for DRI.])) -else - # expat version 2.0 and earlier do not provide expat.pc - EXPAT_LIBS=-lexpat -fi +PKG_CHECK_MODULES([EXPAT], [expat], [], +# expat version 2.0 and earlier do not provide expat.pc +[AC_CHECK_HEADER([expat.h],[], + [AC_MSG_ERROR([Expat headers required for DRI not found])]) + AC_CHECK_LIB([expat],[XML_ParserCreate],[], + [AC_MSG_ERROR([Expat library required for DRI not found])]) + EXPAT_LIBS="-lexpat"]) DRICOMMON_NEED_LIBDRM=no # If we are building any DRI driver other than swrast. -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84570] Borderlands 2: Constant frame rate drops while playing; really bad with additionl lighting
https://bugs.freedesktop.org/show_bug.cgi?id=84570 Kai changed: What|Removed |Added Attachment #107424|0 |1 is obsolete|| --- Comment #8 from Kai --- Created attachment 107502 --> https://bugs.freedesktop.org/attachment.cgi?id=107502&action=edit Screenshot with GALLIUM_HUD=fps showing FPS drops (DynamicLights=true) (In reply to Michel Dänzer from comment #7) > Can you add 'requested-VRAM+VRAM-usage,requested-GTT+GTT-usage' to > GALLIUM_HUD? Sure, here you go. One time with DynamicLights=true and one with DynamicLights=false. -- 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 84570] Borderlands 2: Constant frame rate drops while playing; really bad with additionl lighting
https://bugs.freedesktop.org/show_bug.cgi?id=84570 Kai changed: What|Removed |Added Attachment #107417|0 |1 is obsolete|| --- Comment #9 from Kai --- Created attachment 107503 --> https://bugs.freedesktop.org/attachment.cgi?id=107503&action=edit Screenshot with GALLIUM_HUD=fps showing FPS drops (DynamicLights=false) -- 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 84570] Borderlands 2: Constant frame rate drops while playing; really bad with additionl lighting
https://bugs.freedesktop.org/show_bug.cgi?id=84570 Kai changed: What|Removed |Added Attachment #107502|Screenshot with |Screenshot with description|GALLIUM_HUD=fps showing FPS |GALLIUM_HUD=fps,requested-V |drops (DynamicLights=true) |RAM+VRAM-usage,requested-GT ||T+GTT-usage showing FPS ||drops (DynamicLights=true) -- 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 84570] Borderlands 2: Constant frame rate drops while playing; really bad with additionl lighting
https://bugs.freedesktop.org/show_bug.cgi?id=84570 Kai changed: What|Removed |Added Attachment #107503|Screenshot with |Screenshot with description|GALLIUM_HUD=fps showing FPS |GALLIUM_HUD=fps,requested-V |drops (DynamicLights=false) |RAM+VRAM-usage,requested-GT ||T+GTT-usage showing FPS ||drops (DynamicLights=false) -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/main: Fix unpack_R5G6B5_UNORM.
On Oct 7, 2014 12:04 PM, "Iago Toral Quiroga" wrote:
>
> There is a comment warning about the fact that this is not doing what we
> expect, so fix it. This should be doing the same as unpack_B5G6R5_UNORM
> but swapping B and R.
> ---
>
> Jason started some work to auto-generate the format_pack.c and
> format_unpack.c files which I think has this fixed. I am continuing his
> work on this at the moment, but I guess it might make sense to fix this in
> the current code too while that work is on-going.
Not much time to reply right now, but I seem to recall there being a bit
more to fix here. What about packing and swrast's texel fetch
implementation. Are those OK for this format?
> No piglit regressions observed.
On what drivers? It might be good to test on swrast and llvmpipe. I'm not
super-concerned there but we should at least try not to break it.
--Jason
>
> src/mesa/main/format_unpack.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
> index d5628a9..11b028c 100644
> --- a/src/mesa/main/format_unpack.c
> +++ b/src/mesa/main/format_unpack.c
> @@ -207,16 +207,12 @@ unpack_B5G6R5_UNORM(const void *src, GLfloat
dst[][4], GLuint n)
> static void
> unpack_R5G6B5_UNORM(const void *src, GLfloat dst[][4], GLuint n)
> {
> - /* Warning: this function does not match the current Mesa definition
> -* of MESA_FORMAT_R5G6B5_UNORM.
> -*/
> const GLushort *s = ((const GLushort *) src);
> GLuint i;
> for (i = 0; i < n; i++) {
> - GLuint t = (s[i] >> 8) | (s[i] << 8); /* byte swap */
> - dst[i][RCOMP] = UBYTE_TO_FLOAT( ((t >> 8) & 0xf8) | ((t >> 13) &
0x7) );
> - dst[i][GCOMP] = UBYTE_TO_FLOAT( ((t >> 3) & 0xfc) | ((t >> 9) &
0x3) );
> - dst[i][BCOMP] = UBYTE_TO_FLOAT( ((t << 3) & 0xf8) | ((t >> 2) &
0x7) );
> + dst[i][RCOMP] = ((s[i] ) & 0x1f) * (1.0F / 31.0F);
> + dst[i][GCOMP] = ((s[i] >> 5 ) & 0x3f) * (1.0F / 63.0F);
> + dst[i][BCOMP] = ((s[i] >> 11) & 0x1f) * (1.0F / 31.0F);
>dst[i][ACOMP] = 1.0F;
> }
> }
> --
> 1.9.1
>
> ___
> 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 v2] r600: Use DMA transfers in r600_copy_global_buffer
On Sun, Sep 28, 2014 at 09:48:11PM +0200, Niels Ole Salscheider wrote:
> On Sunday 28 September 2014, 17:44:53, Bruno Jimenez wrote:
> > Hi,
> >
> > Sorry for not answering until now, but I have had some personal issues
> > (changing university, moving to another city...)
> >
> > As you said, this is used from clover's resource::copy, which is used by
> > clEnqueueCopyBuffer if I remember correctly (and understand correctly
> > clover) If it doesn't regress any piglit test then it has my R-b :)
> >
> > Thanks a lot!
> > Bruno
>
> Hi,
>
> no problem, I have been a bit busy with my thesis anyway (I have to hand it
> in
> on Tuesday)...
>
> You are right, it is used from clEnqueueCopyBuffer - and it does not regress
> any piglit tests for me.
> Can someone with write access please push this?
>
I've pushed this, thanks!
-Tom
> Thanks,
>
> Ole
>
> > On Mon, 2014-09-08 at 20:10 +0200, Niels Ole Salscheider wrote:
> > > v2: Do not demote items that are already in the pool
> > >
> > > Signed-off-by: Niels Ole Salscheider
> > > ---
> > >
> > > src/gallium/drivers/r600/evergreen_compute.h | 1 +
> > > src/gallium/drivers/r600/r600_blit.c | 59
> > > 2 files changed, 43 insertions(+), 17
> > > deletions(-)
> > >
> > > diff --git a/src/gallium/drivers/r600/evergreen_compute.h
> > > b/src/gallium/drivers/r600/evergreen_compute.h index 4fb53a1..e4d3a38
> > > 100644
> > > --- a/src/gallium/drivers/r600/evergreen_compute.h
> > > +++ b/src/gallium/drivers/r600/evergreen_compute.h
> > > @@ -45,6 +45,7 @@ void evergreen_init_atom_start_compute_cs(struct
> > > r600_context *rctx);>
> > > void evergreen_init_compute_state_functions(struct r600_context *rctx);
> > > void evergreen_emit_cs_shader(struct r600_context *rctx, struct r600_atom
> > > * atom);>
> > > +struct r600_resource* r600_compute_buffer_alloc_vram(struct r600_screen
> > > *screen, unsigned size);>
> > > struct pipe_resource *r600_compute_global_buffer_create(struct
> > > pipe_screen *screen, const struct pipe_resource *templ); void
> > > r600_compute_global_buffer_destroy(struct pipe_screen *screen, struct
> > > pipe_resource *res); void *r600_compute_global_transfer_map(
> > >
> > > diff --git a/src/gallium/drivers/r600/r600_blit.c
> > > b/src/gallium/drivers/r600/r600_blit.c index f766e37..b334a75 100644
> > > --- a/src/gallium/drivers/r600/r600_blit.c
> > > +++ b/src/gallium/drivers/r600/r600_blit.c
> > > @@ -21,6 +21,8 @@
> > >
> > > * USE OR OTHER DEALINGS IN THE SOFTWARE.
> > > */
> > >
> > > #include "r600_pipe.h"
> > >
> > > +#include "compute_memory_pool.h"
> > > +#include "evergreen_compute.h"
> > >
> > > #include "util/u_surface.h"
> > > #include "util/u_format.h"
> > > #include "evergreend.h"
> > >
> > > @@ -514,29 +516,52 @@ static void r600_copy_buffer(struct pipe_context
> > > *ctx, struct pipe_resource *dst>
> > > * into a single global resource (r600_screen::global_pool). The means
> > > * they don't have their own cs_buf handle, so they cannot be passed
> > > * to r600_copy_buffer() and must be handled separately.
> > >
> > > - *
> > > - * XXX: It should be possible to implement this function using
> > > - * r600_copy_buffer() by passing the memory_pool resource as both src
> > > - * and dst and updating dstx and src_box to point to the correct offsets.
> > > - * This would likely perform better than the current implementation.
> > >
> > > */
> > >
> > > static void r600_copy_global_buffer(struct pipe_context *ctx,
> > >
> > > struct pipe_resource *dst, unsigned
> > > dstx, struct pipe_resource *src,
> > > const struct pipe_box *src_box)
> > >
> > > {
> > >
> > > - struct pipe_box dst_box; struct pipe_transfer *src_pxfer,
> > > - *dst_pxfer;
> > > -
> > > - u_box_1d(dstx, src_box->width, &dst_box);
> > > - void *src_ptr = ctx->transfer_map(ctx, src, 0, PIPE_TRANSFER_READ,
> > > - src_box, &src_pxfer);
> > > - void *dst_ptr = ctx->transfer_map(ctx, dst, 0, PIPE_TRANSFER_WRITE,
> > > - &dst_box, &dst_pxfer);
> > > - memcpy(dst_ptr, src_ptr, src_box->width);
> > > -
> > > - ctx->transfer_unmap(ctx, src_pxfer);
> > > - ctx->transfer_unmap(ctx, dst_pxfer);
> > > + struct r600_context *rctx = (struct r600_context*)ctx;
> > > + struct compute_memory_pool *pool = rctx->screen->global_pool;
> > > + struct pipe_box new_src_box = *src_box;
> > > +
> > > + if (src->bind & PIPE_BIND_GLOBAL) {
> > > + struct r600_resource_global *rsrc =
> > > + (struct r600_resource_global *)src;
> > > + struct compute_memory_item *item = rsrc->chunk;
> > > +
> > > + if (is_item_in_pool(item)) {
> > > + new_src_box.x += 4 * item->start_in_dw;
> > > + src = (struct pipe_resource *)pool->bo;
> > > + } else {
> > > + if (item
[Mesa-dev] [Bug 84570] Borderlands 2: Constant frame rate drops while playing; really bad with additionl lighting
https://bugs.freedesktop.org/show_bug.cgi?id=84570 --- Comment #10 from Michel Dänzer --- Does the kernel patch I attached to bug 84662 help? Note that you may need a newer kernel for it to apply. -- 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] clover: Add support for compiling to native object code v2
v2:
- Split build_module_native() into three separate functions.
- Code cleanups.
---
.../state_trackers/clover/llvm/invocation.cpp | 200 -
src/gallium/targets/opencl/Makefile.am | 1 +
2 files changed, 192 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 3b6b6a4..d9c3d11 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -45,12 +45,18 @@
#include
#include
#endif
+#if HAVE_LLVM < 0x0305
+#include
+#endif
#include
+#include
#include
#include
#if HAVE_LLVM < 0x0303
#include
#endif
+#include
+#include
#include
#include
@@ -61,6 +67,13 @@
#else
#include
#endif
+#include
+#include
+#include
+
+#include
+#include
+#include
#include "pipe/p_state.h"
#include "util/u_memory.h"
@@ -71,6 +84,8 @@
#include
#include
#include
+#include
+#include
using namespace clover;
@@ -117,10 +132,11 @@ namespace {
#endif
llvm::Module *
- compile(llvm::LLVMContext &llvm_ctx, const std::string &source,
+ compile_llvm(llvm::LLVMContext &llvm_ctx, const std::string &source,
const std::string &name, const std::string &triple,
const std::string &processor, const std::string &opts,
- clang::LangAS::Map& address_spaces, compat::string &r_log) {
+ clang::LangAS::Map& address_spaces, unsigned &optimization_level,
+ compat::string &r_log) {
clang::CompilerInstance c;
clang::EmitLLVMOnlyAction act(&llvm_ctx);
@@ -228,6 +244,8 @@ namespace {
// that is no executed by all threads) during its optimizaton passes.
c.getCodeGenOpts().LinkBitcodeFile = libclc_path;
+ optimization_level = c.getCodeGenOpts().OptimizationLevel;
+
// Compile the code
bool ExecSuccess = c.ExecuteAction(act);
r_log = log;
@@ -264,8 +282,8 @@ namespace {
}
void
- internalize_functions(llvm::Module *mod,
-const std::vector &kernels) {
+ optimize(llvm::Module *mod, unsigned optimization_level,
+const std::vector &kernels) {
llvm::PassManager PM;
// Add a function internalizer pass.
@@ -289,7 +307,14 @@ namespace {
llvm::Function *kernel = *I;
export_list.push_back(kernel->getName().data());
}
+ PM.add(new llvm::DataLayoutPass());
PM.add(llvm::createInternalizePass(export_list));
+
+ llvm::PassManagerBuilder PMB;
+ PMB.OptLevel = optimization_level;
+ PMB.LibraryInfo = new llvm::TargetLibraryInfo(
+llvm::Triple(mod->getTargetTriple()));
+ PMB.populateModulePassManager(PM);
PM.run(*mod);
}
@@ -404,6 +429,150 @@ namespace {
return m;
}
+
+ std::vector
+ compile_native(const llvm::Module *mod, std::string triple,
+ std::string processor, compat::string &r_log) {
+
+ std::string log;
+ LLVMTargetRef target;
+ char *error_message;
+ LLVMMemoryBufferRef out_buffer;
+ unsigned buffer_size;
+ const char *buffer_data;
+ LLVMBool err;
+ LLVMModuleRef mod_ref = wrap(mod);
+
+ if (LLVMGetTargetFromTriple(triple.c_str(), &target, &error_message)) {
+ r_log = std::string(error_message);
+ LLVMDisposeMessage(error_message);
+ throw build_error();
+ }
+
+ LLVMTargetMachineRef tm = LLVMCreateTargetMachine(
+target, triple.c_str(), processor.c_str(), "",
+LLVMCodeGenLevelDefault, LLVMRelocDefault, LLVMCodeModelDefault);
+
+ if (!tm) {
+ r_log = "Could not create TargetMachine: " + triple;
+ throw build_error();
+ }
+
+ err = LLVMTargetMachineEmitToMemoryBuffer(tm, mod_ref, LLVMObjectFile,
+&error_message, &out_buffer);
+
+ if (err) {
+ LLVMDisposeTargetMachine(tm);
+ r_log = std::string(error_message);
+ LLVMDisposeMessage(error_message);
+ throw build_error();
+ }
+
+ buffer_size = LLVMGetBufferSize(out_buffer);
+ buffer_data = LLVMGetBufferStart(out_buffer);
+
+ std::vector code(buffer_data, buffer_data + buffer_size);
+
+ LLVMDisposeMemoryBuffer(out_buffer);
+ LLVMDisposeTargetMachine(tm);
+
+ return code;
+ }
+
+ std::map
+ get_kernel_offsets(std::vector &code,
+ const std::vector &kernels) {
+
+ // One of the libelf implementations
+ // (http://www.mr511.de/software/english.htm) requires calling
+ // elf_version() before elf_memory().
+ //
+ elf_version(EV_CURRENT);
+
+ Elf *elf = elf_memory(&code[0], code.size());
+ size_t section_str_index;
+ elf_getshdrstrndx(elf, §ion_str_index);
+ Elf_Scn *section = NULL;
+ Elf_Scn *symtab = NULL;
+ GElf_Shdr symtab_header;
+
+ // Find the symbol ta
[Mesa-dev] [PATCH] clover: Register an llvm diagnostic handler v2
This will allow us to handle internal compiler errors.
v2:
- Code cleanups.
---
.../state_trackers/clover/llvm/invocation.cpp | 27 ++
1 file changed, 27 insertions(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index d9c3d11..5cc0825 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -33,6 +33,8 @@
#include
#else
#include
+#include
+#include
#endif
#if HAVE_LLVM < 0x0303
#include
@@ -566,6 +568,26 @@ namespace {
return m;
}
+#if HAVE_LLVM >= 0x0305
+
+ void
+ diagnostic_handler(const llvm::DiagnosticInfo &di, void *data) {
+ if (di.getSeverity() == llvm::DS_Error) {
+ std::string message;
+ llvm::raw_string_ostream stream(message);
+ llvm::DiagnosticPrinterRawOStream dp(stream);
+ di.print(dp);
+ stream.flush();
+ compat::string *r_log = (compat::string*)data;
+ message.insert(0, *r_log);
+ *r_log = message;
+
+ throw build_error();
+ }
+ }
+
+#endif
+
void
init_targets() {
LLVMInitializeAllTargets();
@@ -598,6 +620,10 @@ clover::compile_program_llvm(const compat::string &source,
llvm::LLVMContext llvm_ctx;
unsigned optimization_level;
+#if HAVE_LLVM >= 0x0305
+ llvm_ctx.setDiagnosticHandler(diagnostic_handler, &r_log);
+#endif
+
// The input file name must have the .cl extension in order for the
// CompilerInvocation class to recognize it as an OpenCL source file.
llvm::Module *mod = compile_llvm(llvm_ctx, source, "input.cl", triple,
@@ -629,5 +655,6 @@ clover::compile_program_llvm(const compat::string &source,
// LLVM 3.6 and newer, the user takes ownership of the module.
delete mod;
#endif
+
return m;
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/main: Fix unpack_R5G6B5_UNORM.
El 2014-10-07 21:46, Jason Ekstrand escribió:
On Oct 7, 2014 12:04 PM, "Iago Toral Quiroga"
wrote:
>
> There is a comment warning about the fact that this is not doing
what we
> expect, so fix it. This should be doing the same as
unpack_B5G6R5_UNORM
> but swapping B and R.
> ---
>
> Jason started some work to auto-generate the format_pack.c and
> format_unpack.c files which I think has this fixed. I am continuing
his
> work on this at the moment, but I guess it might make sense to fix
this in
> the current code too while that work is on-going.
Not much time to reply right now, but I seem to recall there being a
bit more to fix here. What about packing and swrast's texel fetch
implementation. Are those OK for this format?
No piglit regressions observed.
On what drivers? It might be good to test on swrast and llvmpipe.
I'm not super-concerned there but we should at least try not to break
it.
--Jason
That was on Intel, but you are right, at least classic swrast has some
regressions with this.
For reference, I did not see any regressions on Gallium Softpipe but I
could only run a small subset of tests with this driver (-t texture -t
color -t format) or otherwise it would hog my CPU and eventually crash
my system. Could not test with llvmpipe, for some reason, even when I am
bulding with llvm and I see the llvmpipe sources being built Mesa
insists in using the softpipe driver at runtime...
Since there are regressions on swrast at least I guess we should just
drop this patch until we have a proper fix for all drivers.
Iago
> src/mesa/main/format_unpack.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/format_unpack.c
b/src/mesa/main/format_unpack.c
> index d5628a9..11b028c 100644
> --- a/src/mesa/main/format_unpack.c
> +++ b/src/mesa/main/format_unpack.c
> @@ -207,16 +207,12 @@ unpack_B5G6R5_UNORM(const void *src, GLfloat
dst[][4], GLuint n)
> static void
> unpack_R5G6B5_UNORM(const void *src, GLfloat dst[][4], GLuint n)
> {
> - /* Warning: this function does not match the current Mesa
definition
> - * of MESA_FORMAT_R5G6B5_UNORM.
> - */
> const GLushort *s = ((const GLushort *) src);
> GLuint i;
> for (i = 0; i < n; i++) {
> - GLuint t = (s[i] >> 8) | (s[i] << 8); /* byte swap */
> - dst[i][RCOMP] = UBYTE_TO_FLOAT( ((t >> 8) & 0xf8) | ((t
13) & 0x7) );
> - dst[i][GCOMP] = UBYTE_TO_FLOAT( ((t >> 3) & 0xfc) | ((t
9) & 0x3) );
> - dst[i][BCOMP] = UBYTE_TO_FLOAT( ((t << 3) & 0xf8) | ((t
2) & 0x7) );
> + dst[i][RCOMP] = ((s[i] ) & 0x1f) * (1.0F /
31.0F);
> + dst[i][GCOMP] = ((s[i] >> 5 ) & 0x3f) * (1.0F / 63.0F);
> + dst[i][BCOMP] = ((s[i] >> 11) & 0x1f) * (1.0F / 31.0F);
> dst[i][ACOMP] = 1.0F;
> }
> }
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev [1]
Links:
--
[1] 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] mesa/main: Fix unpack_R5G6B5_UNORM.
On Oct 8, 2014 6:36 AM, "Iago Toral" wrote:
>
> El 2014-10-07 21:46, Jason Ekstrand escribió:
>
>> On Oct 7, 2014 12:04 PM, "Iago Toral Quiroga"
>> wrote:
>> >
>> > There is a comment warning about the fact that this is not doing
>> what we
>> > expect, so fix it. This should be doing the same as
>> unpack_B5G6R5_UNORM
>> > but swapping B and R.
>> > ---
>> >
>> > Jason started some work to auto-generate the format_pack.c and
>> > format_unpack.c files which I think has this fixed. I am continuing
>> his
>> > work on this at the moment, but I guess it might make sense to fix
>> this in
>> > the current code too while that work is on-going.
>>
>> Not much time to reply right now, but I seem to recall there being a
>> bit more to fix here. What about packing and swrast's texel fetch
>> implementation. Are those OK for this format?
>>
>>> No piglit regressions observed.
>>
>>
>> On what drivers? It might be good to test on swrast and llvmpipe.
>> I'm not super-concerned there but we should at least try not to break
>> it.
>> --Jason
>
>
> That was on Intel, but you are right, at least classic swrast has some
regressions with this.
>
> For reference, I did not see any regressions on Gallium Softpipe but I
could only run a small subset of tests with this driver (-t texture -t
color -t format) or otherwise it would hog my CPU and eventually crash my
system. Could not test with llvmpipe, for some reason, even when I am
bulding with llvm and I see the llvmpipe sources being built Mesa insists
in using the softpipe driver at runtime...
I can give you the configure flags for testing llvmpipe if you'd like.
Yes, doing a full piglit run on llvmpipe or swrast requires a pretty beefy
desktop and still takes quite a while.
> Since there are regressions on swrast at least I guess we should just
drop this patch until we have a proper fix for all drivers.
I'm not as worried about llvmpipe because it fails about half the tests it
attempts anyway. I would like to know what's going on with swrast though.
Brian, any ideas?
--Jason
>
> Iago
>
>>>
>> > src/mesa/main/format_unpack.c | 10 +++---
>> > 1 file changed, 3 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/src/mesa/main/format_unpack.c
>> b/src/mesa/main/format_unpack.c
>> > index d5628a9..11b028c 100644
>> > --- a/src/mesa/main/format_unpack.c
>> > +++ b/src/mesa/main/format_unpack.c
>> > @@ -207,16 +207,12 @@ unpack_B5G6R5_UNORM(const void *src, GLfloat
>> dst[][4], GLuint n)
>> > static void
>> > unpack_R5G6B5_UNORM(const void *src, GLfloat dst[][4], GLuint n)
>> > {
>> > - /* Warning: this function does not match the current Mesa
>> definition
>> > -* of MESA_FORMAT_R5G6B5_UNORM.
>> > -*/
>> > const GLushort *s = ((const GLushort *) src);
>> > GLuint i;
>> > for (i = 0; i < n; i++) {
>> > - GLuint t = (s[i] >> 8) | (s[i] << 8); /* byte swap */
>> > - dst[i][RCOMP] = UBYTE_TO_FLOAT( ((t >> 8) & 0xf8) | ((t
13) & 0x7) );
>>
>> > - dst[i][GCOMP] = UBYTE_TO_FLOAT( ((t >> 3) & 0xfc) | ((t
9) & 0x3) );
>>
>> > - dst[i][BCOMP] = UBYTE_TO_FLOAT( ((t << 3) & 0xf8) | ((t
2) & 0x7) );
>>
>> > + dst[i][RCOMP] = ((s[i] ) & 0x1f) * (1.0F /
>> 31.0F);
>> > + dst[i][GCOMP] = ((s[i] >> 5 ) & 0x3f) * (1.0F / 63.0F);
>> > + dst[i][BCOMP] = ((s[i] >> 11) & 0x1f) * (1.0F / 31.0F);
>> >dst[i][ACOMP] = 1.0F;
>> > }
>> > }
>> > --
>> > 1.9.1
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev [1]
>>
>> Links:
>> --
>> [1] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83445] eglSwapBuffers() crash on dri
https://bugs.freedesktop.org/show_bug.cgi?id=83445 kalyank changed: What|Removed |Added CC||kondapallykalyancontribute@ ||gmail.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
