Re: [Mesa-dev] [PATCH] i965: add support for RGBA dma_buf imports.

2014-09-15 Thread Gwenole Beauchesne
Hi, 2014-09-09 10:56 GMT+02:00 Gwenole Beauchesne : > This allows for importing foreign buffers in RGB32 native endian > byte order, i.e. DRM_FORMAT_XBGR, and DRM_FORMAT_ABGR. > > Signed-off-by: Gwenole Beauchesne > --- > src/mesa/drivers/dri/i965/intel_screen.c |6 ++ > 1 file c

[Mesa-dev] [PATCH 08/11] mesa: Tweak unpack name for MESA_FORMAT_R8G8B8X8_SNORM

2014-09-15 Thread Dave Airlie
From: Richard Sandiford MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM while MESA_FORMAT_R8G8B8X8_SRGB used a function called unpack_R8G8B8X8_SRGB. This patch renames the SNORM function to have the same order as the MESA_FORMAT name, like the SRGB function does. Signed-o

[Mesa-dev] [PATCH 09/11] mesa: Fix alpha component in unpack_R8G8B8X8_SRGB.

2014-09-15 Thread Dave Airlie
From: Richard Sandiford The function was using the "X" component as the alpha channel, rather than setting alpha to 1.0. Signed-off-by: Richard Sandiford Reviewed-by: Brian Paul Signed-off-by: Dave Airlie --- src/mesa/main/format_unpack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Mesa-dev] [PATCH 05/11] st/mesa: Fix handling of LA and RG formats for big-endian

2014-09-15 Thread Dave Airlie
From: Richard Sandiford MESA_FORMAT_LnAn puts the luminance in the least significant part of the containing integer, which is equivalent to PIPE_FORMAT_LAnn. PIPE_FORMAT_LnAn puts the luminance first in memory. This patch fixes up the mesa<->gallium mapping accordingly. Signed-off-by: Richard S

[Mesa-dev] [PATCH 04/11] mesa: Add MESA_FORMAT_A8L8_{SNORM,SRGB}

2014-09-15 Thread Dave Airlie
From: Richard Sandiford The associated UNORM format already existed. This means that each LnAn format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. [airlied: rebased onto current master] Signed-off-by: Richard Sandiford Reviewed-by: Brian Paul

[Mesa-dev] [PATCH 03/11] util: Define PIPE_FORMAT_{LA, AL, RG, GR}nn aliases

2014-09-15 Thread Dave Airlie
From: Richard Sandiford ...i.e. formats in which the first listed component is in the least significant half of the integer. Signed-off-by: Richard Sandiford Reviewed-by: Brian Paul Signed-off-by: Dave Airlie --- src/gallium/include/pipe/p_format.h | 32 1 fi

[Mesa-dev] [PATCH 07/11] util: Define PIPE_FORMAT_xyzw8888_{SNORM, SRGB} aliases

2014-09-15 Thread Dave Airlie
From: Richard Sandiford ...i.e. formats in which the first listed component is in the least significant byte of the integer. The corresponding UNORM aliases already exist. Signed-off-by: Richard Sandiford Signed-off-by: Dave Airlie --- src/gallium/include/pipe/p_format.h | 24 +++

[Mesa-dev] [PATCH 06/11] util: Add PIPE_FORMAT_x8B8G8R8_SNORM formats

2014-09-15 Thread Dave Airlie
From: Richard Sandiford This means that each RnGnBnxn format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. The associated UNORM and SRGB formats already exist. Signed-off-by: Richard Sandiford Reviewed-by: Brian Paul Signed-off-by: Dave Airlie

[Mesa-dev] big endian LA and 8888 SRGB/SNORM fixes (rebased)

2014-09-15 Thread Dave Airlie
Hi, I've taken Richard's previous patchset and rebased them on top of current mesa formats code, I pushed some of Richard's other patches already but these needs some changes, so I thought I'd repost them in case anyone wanted to take a look. Dave. ___

[Mesa-dev] [PATCH 01/11] swrast: Fix handling of MESA_FORMAT_L8A8_SRGB for big-endian

2014-09-15 Thread Dave Airlie
From: Richard Sandiford Luminance is the least-significant byte of the uint16, rather than the lowest byte in memory. Other parts of mesa already handle this correctly for big-endian, and swrast already handles other MESA_FORMAT_x8y8 formats correctly. This case was just an odd-one-out. Signed

[Mesa-dev] [PATCH 11/11] st/mesa: Fix handling of 8888 SNORM and SRGB formats for big-endian

2014-09-15 Thread Dave Airlie
From: Richard Sandiford MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw. PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory. This patch fixes up the mesa<->gallium mapping accordingly. Signe

[Mesa-dev] [PATCH 02/11] util: Add PIPE_FORMAT_AnLn and PIPE_FORMAT_GnRn formats

2014-09-15 Thread Dave Airlie
From: Richard Sandiford ...i.e. formats in which the alpha or green channel is first in memory. This means that each LnAn and RnGn format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. Signed-off-by: Richard Sandiford Reviewed-by: Brian Paul Si

[Mesa-dev] [PATCH 10/11] mesa: Add MESA_FORMAT_{A8R8G8B8, X8R8G8B8, X8B8G8R8}_SRGB

2014-09-15 Thread Dave Airlie
From: Richard Sandiford This means that each SRGB format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. Signed-off-by: Richard Sandiford Signed-off-by: Dave Airlie --- src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 + src/mesa/main/f

[Mesa-dev] [PATCH] util: move shared rgtc code to util

2014-09-15 Thread Dave Airlie
From: Dave Airlie This was being shared using a ../../ get out of gallium into mesa, and I swore when I did it I'd fix things when we got a util dir, we did, so I have. Signed-off-by: Dave Airlie --- src/gallium/auxiliary/util/u_format_latc.c | 72 ++--- src/gallium/auxiliary/util/u_format_rg

Re: [Mesa-dev] [PATCH 4/5] gallivm: add texture target information for sample opcodes to tgsi info

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 21:28, schrieb Roland Scheidegger: > Am 15.09.2014 21:00, schrieb Ilia Mirkin: >> On Mon, Sep 15, 2014 at 2:51 PM, wrote: >>> From: Roland Scheidegger >>> >>> sample opcodes don't have valid texture target information (and I don't >>> think >>> this should be changed), however it

[Mesa-dev] [PATCH] gallivm: add texture target information for sample opcodes to tgsi info

2014-09-15 Thread sroland
From: Roland Scheidegger sample opcodes don't have valid texture target information (and I don't think this should be changed), however it would be nice if we had that information ready elsewhere, so stuff that information into the tgsi info when analyzing a shader. v2: Ilja Mirkin spotted some

[Mesa-dev] [Bug 83631] /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared

2014-09-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83631 --- Comment #5 from Orion Poplawski --- So, make the test: $ cat gltest.c #define GL_GLEXT_LEGACY #include int main(void) { GLintptr p; return 0; } $ gcc gltest.c In file included from /usr/include/GL/glx.h:333:0, from g

Re: [Mesa-dev] [RFC PATCH] mesa: Delete VAO _MaxElement code and index buffer bounds checking.

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 08:31, schrieb Kenneth Graunke: > Fredrik's implementation of ARB_vertex_attrib_binding introduced new > gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and > converted Mesa's older gl_client_array to be derived state. Ultimately, > we'd like to drop gl_client_array a

[Mesa-dev] [PATCH] i965: Require pixel alignment for GPU copy blit

2014-09-15 Thread Cody Northrop
The blitter will start at a pixel's natural alignment. For PBOs, if the provided offset if not aligned, bits will get dropped. This change adds offset alignment check for src and dst, kicking back if the requirements are not met. The change is based on following verbiage from BSPEC: Color pixel

Re: [Mesa-dev] [PATCH 1/4] mesa: Rework depth range setting in preparation for NV_depth_buffer_float.

2014-09-15 Thread Ian Romanick
This patch is Reviewed-by: Ian Romanick On 09/14/2014 10:07 AM, mathias.froehl...@gmx.net wrote: > From: Mathias Froehlich > > Factor out some functions that will get additional callers > with the implementation of NV_depth_buffer_float. > > Signed-off-by: Mathias Froehlich > --- > src/mesa

Re: [Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

2014-09-15 Thread Ian Romanick
On 09/15/2014 10:41 AM, Roland Scheidegger wrote: > Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net: >> From: Mathias Fröhlich >> >> Will be used in the implementation of NV_depth_buffer_float. >> >> Signed-off-by: Mathias Froehlich > --- >> src/mesa/main/glformats.c | 18 +

Re: [Mesa-dev] [PATCH] llvmpipe: fix PIPE_FORMAT_Z24_UNORM_S8_UINT depth on big endian

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 22:48, schrieb Dave Airlie: >> >> I never really looked at the big endian stuff so I have no idea if this >> is right. I thought though the channel shift thing now should work >> without endianness awareness if you fetch one 32bit number and then >> break it up into parts with shifts

[Mesa-dev] [Bug 70920] [GLSL compiler] SIGSEGV for shaders/glsl-fs-inline-explosion

2014-09-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70920 Erik Faye-Lund changed: What|Removed |Added Attachment #106343|0 |1 is obsolete|

Re: [Mesa-dev] [PATCH] llvmpipe: fix PIPE_FORMAT_Z24_UNORM_S8_UINT depth on big endian

2014-09-15 Thread Alex Deucher
On Mon, Sep 15, 2014 at 4:48 PM, Dave Airlie wrote: >> >> I never really looked at the big endian stuff so I have no idea if this >> is right. I thought though the channel shift thing now should work >> without endianness awareness if you fetch one 32bit number and then >> break it up into parts w

Re: [Mesa-dev] [PATCH] llvmpipe: fix PIPE_FORMAT_Z24_UNORM_S8_UINT depth on big endian

2014-09-15 Thread Dave Airlie
> > I never really looked at the big endian stuff so I have no idea if this > is right. I thought though the channel shift thing now should work > without endianness awareness if you fetch one 32bit number and then > break it up into parts with shifts due to the channel information being > adjusted

[Mesa-dev] [Bug 70920] [GLSL compiler] SIGSEGV for shaders/glsl-fs-inline-explosion

2014-09-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70920 --- Comment #5 from Erik Faye-Lund --- Created attachment 106343 --> https://bugs.freedesktop.org/attachment.cgi?id=106343&action=edit error-checking in glsl-compiler What's going on here, seems to be that we're running out of memory while lin

Re: [Mesa-dev] [RFC PATCH] mesa: Delete VAO _MaxElement code and index buffer bounds checking.

2014-09-15 Thread Eric Anholt
Kenneth Graunke writes: > Fredrik's implementation of ARB_vertex_attrib_binding introduced new > gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and > converted Mesa's older gl_client_array to be derived state. Ultimately, > we'd like to drop gl_client_array and use those structu

Re: [Mesa-dev] [PATCH 4/5] gallivm: add texture target information for sample opcodes to tgsi info

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 21:00, schrieb Ilia Mirkin: > On Mon, Sep 15, 2014 at 2:51 PM, wrote: >> From: Roland Scheidegger >> >> sample opcodes don't have valid texture target information (and I don't think >> this should be changed), however it would be nice if we had that information >> ready elsewhere,

Re: [Mesa-dev] [PATCH 4/5] gallivm: add texture target information for sample opcodes to tgsi info

2014-09-15 Thread Ilia Mirkin
On Mon, Sep 15, 2014 at 2:51 PM, wrote: > From: Roland Scheidegger > > sample opcodes don't have valid texture target information (and I don't think > this should be changed), however it would be nice if we had that information > ready elsewhere, so stuff that information into the tgsi info when

[Mesa-dev] [PATCH 4/5] gallivm: add texture target information for sample opcodes to tgsi info

2014-09-15 Thread sroland
From: Roland Scheidegger sample opcodes don't have valid texture target information (and I don't think this should be changed), however it would be nice if we had that information ready elsewhere, so stuff that information into the tgsi info when analyzing a shader. --- src/gallium/auxiliary/gal

[Mesa-dev] [PATCH 5/5] gallivm: attach DataLayout to module too, not just pass manager.

2014-09-15 Thread sroland
From: Rafael Ávila de Espíndola It looks like it was possible to attach it to both for a long time, however since llvm r217548 attaching it to just the pass manager is no longer sufficient and causes bugs (see http://llvm.org/bugs/show_bug.cgi?id=20903). Tested-by: Vinson Lee --- src/gallium/a

[Mesa-dev] [PATCH 2/5] tgsi: accept offsets for sample opcodes too in the text parser

2014-09-15 Thread sroland
From: Roland Scheidegger sample opcodes are a little oddly represented in the opcode_info, since they don't count as texture instructions - they don't have valid target information, but they may have offsets (unlike "ordinary" texture instructions, the texture token may be optional for them). So

[Mesa-dev] [PATCH 1/5] tgsi: don't print texture target for sample opcodes

2014-09-15 Thread sroland
From: Roland Scheidegger sample opcodes don't encode a texture target, it would thus always print UNKNOWN, which is not helpful (and wouldn't parse when giving back the shader text to tgsi). --- src/gallium/auxiliary/tgsi/tgsi_dump.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)

[Mesa-dev] [PATCH 3/5] gallivm: handle SAMPLE opcode in aos sampling

2014-09-15 Thread sroland
From: Roland Scheidegger This is just a very limited version, in particular sampler and sampler view index must be the same. It cannot handle any modifiers neither. Works much the same as soa version otherwise, to figure out the target we need to store the sampler view dcls. While here, also hand

Re: [Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 19:04, schrieb Mathias Fröhlich: > > Hi again, > > On Monday, September 15, 2014 18:11:51 Roland Scheidegger wrote: >> btw I'm not entirely sure everything is really correct with llvmpipe wrt >> that extension (the rasterization stuff, gallium isn't involved in the >> texture conver

Re: [Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 18:28, schrieb Mathias Fröhlich: > > Hi Roland, > > On Monday, September 15, 2014 16:57:49 Roland Scheidegger wrote: >> Hmm actually that wasn't right, it does make a difference if the nv or >> core format enums are used, at least for texture specification (nv won't >> clamp, wherea

Re: [Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

2014-09-15 Thread Mathias Fröhlich
Hi again, On Monday, September 15, 2014 18:11:51 Roland Scheidegger wrote: > btw I'm not entirely sure everything is really correct with llvmpipe wrt > that extension (the rasterization stuff, gallium isn't involved in the > texture conversion). There's some very annoying differences how things >

[Mesa-dev] [Bug 71199] [llvmpipe] piglit glean polygonOffset regression

2014-09-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=71199 Vinson Lee changed: What|Removed |Added Keywords||bisected Blocks|

[Mesa-dev] [Bug 79706] [TRACKER] Mesa regression tracker

2014-09-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=79706 Vinson Lee changed: What|Removed |Added Depends on||71199 -- You are receiving this mail becau

[Mesa-dev] [Bug 79706] [TRACKER] Mesa regression tracker

2014-09-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=79706 Vinson Lee changed: What|Removed |Added Depends on||70359 -- You are receiving this mail becau

[Mesa-dev] [Bug 70359] [llvmpipe] piglit arb_shader_texture_lod-texgrad regression

2014-09-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70359 Vinson Lee changed: What|Removed |Added Keywords||bisected Blocks|

Re: [Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

2014-09-15 Thread Mathias Fröhlich
Hi, On Monday, September 15, 2014 18:11:51 Roland Scheidegger wrote: > btw I'm not entirely sure everything is really correct with llvmpipe wrt > that extension (the rasterization stuff, gallium isn't involved in the > texture conversion). There's some very annoying differences how things > work

Re: [Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

2014-09-15 Thread Mathias Fröhlich
Hi Roland, On Monday, September 15, 2014 16:57:49 Roland Scheidegger wrote: > Hmm actually that wasn't right, it does make a difference if the nv or > core format enums are used, at least for texture specification (nv won't > clamp, whereas core will) and probably for rasterization too, what a >

Re: [Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 16:57, schrieb Roland Scheidegger: > Am 15.09.2014 16:41, schrieb Roland Scheidegger: >> Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net: >>> From: Mathias Fröhlich >>> >>> Will be used in the implementation of NV_depth_buffer_float. >>> >>> Signed-off-by: Mathias Froehlich >>

Re: [Mesa-dev] [PATCH 4/4] mesa: Add support for NV_depth_buffer_float.

2014-09-15 Thread Roland Scheidegger
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net: > From: Mathias Fröhlich > > This is mostly support for the unclamped versions of > glDepthRangedNV, glClearDepthdNV and glDepthBoundsdNV. > Note that OpenGL 4.2 introduced that the traditonal > glDepthRange functions may no longer clamp to

[Mesa-dev] [Bug 83631] /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared

2014-09-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83631 --- Comment #4 from Orion Poplawski --- It seems that in GL/glx.h, GL/glext.h is only included when GL_GLEXT_LEGACY is not defined (line 2049). Unfortunatly, GL_GLEXT_LEGACY is defined in Rendering/OpenGL/vtkOpenGL.h (line 22) and vtkOpenGL.h i

Re: [Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 16:41, schrieb Roland Scheidegger: > Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net: >> From: Mathias Fröhlich >> >> Will be used in the implementation of NV_depth_buffer_float. >> >> Signed-off-by: Mathias Froehlich > --- >> src/mesa/main/glformats.c | 18 ++

Re: [Mesa-dev] [PATCH] ilo: Build pipe-loader for ilo

2014-09-15 Thread Steven Newbury
On Fri, 2014-09-12 at 18:20 -0400, Nick Sarnie wrote: > Trivial patch to create the pipe loader for ilo. All the code was > already there. > > Signed-off-by: Nick Sarnie > --- > src/gallium/targets/pipe-loader/Makefile.am | 14 ++ > src/gallium/targets/pipe-loader/pipe_i965.c | 26

Re: [Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

2014-09-15 Thread Roland Scheidegger
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net: > From: Mathias Fröhlich > > Will be used in the implementation of NV_depth_buffer_float. > > Signed-off-by: Mathias Froehlich --- > src/mesa/main/glformats.c | 18 ++ > src/mesa/main/glformats.h | 3 +++ > 2 files change

Re: [Mesa-dev] [PATCH 3/4] gallium: introduce PIPE_CAP_UNCLAMPED_DEPTH_VALUES.

2014-09-15 Thread Roland Scheidegger
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net: > From: Mathias Fröhlich > > In preparation of NV_depth_buffer_float. Let the > driver decide if it could support writing depth values > beyond the [0, 1] range. > > Signed-off-by: Mathias Froehlich --- > src/gallium/docs/source/screen.rs

Re: [Mesa-dev] [PATCH] llvmpipe: fix rast debugging output

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 08:55, schrieb Dave Airlie: > From: Dave Airlie > > The triangle_32_ rast functions never made it into the debug output, > confused me for a few seconds. > > Signed-off-by: Dave Airlie > --- > src/gallium/drivers/llvmpipe/lp_rast_debug.c | 11 +++ > 1 file changed, 11 ins

Re: [Mesa-dev] [PATCH] llvmpipe: fix PIPE_FORMAT_Z24_UNORM_S8_UINT depth on big endian

2014-09-15 Thread Roland Scheidegger
Am 15.09.2014 12:22, schrieb Dave Airlie: >> We had a bug report from some screensavers in xscreensaver package >> not working on ppc64be, I took a day out to cause myself undue pain. >> >> I tracked it down to the depth buffer not being read correctly, >> I've no idea if this is the proper fix for

Re: [Mesa-dev] [PATCH] llvmpipe: fix PIPE_FORMAT_Z24_UNORM_S8_UINT depth on big endian

2014-09-15 Thread Dave Airlie
> We had a bug report from some screensavers in xscreensaver package > not working on ppc64be, I took a day out to cause myself undue pain. > > I tracked it down to the depth buffer not being read correctly, > I've no idea if this is the proper fix for it, I need to run > some more piglit on it. (m

[Mesa-dev] [PATCH] llvmpipe: fix PIPE_FORMAT_Z24_UNORM_S8_UINT depth on big endian

2014-09-15 Thread Dave Airlie
From: Dave Airlie We had a bug report from some screensavers in xscreensaver package not working on ppc64be, I took a day out to cause myself undue pain. I tracked it down to the depth buffer not being read correctly, I've no idea if this is the proper fix for it, I need to run some more piglit