Re: [Mesa-dev] [PATCH 1/2] gallium: add PIPE_DRIVER_QUERY_FLAG_DONT_LIST

The series is: Reviewed-by: Marek Olšák Marek On Tue, Nov 24, 2015 at 5:05 PM, Nicolai Hähnle wrote: > This allows the driver to give a hint to the HUD so that GALLIUM_HUD=help is > less spammy. > --- > src/gallium/auxiliary/hud/hud_context.c | 10

[Mesa-dev] [PATCH 1/5] i965/meta-fast-clear: Disable GL_FRAMEBUFFER_SRGB during clear

Adds MESA_META_FRAMEBUFFER_SRGB to the meta save state so that GL_FRAMEBUFFER_SRGB will be disabled when performing the fast clear. That way the render surface state will be programmed with the linear equivalent format during the clear. This is important for Gen9 because the SRGB formats are not

[Mesa-dev] [PATCH 5/5] i965/gen9: Don't do fast clears when GL_FRAMEBUFFER_SRGB is enabled

When GL_FRAMEBUFFER_SRGB is enabled any single-sampled renderbuffers are resolved in intel_update_state because the hardware can't cope with fast clears on SRGB buffers. In that case it's pointless to do a fast clear because it will just be immediately resolved. ---

[Mesa-dev] [PATCH 4/5] i965/gen9: Allow fast clears for non-MSRT SRGB buffers

SRGB buffers are not marked as losslessly compressible so previously they would not be used for fast clears. However in practice the hardware will never actually see that we are using SRGB buffers for fast clears if we use the linear equivalent format when clearing and make sure to resolve the

[Mesa-dev] [PATCH 2/5] i965/gen8+: Don't upload the MCS buffer for single-sampled textures

For single-sampled textures the MCS buffer is only used to implement fast clears. However the surface always needs to be resolved before being used as a texture anyway so the the MCS buffer doesn't actually achieve anything. This is important for Gen9 because in that case SRGB surfaces are not

Re: [Mesa-dev] [PATCH v3 06/42] i965: Import tables enumerating the set of validated L3 configurations.

Just to make it explicit, Reviewed-by: Samuel Iglesias Gonsálvez Sam On 25/11/15 15:24, Francisco Jerez wrote: > It should be possible to use additional L3 configurations other than > the ones listed in the tables of validated allocations ("BSpec » > 3D-Media-GPGPU Engine

Re: [Mesa-dev] [Mesa-announce] Mesa 11.1.0 release candidate 1

Hi Emil, I noticed that this branchpoint is after the KHR_DEBUG patches which broke GL conformance. Is the plan to resolve this bug before release? https://bugs.freedesktop.org/show_bug.cgi?id=93048 -Mark Emil Velikov writes: > On 23 November 2015 at 09:18, Thierry

[Mesa-dev] [PATCH] docs: minimum required python mako version is 0.3.4

Signed-off-by: Samuel Iglesias Gonsálvez --- docs/install.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/install.html b/docs/install.html index a90c2b2..c826d64 100644 --- a/docs/install.html +++ b/docs/install.html @@ -39,7 +39,7 @@ Version

Re: [Mesa-dev] [PATCH] gallium/tests: fix build with clang compiler

On 11/25/2015 05:16 PM, Eirik Byrkjeflot Anonsen wrote: Samuel Pitoiset writes: Nested functions are supported as an extension in GNU C, but Clang don't support them. This fixes compilation errors when (manually) building compute.c, or by setting

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

https://bugs.freedesktop.org/show_bug.cgi?id=93103 --- Comment #2 from Emil Velikov --- Hmm I'm pretty sure that I removed all of those an year or two ago. And looking at the patches in said report, it seems that it was a problem on their end -> they were not hiding

Re: [Mesa-dev] [PATCH] docs: minimum required python mako version is 0.3.4

On 25 November 2015 at 15:35, Samuel Iglesias Gonsálvez wrote: > Signed-off-by: Samuel Iglesias Gonsálvez > --- > docs/install.html | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/docs/install.html b/docs/install.html > index

Re: [Mesa-dev] [PATCH] gallium/tests: fix build with clang compiler

Samuel Pitoiset writes: > Nested functions are supported as an extension in GNU C, but Clang > don't support them. > > This fixes compilation errors when (manually) building compute.c, > or by setting --enable-gallium-tests to the configure script. > > Bugzilla:

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

https://bugs.freedesktop.org/show_bug.cgi?id=93103 --- Comment #3 from Emil Velikov --- (In reply to Jose Fonseca from comment #1) > In addition to that, we probably also need to use a LD version script to > ensure that LLVM symbols don't pop in the dynamic symbol

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

https://bugs.freedesktop.org/show_bug.cgi?id=93103 Jose Fonseca changed: What|Removed |Added CC||jfons...@vmware.com

[Mesa-dev] [PATCH] nv50, nvc0: allow to create resources other than buffers

For the compute support, we might create 1D/2D/3D textures. This fixes an assertion when executing src/gallium/tests/trivial/compute. Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/nouveau/nv50/nv50_resource.c | 2 --

Re: [Mesa-dev] [PATCH v2 2/2] targets: use the non-inline sw helpers

On Mon, Nov 23, 2015 at 10:28 AM, Emil Velikov wrote: > Previously (with the inline ones) things were embedded into the > pipe-loader, which means that we cannot control/select what we want in > each target. > > That also meant that at runtime we ended up with the empty

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

https://bugs.freedesktop.org/show_bug.cgi?id=93103 Bug ID: 93103 Summary: llvm symbols leak through, cause trouble with software rendering in llvm-linked software Product: Mesa Version: 10.1 Hardware: Other

[Mesa-dev] [PATCH 0.5/5] i965/gen9/fast-clear: Handle linear→SRGB conversion

If GL_FRAMEBUFFER_SRGB is enabled when writing to an SRGB-capable framebuffer then the color will be converted from linear to SRGB before being written. There is no chance for the hardware to do this itself because it can't modify the clear color that is programmed in the surface state so it seems

Re: [Mesa-dev] [PATCH] mesa/main: TexImage2DMultisample needs to pass OpenGL3.3 conformance test.

On Wed, 2015-11-25 at 17:13 +0200, Tapani Pälli wrote: > On 11/25/2015 04:00 PM, Predut, Marius wrote: > > > -Original Message- > > > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On > > > Behalf Of > > > Timothy Arceri > > > Sent: Wednesday, November 25, 2015 1:12 PM > >

Re: [Mesa-dev] [PATCH] i965: Don't inline intel_batchbuffer_require_space().

On Wed, Nov 25, 2015 at 1:21 AM, Chris Wilson wrote: > On Tue, Nov 24, 2015 at 11:07:54PM -0800, Kenneth Graunke wrote: >> On Tuesday, November 24, 2015 05:17:29 PM Matt Turner wrote: >> > It's called by the inline intel_batchbuffer_begin() function which >> > itself is

Re: [Mesa-dev] [PATCH] nv50, nvc0: allow to create resources other than buffers

Yeah, but these are "restricted" surfaces. You can't use them as, e.g., render targets. And the whole surface concept is going to go away, with pipe_buffer_view and pipe_image_view. If you really like, move these asserts to where surfaces are used with the assumption that a miptree is backing

[Mesa-dev] question on GL_RED and gles

Hi, In EXT_texture_rg.txt it is mentioned of GL_RED_EXT on gles 2.0. In glformats.c::_mesa_es_error_check_format_and_type returns GL_INVALID_VALUE if GL_RED_EXT(as it reaches default case) so glTexImage2D(..., GL_RED_EXT, GL_UNSIGNED_BYTE, data) fails. Though GL_EXTENSIONS contains

Re: [Mesa-dev] [PATCH v2 5.5/42] i965: Add slice count to the brw_device_info structure.

Reviewed-by: Samuel Iglesias Gonsálvez On 25/11/15 15:22, Francisco Jerez wrote: > --- > src/mesa/drivers/dri/i965/brw_device_info.c | 20 > src/mesa/drivers/dri/i965/brw_device_info.h | 5 + > 2 files changed, 25 insertions(+) > > diff --git

[Mesa-dev] [Bug 93091] [opencl] segfault when running any opencl programs (like clinfo)

https://bugs.freedesktop.org/show_bug.cgi?id=93091 --- Comment #7 from Aaron Watry --- Bah, ignore me. I could still reproduce the issue yesterday to the best of my knowledge, but after an llvm/mesa rebuild with the patch applied this morning, things are working correctly...

Re: [Mesa-dev] [PATCH 23/24] i965/vec4: Replace src_reg(imm) constructors with brw_imm_*().

On Wed, Nov 25, 2015 at 2:48 PM, Matt Turner wrote: > The code seems fine to me. Here's what I see: > > We start with remaining_channels = WRITEMASK_XYZW. We initialize an > element of imm[] for each enabled bit of inst->dst.writemask, and then > we disable those bits from

Re: [Mesa-dev] [RFC 0/5] nir: Separate Textures and Samplers

On Tuesday, November 03, 2015 01:25:59 PM Jason Ekstrand wrote: > Separate textures and samplers are something that a lot of hardware > supports. Our hardware in particular has done this ever since the original > i965 chips. Part of this is because DX has made it a requirement for some > time

Re: [Mesa-dev] [PATCH 23/24] i965/vec4: Replace src_reg(imm) constructors with brw_imm_*().

On Tue, Nov 3, 2015 at 10:58 AM, Emil Velikov wrote: > On 3 November 2015 at 18:20, Matt Turner wrote: >> On Tue, Nov 3, 2015 at 8:09 AM, Emil Velikov >> wrote: >>> On 3 November 2015 at 00:29, Matt Turner

Re: [Mesa-dev] [PATCH 1/2] i965: Do not apply CSE opt to MOV immediate

On Wed, Nov 25, 2015 at 5:36 AM, Juan A. Suarez Romero wrote: > If the shader asm code is something like: > > mov vgrf2767.0:F, [13F, 14F, 15F, 16F] > mov vgrf2768.0:F, [9F, 10F, 11F, 12F] > mov m8:F, [13F, 14F, 15F, 16F] > mov m7:F, [9F, 10F, 11F, 12F] > > And we apply

Re: [Mesa-dev] [RFC 5/5] i965/vec4: Plumb separate surfaces and samplers through from NIR

On Tuesday, November 03, 2015 01:26:04 PM Jason Ekstrand wrote: > --- > src/mesa/drivers/dri/i965/brw_vec4.h | 4 +++- > src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 27 > ++ > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 12 > 3 files

[Mesa-dev] [PATCH v2 2/8] mesa: do not enable KHR_debug for ES 1.0

The extension requires (cough implements) GetPointervKHR (alias of GetPointerv) which in itself is available for ES 1.1 enabled mesa. Anyone willing to fish around and implement it for ES 1.0 is more than welcome to revert this commit. Until then lets restrict things. Bugzilla:

[Mesa-dev] [PATCH v2 6/8] mesa: accept TYPE_PUSH/POP_GROUP with glDebugMessageInsert

These new (relative to ARB_debug_output) tokens, have been explicitly separated from the existing ones in the spec text. With the reference to glDebugMessageInsert was dropped. At the same time, further down the spec says: "The value of must be one of the values from Table 5.4" ... and these

[Mesa-dev] [PATCH v2 7/8] mesa: errors: validate the length of null terminated string

We're about to rework the meaning of gl_debug_message::length to store the user provided data. Thus we should add an explicit validation for null terminated strings. Signed-off-by: Emil Velikov --- src/mesa/main/errors.c | 20 +--- 1 file changed, 17

[Mesa-dev] [PATCH v2 8/8] mesa: rework the meaning of gl_debug_message::length

Currently it stores strlen(buf) whenever the user originally provided a negative value for length. Although I've not seen any explicit text in the spec, CTS requires that the very same length (be that negative value or not) is returned back on Pop. So let's push down the length < 0 checks, tweak

[Mesa-dev] [PATCH v2 5/8] mesa: add SEVERITY_NOTIFICATION to default state

As per the spec quote: "All messages are initially enabled unless their assigned severity is DEBUG_SEVERITY_LOW" We already had MEDIUM and HIGH set, let's toggle NOTIFICATION as well. Signed-off-by: Emil Velikov Reviewed-by: Timothy Arceri

[Mesa-dev] [PATCH v2 3/8] mesa: rename GroupStackDepth to CurrentGroup

The variable is used as the actual index, rather than the size of the group stack - rename it to reflect that. Suggested-by: Ilia Mirkin Signed-off-by: Emil Velikov --- src/mesa/main/errors.c | 32 1 file changed,

[Mesa-dev] [PATCH v2 4/8] mesa: return the correct value for GroupStackDepth

We already have one group (the default) as specif iced in the spec. So lets return its size, rather than the index of the current group. Signed-off-by: Emil Velikov --- src/mesa/main/errors.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH v2 1/8] glapi: add GetPointervKHR to the ES dispatch

The KHR_debug extension implements this. Strictly speaking it could be used with ES 1.0, although as the original function is available on ES 1.1, I'm inclined to lift the KHR_debug requirement to ES 1.1. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93048 Signed-off-by: Emil Velikov

[Mesa-dev] [PATCH v2 0/8] GL_KHR_debug fixes

Hi all, A bit of an update from last time around: - Renamed GroupStackDepth to CurrentGroup, as Ilia suggested - No more hacks - Validate the length on null terminated strings - Return the correct total length in GetDebugMessageLog With these in place CTS test now passes. A full spin is

Re: [Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

On Wed, Nov 25, 2015 at 10:31 AM, Matt Turner wrote: > On Wed, Nov 25, 2015 at 4:15 AM, Juan A. Suarez Romero > wrote: >> When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk, >> in a separate file. >> >> But as fs_visitor::optimize()

Re: [Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

On Wednesday, November 25, 2015 10:31:24 AM Matt Turner wrote: > On Wed, Nov 25, 2015 at 4:15 AM, Juan A. Suarez Romero > wrote: > > When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk, > > in a separate file. > > > > But as fs_visitor::optimize() and

Re: [Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

On Wed, Nov 25, 2015 at 10:46 AM, Jason Ekstrand wrote: > On Wed, Nov 25, 2015 at 10:45 AM, Matt Turner wrote: >> On Wed, Nov 25, 2015 at 10:37 AM, Jason Ekstrand >> wrote: >>> On Wed, Nov 25, 2015 at 10:31 AM, Matt Turner

Re: [Mesa-dev] [PATCH 1/2] i965: Fix fragment shader struct inputs.

On Tue, Nov 24, 2015 at 10:35 PM, Kenneth Graunke wrote: > Apparently we have literally no support for FS varying struct inputs. > This is somewhat surprising, given that we've had tests for that very > feature that have been passing for a long time. > > Normally, varying

Re: [Mesa-dev] [PATCH 0/5] i965/gen9: Support fast clear on SRGB buffers

On Wed, Nov 25, 2015 at 06:36:34PM +0100, Neil Roberts wrote: [snip] > > Sadly there is a second obstacle stopping window system buffers from > using fast clears which as that they are always x-tiled and supposedly > SKL doesn't support that. This is explicitly disabled in >

Re: [Mesa-dev] [PATCH 2/2] i965: run brw_vec4 optimizations in loop

On Wed, Nov 25, 2015 at 5:36 AM, Juan A. Suarez Romero wrote: > When analyzing output for glsl-mat-from-int-ctor-03 piglit test, found > that the following piece of generated asm code: > > mov(8) g19<1>.xyzF g6<4,4,1>.xyzzD { align16 1Q > }; >

Re: [Mesa-dev] [RFC 1/5] nir: Separate texture from sampler in nir_tex_instr

On Tuesday, November 03, 2015 01:26:00 PM Jason Ekstrand wrote: > This commit adds the capability to NIR to support separate textures and > samplers. As it currently stands, glsl_to_nir only sets the sampler and > leaves the texture alone as it did before and nir_lower_samplers assumes > this.

Re: [Mesa-dev] [RFC 3/5] i965/fs: Plumb separate surfaces and samplers through from NIR

On Tuesday, November 03, 2015 01:26:02 PM Jason Ekstrand wrote: > --- > src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 2 +- > src/mesa/drivers/dri/i965/brw_fs.cpp| 47 > +++-- > src/mesa/drivers/dri/i965/brw_fs.h | 4 ++- >

Re: [Mesa-dev] [PATCH 0/2] Run post opt_vector_float() opts in a loop

On Wed, Nov 25, 2015 at 5:36 AM, Juan A. Suarez Romero wrote: > > When checking output VS in glsl-mat-from-int-ctor-03 piglit, I got the > following > (part of) code. > > mov(8) g19<1>.xyzF g6<4,4,1>.xyzzD { align16 > 1Q }; > dp4(8)

Re: [Mesa-dev] [PATCH 4/9] compiler: introduce a libcompiler static library

On 25 November 2015 at 21:54, Matt Turner wrote: > On Wed, Nov 25, 2015 at 1:31 PM, Emil Velikov > wrote: >> From: Emil Velikov >> >> Currently it's an empty library, although it'll be used to store common >> code

Re: [Mesa-dev] [Mesa-stable] [PATCH] swrast: Fix the coordinates passed to _mesa_regions_overlap()

On Wed, Nov 25, 2015 at 10:44 AM, Matt Turner wrote: > On Wed, Nov 25, 2015 at 10:22 AM, Ian Romanick wrote: >> Is this related to a bugzilla or a failing test case? If not, could we >> get it piglit for it? >> >> Either way, looking at

Re: [Mesa-dev] [PATCH v2 4/8] mesa: return the correct value for GroupStackDepth

On Wed, Nov 25, 2015 at 7:36 PM, Emil Velikov wrote: > We already have one group (the default) as specif iced in the spec. So what's a "specif iced"? is that like iced tea? > lets return its size, rather than the index of the current group. > > Signed-off-by: Emil

Re: [Mesa-dev] [RFC 5/5] i965/vec4: Plumb separate surfaces and samplers through from NIR

On Nov 25, 2015 4:18 PM, "Kenneth Graunke" wrote: > > On Tuesday, November 03, 2015 01:26:04 PM Jason Ekstrand wrote: > > --- > > src/mesa/drivers/dri/i965/brw_vec4.h | 4 +++- > > src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 27 ++ >

Re: [Mesa-dev] [PATCH 1/3] dri_interface: Introduce __DRI_IMAGE_USE_SCANOUT_ROTATION_* flags (v3)

On Wed, 25 Nov 2015 18:38:50 +0900 Michel Dänzer wrote: > On 21.11.2015 12:38, Vivek Kasireddy wrote: > > These flags can be used by the DRI driver to set additional > > requirements such as tiling while creating buffers. > > > > v2: Added a brief comment to explain the

[Mesa-dev] [PATCH 01/12] mesa: Cut enum_strings.cpp test down to a few hand-chosen enums.

The previous contents appeared to be the output of some form of code generation for all enums, with a few entries hand-edited to deal with oddness. The downside to this was that when an enum gets promoted from vendor to _EXT or _EXT to _ARB or _ARB to core, make check starts failing even when the

[Mesa-dev] [PATCH 09/12] mesa: Drop bitfield "enums" from the enum-to-string table.

Asking the table for bitfield names doesn't make any sense. For 0x10, do you want GL_GLYPH_HORIZONTAL_BEARING_ADVANCE_BIT_NV or GL_COLOR_BUFFER_BIT4_QCOM or GL_POLYGON_STIPPLE_BIT or GL_SHADER_GLOBAL_ACCESS_BARRIER_BIT_NV? Giving a useful answer would depend on a whole lot of context. This also

[Mesa-dev] [PATCH 08/12] mesa: Switch to using the Khronos registry for generating enums.

I've used a bunch of python code to cut out new enums so that the two generated files can be diffed. I'll remove all that hardcoding in the following commits. All remaining differences between the generated code: - GL_TEXTURE_BUFFER_FORMAT didn't appear in GL3 when TBOs got merged to core, so

[Mesa-dev] [PATCH 11/12] mesa: Use a 32-bit offset for the enums.c string offset table.

With GLES 3.1, GL 4.5, and many new vendor extensions about to get their enums added, we jump up to 85k of table. --- src/mapi/glapi/gen/gl_enums.py | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/mapi/glapi/gen/gl_enums.py b/src/mapi/glapi/gen/gl_enums.py index

[Mesa-dev] [PATCH 05/12] mesa: Drop enums that had been removed in later revs of specs.

Mesa hasn't been using these enums and the finalized specs don't reference them, so losing them from our generated enum-to-string code should be fine. Reduces diffs to generating from Khronos XML, which has these enums noted defined but commented out from any consumers. ---

[Mesa-dev] [PATCH 10/12] mesa: Prefer newer names to older ones among names present in core.

Sometimes GL likes to rename an old enum when it grows a more general purpose, and we should prefer the new name. Changes from this: GL_POINT/LINE_SIZE_* (1.1) -> GL_SMOOTH_POINT/LINE_SIZE_* (1.2) GL_FOG_COORDINATE_* (1.4) -> GL_FOG_COORD_* (1.5) GL_SOURCE[012]_RGB/ALPHA (1.3) -> GL_SRC0_RGB

[Mesa-dev] [PATCH 12/12] mesa: Drop the blacklisting of new GL enums.

Now when people need new extensions, they can skip the entire enum-definition process, and we can stop reviewing new extension XML for its enum content. This also brings in a new enum that I wanted to use in enum_strings.cpp for testing the code generator. --- src/mapi/glapi/gen/gl_enums.py

[Mesa-dev] [PATCH 07/12] mesa: Remove the python mode bits from gl_enums.py.

emacs whines at me every time I open the file about these unsafe variables, and the file was reformatted from 8 space to 4 space long ago. --- src/mapi/glapi/gen/gl_enums.py | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mapi/glapi/gen/gl_enums.py b/src/mapi/glapi/gen/gl_enums.py index

[Mesa-dev] [PATCH 06/12] mesa: Drop apparently typoed GL_ALL_CLIENT_ATTRIB_BITS.

GL_ALL_ATTRIB_BITS is a thing, and GL_CLIENT_ALL_ATTRIB_BITS, but I don't see GL_ALL_CLIENT_ATTRIB_BITS in my grepping of khronos XML, GL extension specs, GL 1.1, GL 2.2, and GL 4.4. --- src/mapi/glapi/gen/gl_API.xml| 1 - src/mesa/main/tests/enum_strings.cpp | 4 +--- 2 files changed, 1

[Mesa-dev] [PATCH 02/12] mesa: Add a copy of the Khronos gl.xml (SVN #31705).

The intention here is to keep a pristine copy of the upstream gl.xml that can be updated at any time with a new version, and use that to generate Mesa code from instead of our private XML. --- Contents trimmed, because it's 2.5MB. You can find the whole branch at:

[Mesa-dev] [PATCH] i965: Don't mark dead instructions' sources live.

Removes dead code from glsl-mat-from-int-ctor-03.shader_test. Reported-by: Juan A. Suarez Romero --- src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 4 src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp | 4 2 files changed, 8 insertions(+)

Re: [Mesa-dev] [RFC 1/5] nir: Separate texture from sampler in nir_tex_instr

On Wed, Nov 25, 2015 at 3:57 PM, Kenneth Graunke wrote: > On Tuesday, November 03, 2015 01:26:00 PM Jason Ekstrand wrote: >> This commit adds the capability to NIR to support separate textures and >> samplers. As it currently stands, glsl_to_nir only sets the sampler and

Re: [Mesa-dev] [PATCH 12/12] mesa: Drop the blacklisting of new GL enums.

On Wed, Nov 25, 2015 at 10:10 PM, Eric Anholt wrote: > index bff425a..4c89849 100644 > --- a/src/mesa/main/tests/enum_strings.cpp > +++ b/src/mesa/main/tests/enum_strings.cpp > @@ -71,7 +71,7 @@ const struct enum_info everything[] = { > * see go farther. Disabled for the

Re: [Mesa-dev] [RFC 3/5] i965/fs: Plumb separate surfaces and samplers through from NIR

On Wed, Nov 25, 2015 at 4:13 PM, Kenneth Graunke wrote: > On Tuesday, November 03, 2015 01:26:02 PM Jason Ekstrand wrote: >> --- >> src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 2 +- >> src/mesa/drivers/dri/i965/brw_fs.cpp| 47 >>

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

https://bugs.freedesktop.org/show_bug.cgi?id=93103 --- Comment #4 from Michel Dänzer --- Also note that as of version 3.6, LLVM uses versioned symbols, which may help for this issue. -- You are receiving this mail because: You are the QA Contact for the bug. You are the

Re: [Mesa-dev] [PATCH v2 4/8] mesa: return the correct value for GroupStackDepth

On 26 November 2015 at 00:57, Ilia Mirkin wrote: > On Wed, Nov 25, 2015 at 7:36 PM, Emil Velikov > wrote: >> We already have one group (the default) as specif iced in the spec. So > > what's a "specif iced"? is that like iced tea? > The very same

[Mesa-dev] [PATCH 04/12] mesa: Fix a typo in AMD_performance_monitor enum.

--- src/mapi/glapi/gen/AMD_performance_monitor.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mapi/glapi/gen/AMD_performance_monitor.xml b/src/mapi/glapi/gen/AMD_performance_monitor.xml index 41b5208..b29dc5d 100644 ---

[Mesa-dev] [PATCH 03/12] mesa: Fix enum definition of CULL_VERTEX_EYE/OBJECT_POSITION

In converting to using the Khronos XML, I found that our XML had these two swapped, and the text spec agreed. --- src/mapi/glapi/gen/gl_API.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index

Re: [Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

On Wed, Nov 25, 2015 at 4:15 AM, Juan A. Suarez Romero wrote: > When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk, > in a separate file. > > But as fs_visitor::optimize() and vec4_visitor::run() are called more > than once, it ends up overwriting the

Re: [Mesa-dev] [Mesa-stable] [PATCH] swrast: Fix the coordinates passed to _mesa_regions_overlap()

On Wed, Nov 25, 2015 at 10:22 AM, Ian Romanick wrote: > Is this related to a bugzilla or a failing test case? If not, could we > get it piglit for it? > > Either way, looking at _mesa_regions_overlap (which could use a comment > saying that the rectangles are inclusive), I

Re: [Mesa-dev] [PATCH 1/2] i965: Fix fragment shader struct inputs.

On Tue, Nov 24, 2015 at 10:35 PM, Kenneth Graunke wrote: > Apparently we have literally no support for FS varying struct inputs. > This is somewhat surprising, given that we've had tests for that very > feature that have been passing for a long time. > > Normally, varying

Re: [Mesa-dev] [PATCH v2 27/42] i965/fs: Handle nir shared variable load intrinsic

Jordan Justen writes: > Signed-off-by: Jordan Justen > --- > src/mesa/drivers/dri/i965/brw_defines.h | 2 ++ > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 33 > > 2 files changed, 35 insertions(+) > > diff

Re: [Mesa-dev] [Mesa-announce] Mesa 11.1.0 release candidate 1

On 25 November 2015 at 17:07, Mark Janes wrote: > Hi Emil, > > I noticed that this branchpoint is after the KHR_DEBUG patches which > broke GL conformance. > > Is the plan to resolve this bug before release? > Indeed it is. I'm not sure if I'll get everything ironed out

Re: [Mesa-dev] [Mesa-stable] [PATCH] swrast: Fix the coordinates passed to _mesa_regions_overlap()

Is this related to a bugzilla or a failing test case? If not, could we get it piglit for it? Either way, looking at _mesa_regions_overlap (which could use a comment saying that the rectangles are inclusive), I believe this is correct. Reviewed-by: Ian Romanick On

Re: [Mesa-dev] [PATCH 2/2] i965: Fix scalar vertex shader struct outputs.

On Tue, Nov 24, 2015 at 10:35 PM, Kenneth Graunke wrote: > While we correctly set output[] for composite varyings, we set completely > bogus values for output_components[], making emit_urb_writes() output > zeros instead of the actual values. > > Unfortunately, our simple

Re: [Mesa-dev] [PATCH v2] mesa: remove ARB_geometry_shader4

At first I thought it was a mistake to remove things from enum_strings.cpp, but it looks like the ARB/EXT extensions actually had different enum values than core GL 3.2 for the same things. I've looked over all of this with some care and it looks right. Will need a bunch of changes to support

Re: [Mesa-dev] [PATCH 2/5] i965/gen8+: Don't upload the MCS buffer for single-sampled textures

On Wed, Nov 25, 2015 at 06:36:36PM +0100, Neil Roberts wrote: > For single-sampled textures the MCS buffer is only used to implement > fast clears. However the surface always needs to be resolved before > being used as a texture anyway so the the MCS buffer doesn't actually > achieve anything.

[Mesa-dev] [PATCH 3/3] i965/gen9+: Switch thread scratch space to non-coherent stateless access.

The thread scratch space is thread-local so using the full IA-coherent stateless surface index (255 since Gen8) is unnecessary and potentially expensive. On Gen8 and early steppings of Gen9 this is not a functional change because the kernel already sets bit 4 of HDC_CHICKEN0 which overrides all

[Mesa-dev] [PATCH 2/3] i965/fs: Don't use Gen7-style scratch block reads on Gen9+.

Unfortunately Gen7 scratch block reads and writes seem to be hardwired to BTI 255 even on Gen9+ where that index causes the dataport to do an IA-coherent read or write. This change is required for the next patch to be correct, since otherwise we would be writing to the scratch space using

[Mesa-dev] [PATCH 1/3] i965: Add symbolic defines for some magic dataport surface indices.

--- src/mesa/drivers/dri/i965/brw_defines.h | 13 + 1 file changed, 13 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index ade3ede..a511d5c 100644 --- a/src/mesa/drivers/dri/i965/brw_defines.h +++

Re: [Mesa-dev] [PATCH] travis: Initial import of travis instructions.

Jose Fonseca writes: > On 24/11/15 21:38, Rob Clark wrote: >> On Tue, Nov 24, 2015 at 4:10 PM, Eric Anholt wrote: >>> Rob Clark writes: >>> On Tue, Nov 24, 2015 at 2:10 PM, Ilia Mirkin wrote: > On Tue,

Re: [Mesa-dev] [PATCH v2 21/42] glsl: Add default matrix ordering in lower_buffer_access

On 2015-11-25 01:32:37, Iago Toral wrote: > > On Tue, 2015-11-17 at 21:54 -0800, Jordan Justen wrote: > > For compute shader shared variable we will set a default of column > > major. > > > > Signed-off-by: Jordan Justen > > --- > > src/glsl/lower_buffer_access.cpp |

Re: [Mesa-dev] [PATCH v3 11/42] i965: Implement L3 state atom.

On Wed, Nov 25, 2015 at 6:26 AM, Francisco Jerez wrote: > The L3 state atom calculates the target L3 partition weights when the > program bound to some shader stage is modified, and in case they are > far enough from the current partitioning it makes sure that the L3 >

[Mesa-dev] [PATCH 0/5] i965/gen9: Support fast clear on SRGB buffers

Currently fast clears are disabled on SKL with SRGB buffers because they are not marked as losslessly compressible in the formats table. This is less than ideal because by default the window system buffers are created as SRGB so in practice it means an application is unlikely to end up using fast

[Mesa-dev] [PATCH 3/5] i965/gen9: Resolve SRGB color buffers when GL_FRAMEBUFFER_SRGB enabled

SKL can't cope with the CCS buffer for SRGB buffers. Normally the hardware won't see the SRGB formats because when GL_FRAMEBUFFER_SRGB is disabled these get mapped to their linear equivalents. In order to avoid relying on the CCS buffer when it is enabled this patch now makes it flush the

Re: [Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

On Wed, Nov 25, 2015 at 10:52 AM, Matt Turner wrote: > On Wed, Nov 25, 2015 at 10:46 AM, Jason Ekstrand wrote: >> On Wed, Nov 25, 2015 at 10:45 AM, Matt Turner wrote: >>> On Wed, Nov 25, 2015 at 10:37 AM, Jason Ekstrand

Re: [Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

On Wed, Nov 25, 2015 at 4:25 AM, Juan A. Suarez Romero wrote: > On Wed, 2015-11-25 at 13:15 +0100, Juan A. Suarez Romero wrote: >> When using INTEL_DEBUG=optimizer, each optimizing step is dump to >> disk, >> in a separate file. >> >> But as fs_visitor::optimize() and

Re: [Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

On Wed, Nov 25, 2015 at 10:49 AM, Kenneth Graunke wrote: > On Wednesday, November 25, 2015 10:31:24 AM Matt Turner wrote: >> On Wed, Nov 25, 2015 at 4:15 AM, Juan A. Suarez Romero >> wrote: >> > When using INTEL_DEBUG=optimizer, each optimizing step is

Re: [Mesa-dev] [PATCH v2] mesa: remove ARB_geometry_shader4

On Wednesday, November 25, 2015 12:16:02 PM Marta Lofstedt wrote: > From: Marta Lofstedt > > No drivers currently implement ARB_geometry_shader4, nor are there > any plans to implement it. We only support the version of geometry > shaders that was incorporated into

Re: [Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

On Wed, Nov 25, 2015 at 11:05 AM, Jason Ekstrand wrote: > On Wed, Nov 25, 2015 at 10:52 AM, Matt Turner wrote: >> On Wed, Nov 25, 2015 at 10:46 AM, Jason Ekstrand >> wrote: >>> On Wed, Nov 25, 2015 at 10:45 AM, Matt Turner

[Mesa-dev] [PATCH] mesa/program: remove empty function declaration

From: Emil Velikov Unused since 5e9aa9926b9 (2011) - _mesa_ir_compile_shader 69e07bdeb42 (2009) - _mesa_get_program_register Cc: Kenneth Graunke Cc: Brian Paul Signed-off-by: Emil Velikov ---

Re: [Mesa-dev] [PATCH 3/3] i965/gen9+: Switch thread scratch space to non-coherent stateless access.

On Wed, Nov 25, 2015 at 11:37 AM, Francisco Jerez wrote: > The thread scratch space is thread-local so using the full IA-coherent > stateless surface index (255 since Gen8) is unnecessary and > potentially expensive. On Gen8 and early steppings of Gen9 this is > not a

[Mesa-dev] [PATCH v2 10/11] gallium: do not wrap header inclusion in

From: Emil Velikov Add one missing extern C guard within include/pipe/p_video_enums.h, and remove the wrapping throughout gallium. On Haiku one could even use the gallium debug_printf() although that's another topic. v2: Leave dbghelp.h as is (Jose) Cc: Jose

Re: [Mesa-dev] [PATCH 8/9] nir: move to compiler

On Wed, Nov 25, 2015 at 1:32 PM, Emil Velikov wrote: > From: Emil Velikov > > Signed-off-by: Emil Velikov > --- > Android.mk | 1 + > configure.ac

Re: [Mesa-dev] [PATCH v2 22/42] glsl: Don't lower_variable_index_to_cond_assign for shared variables

On 2015-11-25 00:12:15, Iago Toral wrote: > On Tue, 2015-11-17 at 21:54 -0800, Jordan Justen wrote: > > Signed-off-by: Jordan Justen > > --- > > src/glsl/lower_variable_index_to_cond_assign.cpp | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git

Re: [Mesa-dev] [PATCH v2 5.5/42] i965: Add slice count to the brw_device_info structure.

The most important feedback I have on the patch is that we continue to add stuff like this for compute when there is a libdrm interface which exposes all or most of it - and that interface should either be expanded or removed. FWIW, I wasn't a big fan of the interface when it was introduced, but

Re: [Mesa-dev] [PATCH 2/9] nir: remove recursive inclusion in builtin_type_macros.h

On Wed, Nov 25, 2015 at 1:31 PM, Emil Velikov wrote: > From: Emil Velikov > > The header is already included by glsl_types.{cpp,h}. > > Signed-off-by: Emil Velikov > --- > src/glsl/nir/builtin_type_macros.h | 2

Re: [Mesa-dev] [PATCH] mesa/program: remove empty function declaration

On Wed, Nov 25, 2015 at 12:17 PM, Emil Velikov wrote: > From: Emil Velikov > > Unused since > > 5e9aa9926b9 (2011) - _mesa_ir_compile_shader > 69e07bdeb42 (2009) - _mesa_get_program_register I was confused because this second commit didn't

  1   2   3   >