[Mesa-dev] [PATCH] util: Move _mesa_fsl/util_last_bit into util/bitscan.h

From: Mathias Fröhlich Hi Brian, As requested with the initial creation of util/bitscan.h now move other bitscan related functions into util. Make use of win32 intrinsics for util_last_bit/fls if present. Signed-off-by: Mathias Fröhlich

[Mesa-dev] [PATCH] mesa: Copy bitmask of VBOs in the VAO on gl{Push, Pop}Attrib.

From: Mathias Fröhlich Hi all, The below was found by inspection. Please review. Thanks Mathias On gl{Push,Pop}Attrib(GL_CLIENT_VERTEX_ARRAY_BIT) take care that gl_vertex_array_object::VertexAttribBufferMask matches the bound buffer object in the

[Mesa-dev] cairo as state tracker

Hi folks, I'd like to get the cairo's gallium backend running again (hasn't been maintained for a long time and doesn't fit at all to recent mesa). The main problem I've got here is that gallium API is mesa-internal, so I'd like to do some steps on making it (semi-)public. I'm aware that it's

Re: [Mesa-dev] [PATCH] anv/gen7_pipeline: Set PixelShaderKillPixel when needed

Drp... There's more work to do here to get the behavior 100% correct on gen7 but this fixes a bug and is a step in the right direction. Reviewed-by: Jason Ekstrand Unfortunately, gen7 is a bit crazy so the simple solution doesn't cover all the cases. For the full fix take

[Mesa-dev] [PATCH] nir: make use of nir_cf_list_extract() helper

--- src/compiler/nir/nir_opt_dead_cf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/compiler/nir/nir_opt_dead_cf.c b/src/compiler/nir/nir_opt_dead_cf.c index 81c1b65..3551124 100644 --- a/src/compiler/nir/nir_opt_dead_cf.c +++ b/src/compiler/nir/nir_opt_dead_cf.c @@

Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*

On 08/04/2016 02:28 PM, Martin Peres wrote: On 05/08/16 00:24, Mark Janes wrote: I saw no regressions from these tests. However, I wasn't able to run the dEQP-EGL tests the last time I tried. What branch of dEQP are you running? InternalError (Runtime check failed: '(m_capabilities &

Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*

On 08/04/2016 02:24 PM, Mark Janes wrote: I saw no regressions from these tests. However, I wasn't able to run the dEQP-EGL tests the last time I tried. What branch of dEQP are you running? InternalError (Runtime check failed: '(m_capabilities & CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at

Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture (v2)

On 08/05/2016 05:42 AM, Marek Olšák wrote: > From: Marek Olšák > > Some ideas copied from Jakob Sinclair's implementation, but the color > clearing is completely different. > > v2: remove leftover code, disable conditional rendering > --- > docs/GL3.txt

Re: [Mesa-dev] Question about tesselation shader out varyings and transform feedback

On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote: > Hi, > > these days I have been trying to fix a test that uses transform > feedback > on the out varying of a tessellation shader. The relevant part on > that > shader is like this: > >    layout (vertices=4) out; > >    out block {

[Mesa-dev] [PATCH] anv/gen7_pipeline: Set PixelShaderKillPixel when needed

According to the IVB PRM Vol2 P1, this bit must be set if a pixel shader contains a discard instruction. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97207 Cc: "12.0" Signed-off-by: Nanley Chery ---

Re: [Mesa-dev] Intel: Please help define the common rectangle primitive type

On Thursday, August 4, 2016 11:28:28 AM PDT Jason Ekstrand wrote: > > > - No cut index (GS is supposed to be fine and Tess looks OK too) > > > > I'd be OK with dropping GS and Tess support for rectangles. > > I don't know that we need to but the docs say cut index doesn't work. Perhaps we should

[Mesa-dev] [PATCH - Mesa 07/10] i965: Make BLORP do sRGB encode/decode on ES 2 as well.

This should have no effect, as all drivers which support BLORP also support ES 3.0 - so ES 2.0 would be promoted and follow the ES 3 rules. ES 1.0 doesn't have BlitFramebuffer. This is purely to clarify the next patch a bit. Signed-off-by: Kenneth Graunke ---

[Mesa-dev] [PATCH - Mesa 09/10] meta: Make Meta's BlitFramebuffer() follow the GL 4.4 sRGB rules.

Just avoid whacking GL_FRAMEBUFFER_SRGB altogether, so we respect the application's setting. This appears to work. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/common/meta_blit.c | 80 + 1 file changed, 28 insertions(+), 52

[Mesa-dev] [PATCH - Mesa 05/10] i965: Drop the "do resolves in sRGB" hack.

I've never quite understood the purpose of this hack - supposedly, doing resolves in the sRGB colorspace is slightly more accurate. Currently, BlitFramebuffer() ignores sRGB encoding and decoding on OpenGL, although it encodes and decodes in GLES 3.x. The updated OpenGL 4.4 rules also allow for

[Mesa-dev] [PATCH - Mesa 04/10] i965: Bail on the BLT path if BlitFramebuffer requires sRGB conversion.

Modern OpenGL BlitFramebuffer require sRGB encode/decode when GL_FRAMEBUFFER_SRGB is enabled. The blitter can't handle this, so we need to bail. On Gen4-5, this means falling back to Meta, which should handle it. We allow sRGB <-> sRGB blits, as decode then encode ought to be a noop (other than

[Mesa-dev] [PATCH - Mesa 10/10] st/mesa: Make Gallium's BlitFramebuffer follow the GL 4.4 sRGB rules.

OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is enabled. This is technically incompatible in certain cases, but is more consistent across GL, ES, and WebGL, and more flexible. The NVIDIA 367.35 drivers appear

[Mesa-dev] [PATCH - Mesa 06/10] Revert "st/mesa: use sRGB formats for MSAA resolving if destination is sRGB"

This reverts commit 4e549ddb500cf677b6fa16d9ebdfa67cc23da097, dropping the hack from Gallium that I just deleted from i965. See the previous commit for rationale. --- src/mesa/state_tracker/st_cb_blit.c | 32 1 file changed, 32 deletions(-) diff --git

[Mesa-dev] [PATCH - Piglit 02/10] Make multisample accuracy test set GL_FRAMEBUFFER_SRGB when resolving.

For a long time, the Mesa i965 driver has contained a hack to override color spaces to sRGB when doing multisample resolves, with the following justification: * It has been observed that mulitisample resolves produce slightly better * looking images when averaging is done using destination

[Mesa-dev] [PATCH - Piglit 03/10] Change arb_framebuffer_srgb/blit to follow GL 4.4+ rules.

OpenGL originally never did sRGB decode/encode for BlitFramebuffer. OpenGL ES 3.x has always done sRGB decode/encode for BlitFramebuffer. OpenGL 4.x specifications attempted to unify this behavior, and ultimately settled on doing decode/encode if GL_FRAMEBUFFER_SRGB is enabled, which allows the

[Mesa-dev] [PATCH - Piglit 01/10] Delete fbo-srgb-blit test.

This appears to be redundant with spec/arb_framebuffer_srgb/blit which tests many more configurations. --- tests/all.py| 1 - tests/fbo/CMakeLists.gl.txt | 1 - tests/fbo/fbo-srgb-blit.c | 145 3 files changed, 147 deletions(-)

[Mesa-dev] Switching to the GL 4.4 sRGB rules for glBlitFramebuffer().

Hello, This combined patch series updates both Piglit and Mesa to implement the modern GL 4.4+ rules for sRGB encoding/decoding in BlitFramebuffer(). The new GL 4.4 rules make it possible to match the behavior of ES 3.x (always encode and decode), and the old behavior (never encode or decode).

[Mesa-dev] [PATCH - Mesa 08/10] i965: Make BLORP's BlitFramebuffer follow the GL 4.4 sRGB rules.

OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is enabled. This is technically incompatible in certain cases, but is more consistent across GL, ES, and WebGL, and more flexible. The NVIDIA 367.35 drivers appear

Re: [Mesa-dev] [PATCH 3/5] glsl: struct constructors/initializers only allow implicit conversions

On Thu, 2016-08-04 at 23:55 +0300, Andres Gomez wrote: > When an argument for a structure constructor or initializer doesn't > match the expected type, only Section 4.1.10 “Implicit Conversions” > are allowed to try to match that expected type. > > From page 32 (page 38 of the PDF) of the GLSL

Re: [Mesa-dev] [PATCH] i965: import prime buffers in the current context, not screen

On 04/08/16 19:04, Eric Anholt wrote: Martin Peres writes: This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and fixes many applications when using DRI3: - Totem with libva on hw-accelerated decoding - obs-studio, using Window Capture

Re: [Mesa-dev] OpenCL for radeon Hawaii?

On Thu, Aug 4, 2016 at 2:54 PM, Sam Halliday wrote: > Thanks Jan, > > This is what it comes up with > https://gist.github.com/fommil/c97d4c8fb2790e28ecaf8d334ebf1746 > > Are there any demo apps I could expect to run with this? What is > involved in writing missing

Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*

On 05/08/16 00:24, Mark Janes wrote: I saw no regressions from these tests. However, I wasn't able to run the dEQP-EGL tests the last time I tried. What branch of dEQP are you running? InternalError (Runtime check failed: '(m_capabilities & CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at

Re: [Mesa-dev] oldest gcc version to support ?

On 04.08.2016 17:10, Jason Ekstrand wrote: Hi, > The BSDs are still stuck at 4.2+patches for licensing reasons and they > use Mesa for graphics. I think at some point, they'll get clang in core > and they can start building with that. There are ancient RHEL versions > where the GCC version is

Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*

I saw no regressions from these tests. However, I wasn't able to run the dEQP-EGL tests the last time I tried. What branch of dEQP are you running? InternalError (Runtime check failed: '(m_capabilities & CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at egluNativeDisplay.cpp:70) -Mark Chad

[Mesa-dev] [PATCH 3/5] glsl: struct constructors/initializers only allow implicit conversions

When an argument for a structure constructor or initializer doesn't match the expected type, only Section 4.1.10 “Implicit Conversions” are allowed to try to match that expected type. From page 32 (page 38 of the PDF) of the GLSL 1.20 spec: " The arguments to the constructor will be used to

[Mesa-dev] [PATCH 2/5] glsl: Refactor implicit conversion into its own helper

v2: Refactor also the conversion to constant and replacement code (Timothy). Signed-off-by: Andres Gomez --- src/compiler/glsl/ast_function.cpp | 166 +++-- 1 file changed, 86 insertions(+), 80 deletions(-) diff --git

Re: [Mesa-dev] OpenCL for radeon Hawaii?

Hi, On Thu, 2016-08-04 at 20:54 +0100, Sam Halliday wrote: > Thanks Jan, > > This is what it comes up with > https://gist.github.com/fommil/c97d4c8fb2790e28ecaf8d334ebf1746 looks OK. > > Are there any demo apps I could expect to run with this? I was able to successfully run GEGL(GIMP) image

Re: [Mesa-dev] [PATCH 08/12] gallium/radeon/winsyses: print CS submission error number

On Tue, Aug 2, 2016 at 4:38 PM, Nicolai Hähnle wrote: > On 29.07.2016 23:42, Marek Olšák wrote: >> >> From: Marek Olšák >> >> --- >> src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 2 +- >> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +- >> 2 files

Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*

I'll test it. Chad Versace writes: > Hi Intel folks, could one of you please run this through Jenkins? > I verified manually that it fixes the listed dEQP tests on Skylake. > > Chad Versace (2): > i965: Fix miptree layout for EGLImage-based renderbuffers > i965: Respect

[Mesa-dev] [PATCH 1/2] i965: Fix miptree layout for EGLImage-based renderbuffers

When glEGLImageTargetRenderbufferStorageOES() was given an EGLImage created from the non-base slice of a miptree, intel_image_target_renderbuffer_storage() forgot to apply the intra-tile offsets __DRIimage::tile_x,tile_y to the miptree layout. This patch fixes the problem with a quick hack

[Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*

Hi Intel folks, could one of you please run this through Jenkins? I verified manually that it fixes the listed dEQP tests on Skylake. Chad Versace (2): i965: Fix miptree layout for EGLImage-based renderbuffers i965: Respect miptree offsets in intel_readpixels_tiled_memcpy()

[Mesa-dev] [PATCH 2/2] i965: Respect miptree offsets in intel_readpixels_tiled_memcpy()

Respect intel_miptree_slice::x_offset,y_offset and intel_mipmap_tree::offset. All three may be non-zero when glReadPixels is called on an EGLImage created from the non-base slice of a miptree. Patch 2/2 that fixes test 'dEQP-EGL.functional.image.create.gles2_cubemap_*'. Reported-by: Haixia Shi

Re: [Mesa-dev] OpenCL for radeon Hawaii?

Thanks Jan, This is what it comes up with https://gist.github.com/fommil/c97d4c8fb2790e28ecaf8d334ebf1746 Are there any demo apps I could expect to run with this? What is involved in writing missing functionality? Number of platforms 1 Platform Name Clover Platform Vendor Mesa Platform Version

[Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture (v2)

From: Marek Olšák Some ideas copied from Jakob Sinclair's implementation, but the color clearing is completely different. v2: remove leftover code, disable conditional rendering --- docs/GL3.txt | 2 +- docs/relnotes/12.1.0.html

Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture

On Aug 4, 2016 13:17, "Marek Olšák" wrote: > > On Thu, Aug 4, 2016 at 8:04 PM, Ilia Mirkin wrote: > > I believe that clear depth stencil is meant to respect the render condition, > > while clear texture is not. In nouveau I "solved" this by ignoring the >

Re: [Mesa-dev] Intel: Please help define the common rectangle primitive type

On Aug 4, 2016 10:33 AM, "Marek Olšák" wrote: > > On Thu, Aug 4, 2016 at 3:31 PM, Jason Ekstrand wrote: > > Hey Marek, Thanks for working on this! > > > > On Aug 4, 2016 7:39 AM, "Marek Olšák" wrote: > >> > >> Hi, > >> > >> This is my

Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture

On Thu, Aug 4, 2016 at 8:04 PM, Ilia Mirkin wrote: > I believe that clear depth stencil is meant to respect the render condition, > while clear texture is not. In nouveau I "solved" this by ignoring the > render condition in the clear depth stencil function too, since

Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture

I believe that clear depth stencil is meant to respect the render condition, while clear texture is not. In nouveau I "solved" this by ignoring the render condition in the clear depth stencil function too, since nothing in Mesa relied on it iirc. On Aug 4, 2016 12:57, "Marek Olšák"

Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture

On Thu, Aug 4, 2016 at 7:56 PM, Marek Olšák wrote: > From: Marek Olšák > > Some ideas copied from Jakob Sinclair's implementation, but the color > clearing is completely different. > --- > docs/GL3.txt | 2 +- >

[Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture

From: Marek Olšák Some ideas copied from Jakob Sinclair's implementation, but the color clearing is completely different. --- docs/GL3.txt | 2 +- docs/relnotes/12.1.0.html | 1 + src/gallium/drivers/r600/r600_pipe.c | 2

Re: [Mesa-dev] [PATCH 1/3] freedreno/a2xx: fix comparison out of range warnings

Hi Eric, after your question: [snip] I expect, with enums having varying size, that this cast will not always work. [snip] I started a script for testing with variable enum sizes and compilers... If does makes sense to you, I'll try to loop from 1 to n (suggestions?) and build with gcc and

Re: [Mesa-dev] [PATCH v2 3/4] gallium/winsys/kms: Move display target handle lookup to separate function (v2)

On 2016-08-02 03:46:27, Tomasz Figa wrote: > As a preparation to use the lookup in more than once place, move the > code that looks up given KMS/GEM handle to a separate function. This > change should not introduce any functional changes. > > v2: Split into separate patch. > Move lookup code

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

Hi Andy, On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss wrote: > Nayan Deshmukh wrote: > >> Hi Andy, >> >> Thanks for testing my patches. >> > > NP > > > The scaling happens after CSC. >>> >> > OK, thanks. > > > I believe there is some misunderstanding here, I was able to

Re: [Mesa-dev] [PATCH] swrast: fix active attribs with atifragshader

On 08/04/2016 10:40 AM, Miklós Máté wrote: On 07/14/2016 10:43 PM, Miklós Máté wrote: On 07/07/2016 07:11 PM, Miklós Máté wrote: On 06/26/2016 09:48 PM, Miklós Máté wrote: Only include the ones that can be used by the shader. This fixes texture coordinates, which were completely wrong,

Re: [Mesa-dev] [PATCH] swrast: fix active attribs with atifragshader

On 07/14/2016 10:43 PM, Miklós Máté wrote: On 07/07/2016 07:11 PM, Miklós Máté wrote: On 06/26/2016 09:48 PM, Miklós Máté wrote: Only include the ones that can be used by the shader. This fixes texture coordinates, which were completely wrong, because WPOS was included in the list of attribs.

[Mesa-dev] Question about tesselation shader out varyings and transform feedback

Hi, these days I have been trying to fix a test that uses transform feedback on the out varying of a tessellation shader. The relevant part on that shader is like this: layout (vertices=4) out; out block { vec4 value; } user_out[]; The test tries to use block.value as the varying name

Re: [Mesa-dev] [PATCH] i965: import prime buffers in the current context, not screen

Martin Peres writes: > This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and > fixes many applications when using DRI3: > - Totem with libva on hw-accelerated decoding > - obs-studio, using Window Capture (Xcomposite) as a Source > - gstreamer with

Re: [Mesa-dev] Intel: Please help define the common rectangle primitive type

On Thu, Aug 4, 2016 at 3:31 PM, Jason Ekstrand wrote: > Hey Marek, Thanks for working on this! > > On Aug 4, 2016 7:39 AM, "Marek Olšák" wrote: >> >> Hi, >> >> This is my definition so far, which is an intersection of AMD and NV >> rectangles: >> >>

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

Nayan Deshmukh wrote: Hi Andy, Thanks for testing my patches. NP The scaling happens after CSC. OK, thanks. I believe there is some misunderstanding here, I was able to see the artifacts in the video that you sent me previously. But I was not able to replicate them Yea, I got that -

Re: [Mesa-dev] oldest gcc version to support ?

On Aug 4, 2016 2:57 AM, "Enrico Weigelt, metux IT consult" < enrico.weig...@gr13.net> wrote: > > Hi folks, > > > which is the oldest gcc version we need to support ? > > I see certain quirks for pre 4.4.5 - my Ubuntu Trusty box > (now over 2 years old) already has 4.8 ... can we remove > that

Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error

On Thu, Aug 4, 2016 at 10:43 PM, Martin Peres wrote: > > > On 04/08/16 15:17, Nicolas Boichat wrote: >> >> On Thu, Aug 4, 2016 at 7:17 PM, Martin Peres >> wrote: >>> >>> >>> >>> On 04/08/16 13:08, Nicolas Boichat wrote:

Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error

On 04/08/16 15:17, Nicolas Boichat wrote: On Thu, Aug 4, 2016 at 7:17 PM, Martin Peres wrote: On 04/08/16 13:08, Nicolas Boichat wrote: On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres wrote: On 04/08/16 05:07, Nicolas Boichat

Re: [Mesa-dev] __func__ vs. __FUNCTION__

On 08/04/2016 07:56 AM, Jason Ekstrand wrote: On Aug 4, 2016 12:46 AM, "Enrico Weigelt, metux IT consult" > wrote: > > On 03.08.2016 12:20, Eric Engestrom wrote: > > > BTW, c99_compat.h has a #define for __func__ where needed, so this

[Mesa-dev] [PATCH RESEND] wayland-drm: add missing NULL check

Although malloc is unlikely to fail check its return value nevertheless. Signed-off-by: Frank Binns Reviewed-by: Eric Engestrom --- src/egl/wayland/wayland-drm/wayland-drm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[Mesa-dev] [PATCH RESEND] loader: fix sysfs uevent file parsing

When trying to get a device name for an fd using sysfs, it would always fail as it was expecting key/value pairs to be delimited by '\0', which is not the case. Signed-off-by: Frank Binns Reviewed-by: Eric Engestrom --- src/loader/loader.c | 6

Re: [Mesa-dev] __func__ vs. __FUNCTION__

On Aug 4, 2016 12:46 AM, "Enrico Weigelt, metux IT consult" < enrico.weig...@gr13.net> wrote: > > On 03.08.2016 12:20, Eric Engestrom wrote: > > > BTW, c99_compat.h has a #define for __func__ where needed, so this > > change (removing use of __FUNCTION__) is a good one indeed :) > > Did a few

Re: [Mesa-dev] [PATCH 1/3] egl/x11_dri3: disable WL_bind_wayland_display for devices without render nodes

On 20/06/16 12:05, Axel Davy wrote: Hi, The three patches make sense to me. Reviewed-by: Axel Davy Can someone push these patches for me? Thanks Frank On 17/06/2016 19:41, Frank Binns wrote : Up until now, DRI3 was only used for devices that have render nodes, unless

Re: [Mesa-dev] Intel: Please help define the common rectangle primitive type

Hey Marek, Thanks for working on this! On Aug 4, 2016 7:39 AM, "Marek Olšák" wrote: > > Hi, > > This is my definition so far, which is an intersection of AMD and NV rectangles: > > Definition and behavior: > - The rectangle primitive is defined by its first 3 vertices. > - The

[Mesa-dev] [PATCH] i965: import prime buffers in the current context, not screen

This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and fixes many applications when using DRI3: - Totem with libva on hw-accelerated decoding - obs-studio, using Window Capture (Xcomposite) as a Source - gstreamer with VAAPI Cc: mesa-sta...@lists.freedesktop.org Bugzilla:

Re: [Mesa-dev] [PATCH 3/3] radeonsi: move spi_ps_input_addr override outside of the loop

For the series: Reviewed-by: Marek Olšák Marek On Wed, Aug 3, 2016 at 10:56 PM, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > --- > src/gallium/drivers/radeonsi/si_shader.c | 6 +++--- > 1 file changed, 3 insertions(+), 3

[Mesa-dev] Intel: Please help define the common rectangle primitive type

Hi, This is my definition so far, which is an intersection of AMD and NV rectangles: Definition and behavior: - The rectangle primitive is defined by its first 3 vertices. - The 4th vertex is derived (extrapolated) during rasterization. - It's treated as a triangle by all stages before

[Mesa-dev] [Bug 97136] [softpipe] piglit egl-create-context-verify-gl-flavor regression

https://bugs.freedesktop.org/show_bug.cgi?id=97136 Nicolas Boichat changed: What|Removed |Added CC|nico...@boichat.ch | -- You are

[Mesa-dev] [Bug 97136] [softpipe] piglit egl-create-context-verify-gl-flavor regression

https://bugs.freedesktop.org/show_bug.cgi?id=97136 Nicolas Boichat changed: What|Removed |Added Status|NEW |ASSIGNED

Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error

On Thu, Aug 4, 2016 at 7:17 PM, Martin Peres wrote: > > > On 04/08/16 13:08, Nicolas Boichat wrote: >> >> On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres >> wrote: >>> >>> On 04/08/16 05:07, Nicolas Boichat wrote: egl/x11

Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error

On 04/08/16 13:08, Nicolas Boichat wrote: On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres wrote: On 04/08/16 05:07, Nicolas Boichat wrote: egl/x11 fixup has already be sent here: https://patchwork.freedesktop.org/patch/101934/ Compile-tested only (on android

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

Hi Andy, Thanks for testing my patches. On Thu, Aug 4, 2016 at 5:23 AM, Andy Furniss wrote: > Nayan Deshmukh wrote: > >> Hi Christian >> >> On Wed, Aug 3, 2016 at 6:16 PM, Christian König >> wrote: >> >> Sorry for the delay I've been on vacation

Re: [Mesa-dev] c99 vs v90

On 04/08/16 11:25, Enrico Weigelt, metux IT consult wrote: On 04.08.2016 11:38, Jose Fonseca wrote: __FUNCTION__ has been around for a very long time (before 1999), so it's no surprise that MSVC has it. But not implementing __func__ does seem a oversight. I believe they fixed it on MSVC

Re: [Mesa-dev] oldest gcc version to support ?

On 08/04/2016 09:57 AM, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > > which is the oldest gcc version we need to support ? > > I see certain quirks for pre 4.4.5 - my Ubuntu Trusty box > (now over 2 years old) already has 4.8 ... can we remove > that stuff ? > > (anyways, it's just

Re: [Mesa-dev] c99 vs v90

On 04.08.2016 11:38, Jose Fonseca wrote: > __FUNCTION__ has been around for a very long time (before 1999), so it's > no surprise that MSVC has it. But not implementing __func__ does seem a > oversight. I believe they fixed it on MSVC 2015. hmm, okay. as long as we're supporting msvc'03, I'd

Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error

On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres wrote: > On 04/08/16 05:07, Nicolas Boichat wrote: >> >> egl/x11 fixup has already be sent here: >> https://patchwork.freedesktop.org/patch/101934/ >> >> Compile-tested only (on android only). >> >> I was first thinking of

[Mesa-dev] non-shared glapi still needed ? [WAS: what happened to libgallium.so ?]

On 04.08.2016 11:21, Marek Olšák wrote: > src/glx isn't gallium. src/glx isn't even used on Windows. That linked > file is completely disconnected from everything this thread is about. ups, I mixed up several threads ... I meant the shared glapi library. (see the other thread "non-shared glapi

Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error

On 04/08/16 05:07, Nicolas Boichat wrote: egl/x11 fixup has already be sent here: https://patchwork.freedesktop.org/patch/101934/ Compile-tested only (on android only). I was first thinking of modifying most functions in egl_dri2.c to take in dri2_egl_display *dri2_dpy instead of _EGLDisplay

Re: [Mesa-dev] c99 vs v90

On 04/08/16 01:48, Enrico Weigelt, metux IT consult wrote: On 03.08.2016 23:28, Jose Fonseca wrote: Hi, There are minor inconsistencies. For example, it doesn't support __func__, but doing #define __func__ __FUNCTION__ suffices to make __func__ work compatible. Wait a second ... IIRC,

Re: [Mesa-dev] what happened to libgallium.so ?

On Thu, Aug 4, 2016 at 7:48 AM, Enrico Weigelt, metux IT consult wrote: > On 03.08.2016 18:09, Marek Olšák wrote: >> It has always been statically linked as far as I remember. >> libgallium.so is a Ubuntu speciality that we don't support. > > on win32 (using scons), it

[Mesa-dev] oldest gcc version to support ?

Hi folks, which is the oldest gcc version we need to support ? I see certain quirks for pre 4.4.5 - my Ubuntu Trusty box (now over 2 years old) already has 4.8 ... can we remove that stuff ? (anyways, it's just for non-autoconf builds) --mtx ___