Re: [Mesa-dev] [PATCH 10/13] glsl: Add a lowering pass for gl_VertexID
If you define enums in a struct or class, it then works like a
namespace. E.g. the proper form to use such an enum would be:
ctx->Const.VertexID = gl_constants::gl_VertexID_native;
Marek
On Sat, Jun 21, 2014 at 3:01 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> Converts gl_VertexID to (gl_VertexIDMESA + gl_BaseVertex). gl_VertexIDMESA
> is backed by SYSTEM_VALUE_VERTEX_ID_ZERO_BASE, and gl_BaseVertex is backed
> by a built-in uniform from {STATE_INTERNAL, STATE_BASE_VERTEX}.
>
> NOTE: The enum has to be declared outside the struct or C++ just cannot
> find the values. I tried many variations of scope resolution in
> linker.cpp, but could not make it do-the-right-thing.
>
> Signed-off-by: Ian Romanick
> Cc: "10.2"
> ---
> src/glsl/Makefile.sources| 1 +
> src/glsl/ir_optimization.h | 2 +
> src/glsl/linker.cpp | 7 ++
> src/glsl/lower_vertex_id.cpp | 152
> +++
> src/mesa/main/context.c | 5 ++
> src/mesa/main/mtypes.h | 14
> 6 files changed, 181 insertions(+)
> create mode 100644 src/glsl/lower_vertex_id.cpp
>
> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
> index b54eae7..b884d66 100644
> --- a/src/glsl/Makefile.sources
> +++ b/src/glsl/Makefile.sources
> @@ -77,6 +77,7 @@ LIBGLSL_FILES = \
> $(GLSL_SRCDIR)/lower_vec_index_to_swizzle.cpp \
> $(GLSL_SRCDIR)/lower_vector.cpp \
> $(GLSL_SRCDIR)/lower_vector_insert.cpp \
> + $(GLSL_SRCDIR)/lower_vertex_id.cpp \
> $(GLSL_SRCDIR)/lower_output_reads.cpp \
> $(GLSL_SRCDIR)/lower_ubo_reference.cpp \
> $(GLSL_SRCDIR)/opt_algebraic.cpp \
> diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
> index b83c225..2892dc2 100644
> --- a/src/glsl/ir_optimization.h
> +++ b/src/glsl/ir_optimization.h
> @@ -125,6 +125,8 @@ bool optimize_redundant_jumps(exec_list *instructions);
> bool optimize_split_arrays(exec_list *instructions, bool linked);
> bool lower_offset_arrays(exec_list *instructions);
>
> +bool lower_vertex_id(gl_shader *shader);
> +
> ir_rvalue *
> compare_index_block(exec_list *instructions, ir_variable *index,
> unsigned base, unsigned components, void *mem_ctx);
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index 813108c..2e9a0b6 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -1623,6 +1623,13 @@ link_intrastage_shaders(void *mem_ctx,
>}
> }
>
> + if (ctx->Const.VertexID != gl_VertexID_native) {
> + /* FINISHME: The other lowering method is not yet implemented.
> + */
> + assert(ctx->Const.VertexID == gl_VertexID_using_uniform_gl_BaseVertex);
> + lower_vertex_id(linked);
> + }
> +
> /* Make a pass over all variable declarations to ensure that arrays with
> * unspecified sizes have a size specified. The size is inferred from the
> * max_array_access field.
> diff --git a/src/glsl/lower_vertex_id.cpp b/src/glsl/lower_vertex_id.cpp
> new file mode 100644
> index 000..c9cced1
> --- /dev/null
> +++ b/src/glsl/lower_vertex_id.cpp
> @@ -0,0 +1,152 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +/**
> + * \file lower_vertex_id.cpp
> + *
> + * There exists hardware, such as i965, that does not implement the OpenGL
> + * semantic for gl_VertexID. Instead, that hardware does not include the
> + * value of basevertex in the gl_VertexID value. To implement the OpenGL
> + * semantic, we'll have to convert gl_Vertex_ID to
> + * gl_VertexIDMESA+gl_BaseVertexMESA.
> + */
> +
> +#include "glsl_symbol_table.h"
> +#include "ir_hierarchical_visitor.h"
> +#include "ir.h"
> +#include "ir_builder.h"
> +#include "linker.h"
> +#include "program/prog_statevars.h"
> +
> +namespace {
> +
> +class lower_vertex_id_visitor : public ir_
Re: [Mesa-dev] [PATCH] glsl: Silence many unused parameter warnings
Reviewed-by: Tapani Pälli
On 06/21/2014 03:44 AM, Ian Romanick wrote:
From: Ian Romanick
In file included from ../../src/glsl/builtin_functions.cpp:61:0:
../../src/glsl/glsl_parser_extras.h:154:9: warning: unused parameter 'var'
[-Wunused-parameter]
Signed-off-by: Ian Romanick
Cc: Tapani Pälli
---
src/glsl/glsl_parser_extras.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index a59090f..f76ba89 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -152,7 +152,7 @@ struct _mesa_glsl_parse_state {
}
bool check_explicit_uniform_location_allowed(YYLTYPE *locp,
-const ir_variable *var)
+const ir_variable *)
{
if (!this->has_explicit_attrib_location() ||
!this->ARB_explicit_uniform_location_enable) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore
Your v3 branch seems to work flawlessly. Autogen, make, and make install works as it used to. If anything, I think I might be seeing decreased compile-time. That might just be my imagination though. Rebooted and everything seems to be in good order. Let me know if you want me to do any more tests or benchmarks. Tested-by: Thomas Helland 2014-06-21 16:19 GMT+02:00 Emil Velikov : > On 21/06/14 01:30, Thomas Helland wrote: > > Hi again, > > > > Autogen seems to work flawlessly with the updated branch. > > Everything builds and compiles as normal on my Ivy Bridge setup. > > When trying to do a make install though, something fails. > > I'm not sure if it's related to your changes, but at least master gets > > further into the process before failing due to LLVM incompatibility > > when trying to install libxatracker > > > I'm not sure what llvm has to do with libxatracker. I'm suspecting that > 564821c917f will help on that regard. > > > make[3]: Entering directory > '/home/helland/Mesa/src/gallium/targets/vdpau' > > CXXLDlibvdpau_gallium.la > > .libs/libvdpau_gallium_la-target.o: In function > `pipe_r600_create_screen': > > > /home/helland/Mesa/src/gallium/targets/vdpau/../../../../src/gallium/auxiliary/target-helpers/inline_drm_helper.h:178: > > undefined reference to `radeon_drm_winsys_create' > > collect2: error: ld returned 1 exit status > > Makefile:729: recipe for target 'libvdpau_gallium.la' failed > > make[3]: *** [libvdpau_gallium.la] Error 1 > > make[3]: Leaving directory '/home/helland/Mesa/src/gallium/targets/vdpau' > > Makefile:524: recipe for target 'install-recursive' failed > > make[2]: *** [install-recursive] Error 1 > > make[2]: Leaving directory '/home/helland/Mesa/src/gallium/targets' > > Makefile:530: recipe for target 'install-recursive' failed > > make[1]: *** [install-recursive] Error 1 > > make[1]: Leaving directory '/home/helland/Mesa/src' > > Makefile:579: recipe for target 'install-recursive' failed > > make: *** [install-recursive] Error 1 > > > As soon as I saw this I realised what Christian meant while going through > the > radeon patches. Cheers for that. > > The updated series (and rebased on top of master) can be found at branch > static-or-shared-pipe-drivers-v3 in the usual place. > > Thanks again > Emil > > > I might just be doing something wrong here though. > > I'm not really that familiar with build-systems yet. > > (I'm spoiled with having started my programming career in java) > > > > Cheers, > > Thomas > > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/11] [RFC v2] Solve the mapping bug
Bruno Jimenez writes:
> On Sat, 2014-06-21 at 17:39 +0200, Francisco Jerez wrote:
>[...]
>> The implementation of PIPE_TRANSFER_MAP_DIRECTLY introduced in PATCH 10
>> has somewhat worrying semantics: A mapping with this flag might become
>> stale unpredictably if a kernel is run, maybe from a different command
>> queue. Clover's transfer functions don't hit that path right now on
>> single-threaded applications, but they might in the future as we start
>> accelerating the APIs we currently implement with soft_copy_op(). This
>> is a bug IMHO: even direct mappings should last until the corresponding
>> unmap call.
>
> I think I'm not fully understanding you here. I tried to use
> PIPE_TRANSFER_MAP_DIRECTLY only with clEnqueue{Write,Read} functions,
> which map the resource, copy it and unmap it when finished. Is it
> possible for another kernel to access the memory of a buffer that is
> being read/written?
>
AFAICT, yes. All command queues created on the same device share the
same memory pool, so a kernel being queued for execution in one could
invalidate a concurrent mapping done with PIPE_TRANSFER_MAP_DIRECTLY by
one of the transfer functions. On top of that the transfer functions
might start queuing kernels themselves in the future to accelerate
certain operations we currently do on the CPU, which would make this
scenario more likely.
> I had no intention of having user mappings made with that flag.
> [Although a possible solution, with a lot of warnings of course, for the
> avobe problem could be to allow a user to use this flag]
>
>> I'm not advocating a revert of the series because it fixes a serious
>> bug, but please don't push patches 10-11, we should probably start
>> looking for a different solution. Some suggestions are:
>
> I also asked for them to not to be pushed. And with your reasons, until
> we find a better way or we change how buffers are handled, I won't
> propose them again.
>
>> - Why do you even need a pool? Wouldn't it be possible to create a
>>huge RAT, e.g. covering a 4GB portion of the GPU memory and then use
>>a special memory domain or some sort of flag to tell the kernel to
>>allocate a buffer from that region (or relocate if it's already been
>>allocated elsewhere)? This is especially easy on hardware with
>>virtual memory, as you could simply reserve an arbitrarily large
>>block of virtual memory, bind it as e.g. RAT0, and then map other
>>buffer objects into the block on-demand as they're bound to the
>>compute pipeline -- There would be no need to move the actual bits
>>around. This is similar to the approach I used in my original
>>proof-of-concept implementation of the compute API on nv50.
>
> This is one of the things I have been wondering recently, given that
> radeonsi doesn't use a pool, why r600 needs one? I still have to
> understand AMD docs and how *exactly* everything works.
>
Probably because on SI compute kernels can access random locations of
memory without going through an RAT? I have little actual experience
with radeons, Tom should know the low-level details.
> 4GB seems like a big amount of memory for me, my little cedar has only
> 512MB :)
>
>> - If you insist on using a pool, you could (mostly) avoid the storage
>>duplication and the mapping copies by allocating buffer objects
>>directly from the pool as it was before this series, and then keep
>>some sort of reference count specific to the pool storage that would
>>be incremented on map and decremented on unmap. Once you need to
>>grow the pool you'd keep the old storage around temporarily and
>>migrate buffers to the new storage lazily as they are required or
>>unmapped. Once the reference count drops to zero you'd be free to
>>release the backing BO to the system. The fact that you'd keep both
>>storage buffers around for a bit means that you'd be able to use DMA
>>to migrate the pool contents instead of the CPU copies you're doing
>>now, which is likely to be substantially more efficient.
>
> I see how this would solve the slow mappings problem, but I think that
> it could mean a higher memory usage. In the case of a user creating some
> buffers, mapping one of them and them adding more so that the pool has
> to grow, we would have to keep the full size of the old pool just for a
> buffer, plus the new pool.
>
That's a fair point, this solution would only get rid of the extra
copying but it wouldn't solve memory usage problem in some situations
(long-lived mappings). IMHO the former is more worrying because it has
an impact on every map operation no matter what, while the increased
memory usage will only have an impact in situations of heavy memory
pressure -- And even in those cases the kernel might be able to avoid an
OOM situation by evicting the old pool storage from graphics memory
(which, I must admit, might be rather punishing too), as we can be sure
that there will be no further reference
[Mesa-dev] [PATCH 1/4] mesa/st: handle gl_Layer input semantic
Signed-off-by: Ilia Mirkin --- src/mesa/state_tracker/st_program.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/mesa/state_tracker/st_program.c b/src/mesa/state_tracker/st_program.c index 26eb978..1df411c 100644 --- a/src/mesa/state_tracker/st_program.c +++ b/src/mesa/state_tracker/st_program.c @@ -572,6 +572,11 @@ st_translate_fragment_program(struct st_context *st, input_semantic_index[slot] = 0; interpMode[slot] = TGSI_INTERPOLATE_CONSTANT; break; + case VARYING_SLOT_LAYER: +input_semantic_name[slot] = TGSI_SEMANTIC_LAYER; +input_semantic_index[slot] = 0; +interpMode[slot] = TGSI_INTERPOLATE_CONSTANT; +break; case VARYING_SLOT_VIEWPORT: input_semantic_name[slot] = TGSI_SEMANTIC_VIEWPORT_INDEX; input_semantic_index[slot] = 0; -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] nv50: enable ARB_fragment_layer_viewport
Signed-off-by: Ilia Mirkin --- docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..c47a54b 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..5e29f2d 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. GL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe GL_ARB_texture_query_lod on radeonsi GL_ARB_viewport_array on nvc0 +GL_ARB_fragment_layer_viewport on nv50 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 68becec..8b8a72a 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c @@ -167,6 +167,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_USER_VERTEX_BUFFERS: case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 1; case PIPE_CAP_SEAMLESS_CUBE_MAP: return 1; /* class_3d >= NVA0_3D_CLASS; */ @@ -197,7 +198,6 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: case PIPE_CAP_COMPUTE: - case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; } -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] gallium: add cap to show that fs can accept layer/viewport inputs
Signed-off-by: Ilia Mirkin --- src/gallium/docs/source/screen.rst | 2 ++ src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 3 ++- src/mesa/state_tracker/st_extensions.c | 1 + 15 files changed, 17 insertions(+), 1 deletion(-) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 1a80b04..ebebfe8 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -205,6 +205,8 @@ The integer capabilities: * ``PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION``: Whether TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION is supported, which disables clipping and viewport transformation. +* ``PIPE_CAP_TGSI_FS_LAYER_VIEWPORT``: Whether the fragment shader can accept + ``TGSI_SEMANTIC_LAYER`` and ``TGSI_SEMANTIC_VIEWPORT_INDEX`` inputs. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index e7a185d..fa201ce 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -215,6 +215,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_SAMPLE_SHADING: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 79d8659..b776c49 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -223,6 +223,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_SAMPLE_SHADING: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index b08ae20..4b1fe35 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -442,6 +442,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_SAMPLE_SHADING: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; default: diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index a6b712a..3ccbcd3 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -244,6 +244,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_SAMPLE_SHADING: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; case PIPE_CAP_FAKE_SW_MSAA: return 1; diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index 5c3d783..db4755b 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c @@ -146,6 +146,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: case PIPE_CAP_USER_VERTEX_BUFFERS: case PIPE_CAP_COMPUTE: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; } diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index c09a8c6..68becec 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c @@ -197,6 +197,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION: case PIPE_CAP_COMPUTE: + case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT: return 0; } diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 52a067e..2c8f1ca 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -181,6 +181,7 @@ nvc0_screen_get_param(struc
[Mesa-dev] [PATCH 4/4] nvc0: enable ARB_fragment_layer_viewport
Signed-off-by: Ilia Mirkin
---
docs/GL3.txt| 2 +-
docs/relnotes/10.3.html | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index c47a54b..8cfa247 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -161,7 +161,7 @@ GL 4.3:
GL_ARB_copy_imagenot started
GL_KHR_debug DONE (all drivers)
GL_ARB_explicit_uniform_location DONE (all drivers that
support GLSL)
- GL_ARB_fragment_layer_viewport DONE (nv50)
+ GL_ARB_fragment_layer_viewport DONE (nv50, nvc0)
GL_ARB_framebuffer_no_attachmentsnot started
GL_ARB_internalformat_query2 not started
GL_ARB_invalidate_subdataDONE (all drivers)
diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html
index 5e29f2d..b65e347 100644
--- a/docs/relnotes/10.3.html
+++ b/docs/relnotes/10.3.html
@@ -53,7 +53,7 @@ Note: some of the new features are only available with
certain drivers.
GL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi,
softpipe
GL_ARB_texture_query_lod on radeonsi
GL_ARB_viewport_array on nvc0
-GL_ARB_fragment_layer_viewport on nv50
+GL_ARB_fragment_layer_viewport on nv50, nvc0
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index 667fbc8..ad8d1b0 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
@@ -36,6 +36,8 @@ nvc0_shader_input_address(unsigned sn, unsigned si, unsigned
ubase)
switch (sn) {
case NV50_SEMANTIC_TESSFACTOR: return 0x000 + si * 0x4;
case TGSI_SEMANTIC_PRIMID: return 0x060;
+ case TGSI_SEMANTIC_LAYER:return 0x064;
+ case TGSI_SEMANTIC_VIEWPORT_INDEX:return 0x068;
case TGSI_SEMANTIC_PSIZE:return 0x06c;
case TGSI_SEMANTIC_POSITION: return 0x070;
case TGSI_SEMANTIC_GENERIC: return ubase + si * 0x10;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 2c8f1ca..c02e10a 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -164,6 +164,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_SAMPLE_SHADING:
case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
case PIPE_CAP_TEXTURE_GATHER_SM5:
+ case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT:
return 1;
case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
@@ -181,7 +182,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_TGSI_VS_LAYER:
case PIPE_CAP_FAKE_SW_MSAA:
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
- case PIPE_CAP_TGSI_FS_LAYER_VIEWPORT:
return 0;
}
--
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 1/4] glxinfo: Print XFB, TBO, and UBO limits
Fredrik, What happened to this series? -ilia On Thu, Apr 10, 2014 at 10:09 AM, Brian Paul wrote: > On 04/09/2014 07:51 PM, Fredrik Höglund wrote: >> >> --- >> src/xdemos/glxinfo.c | 22 ++ >> 1 file changed, 22 insertions(+) >> > > For the series: > Reviewed-by: Brian Paul > > > ___ > 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 1/4] mesa/st: handle gl_Layer input semantic
Patch 1 & 2: Reviewed-by: Marek Olšák Marek On Sun, Jun 22, 2014 at 5:10 PM, Ilia Mirkin wrote: > Signed-off-by: Ilia Mirkin > --- > src/mesa/state_tracker/st_program.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/src/mesa/state_tracker/st_program.c > b/src/mesa/state_tracker/st_program.c > index 26eb978..1df411c 100644 > --- a/src/mesa/state_tracker/st_program.c > +++ b/src/mesa/state_tracker/st_program.c > @@ -572,6 +572,11 @@ st_translate_fragment_program(struct st_context *st, > input_semantic_index[slot] = 0; > interpMode[slot] = TGSI_INTERPOLATE_CONSTANT; > break; > + case VARYING_SLOT_LAYER: > +input_semantic_name[slot] = TGSI_SEMANTIC_LAYER; > +input_semantic_index[slot] = 0; > +interpMode[slot] = TGSI_INTERPOLATE_CONSTANT; > +break; > case VARYING_SLOT_VIEWPORT: > input_semantic_name[slot] = TGSI_SEMANTIC_VIEWPORT_INDEX; > input_semantic_index[slot] = 0; > -- > 1.8.5.5 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Beignet Mesa EGL extension
I was looking at getting Beignet compiling against current mesa working
again a few weeks ago. Really there needs to be some coordination with
the Mesa devs to provide a suitable API since what was being used has
been since removed. To that end; I've cc'd mesa-dev, hopefully there can
be progress made.
As to my own efforts; unfortunately, after making some progress, I
accidentally lost my patches(!), but since I spent a while reading the
code, I'm sure the below commit which has attempted to at least get it
working with 10.1 is only partially right. See inline.
> commit c2d2853c55d7ab12e422301d1c359b4f736b87d8
> Author: Abrahm Scully
> Date: Wed Jun 18 22:28:08 2014 -0400
>
> Fix build with mesa 10.1.
>
> Mesa renamed some constants and a directory.
>
> Signed-off-by: Abrahm Scully
> Reviewed-by: Zhigang Gong
>
> diff --git a/CMake/FindMesaSrc.cmake b/CMake/FindMesaSrc.cmake
> index c1d4fc6..978cb4e 100644
> --- a/CMake/FindMesaSrc.cmake
> +++ b/CMake/FindMesaSrc.cmake
> @@ -18,7 +18,7 @@ SET(MESA_SOURCE_INCLUDES ${MESA_SOURCE_PREFIX}/src/mesa
> ${MESA_SOURCE_PREFIX}/include
> ${MESA_SOURCE_PREFIX}/src/mapi
> ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/i965/
> - ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/intel/
> + ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/i915/
The i915 is the "other" intel driver, it's *wrong* to include the
headers even though they happen to provide the missing definitions which
were in the headers present in the common "intel" directory. If they're
still valid for i965 it would be better to define them in the beignet
source until upsteam Mesa provides an API for beignet to use.
> ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/common/)
> SET(MESA_SOURCE_FOUND 1 CACHE STRING "Set to 1 if mesa source code is found,
> 0 otherwise")
> ELSE(MESA_SOURCE_PREFIX)
> diff --git a/src/intel/intel_dri_resource_sharing.c
> b/src/intel/intel_dri_resource_sharing.c
> index b31844e..188c1fa 100644
> --- a/src/intel/intel_dri_resource_sharing.c
> +++ b/src/intel/intel_dri_resource_sharing.c
> @@ -119,12 +119,12 @@ intel_get_gl_obj_from_texture(void *driver,
> }
>
> static GLenum
> -get_cl_gl_format(gl_format format)
> +get_cl_gl_format(mesa_format format)
> {
> switch (format) {
> - case MESA_FORMAT_RGBA:
> + case MESA_FORMAT_R8G8B8A8_UNORM:
>return GL_RGBA;
> - case MESA_FORMAT_ARGB:
> + case MESA_FORMAT_A8R8G8B8_UNORM:
>return GL_BGRA;
> default:
>return GL_BGRA;
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore
On 22/06/14 14:38, Thomas Helland wrote: > Your v3 branch seems to work flawlessly. > Autogen, make, and make install works as it used to. > If anything, I think I might be seeing decreased compile-time. > That might just be my imagination though. > Rebooted and everything seems to be in good order. > Let me know if you want me to do any more tests or benchmarks. > > Tested-by: Thomas Helland > Great news. Testing - pretty much anything you do on a daily basis. None of the patches should make _any_ difference. Have you tried vdpau/omx ? Benchmarks - in theory we are a bit slower now. The series adds a few dlopen/dlsym + libudev + strcmp calls, which happen (only once) upon screen creation. The change should be unnoticeable. Unfortunately (?) gallium does not use libdricore, thus the speed benefits of classic megadrivers, would seems unlikely here :\ Feel free to give your favourite game/benchmark a go though :) Thanks, Emil > > 2014-06-21 16:19 GMT+02:00 Emil Velikov : > >> On 21/06/14 01:30, Thomas Helland wrote: >>> Hi again, >>> >>> Autogen seems to work flawlessly with the updated branch. >>> Everything builds and compiles as normal on my Ivy Bridge setup. >>> When trying to do a make install though, something fails. >>> I'm not sure if it's related to your changes, but at least master gets >>> further into the process before failing due to LLVM incompatibility >>> when trying to install libxatracker >>> >> I'm not sure what llvm has to do with libxatracker. I'm suspecting that >> 564821c917f will help on that regard. >> >>> make[3]: Entering directory >> '/home/helland/Mesa/src/gallium/targets/vdpau' >>> CXXLDlibvdpau_gallium.la >>> .libs/libvdpau_gallium_la-target.o: In function >> `pipe_r600_create_screen': >>> >> /home/helland/Mesa/src/gallium/targets/vdpau/../../../../src/gallium/auxiliary/target-helpers/inline_drm_helper.h:178: >>> undefined reference to `radeon_drm_winsys_create' >>> collect2: error: ld returned 1 exit status >>> Makefile:729: recipe for target 'libvdpau_gallium.la' failed >>> make[3]: *** [libvdpau_gallium.la] Error 1 >>> make[3]: Leaving directory '/home/helland/Mesa/src/gallium/targets/vdpau' >>> Makefile:524: recipe for target 'install-recursive' failed >>> make[2]: *** [install-recursive] Error 1 >>> make[2]: Leaving directory '/home/helland/Mesa/src/gallium/targets' >>> Makefile:530: recipe for target 'install-recursive' failed >>> make[1]: *** [install-recursive] Error 1 >>> make[1]: Leaving directory '/home/helland/Mesa/src' >>> Makefile:579: recipe for target 'install-recursive' failed >>> make: *** [install-recursive] Error 1 >>> >> As soon as I saw this I realised what Christian meant while going through >> the >> radeon patches. Cheers for that. >> >> The updated series (and rebased on top of master) can be found at branch >> static-or-shared-pipe-drivers-v3 in the usual place. >> >> Thanks again >> Emil >> >>> I might just be doing something wrong here though. >>> I'm not really that familiar with build-systems yet. >>> (I'm spoiled with having started my programming career in java) >>> >>> Cheers, >>> Thomas >>> >> >> > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: expose ARB_seamless_cubemap_per_texture when supported
All of the bits appear to already be in place to support this in the
sampler (which the original AMD version didn't allow).
Signed-off-by: Ilia Mirkin
---
I'm probably missing some reason why this wasn't already enabled, but sending
this out anyways. Feel free to point out the error in my reasoning :)
src/mesa/main/extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 25e3dab..522f5ad 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -136,6 +136,7 @@ static const struct extension extension_table[] = {
{ "GL_ARB_sample_shading", o(ARB_sample_shading),
GL, 2009 },
{ "GL_ARB_sampler_objects", o(dummy_true),
GL, 2009 },
{ "GL_ARB_seamless_cube_map", o(ARB_seamless_cube_map),
GL, 2009 },
+ { "GL_ARB_seamless_cubemap_per_texture",
o(AMD_seamless_cubemap_per_texture),GL, 2013 },
{ "GL_ARB_separate_shader_objects", o(dummy_true),
GL, 2010 },
{ "GL_ARB_shader_atomic_counters",
o(ARB_shader_atomic_counters), GL, 2011 },
{ "GL_ARB_shader_bit_encoding", o(ARB_shader_bit_encoding),
GL, 2010 },
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Beignet Mesa EGL extension
On 19/06/14 12:25, Steven Newbury wrote:
> I was looking at getting Beignet compiling against current mesa working
> again a few weeks ago. Really there needs to be some coordination with
> the Mesa devs to provide a suitable API since what was being used has
> been since removed. To that end; I've cc'd mesa-dev, hopefully there can
> be progress made.
>
> As to my own efforts; unfortunately, after making some progress, I
> accidentally lost my patches(!), but since I spent a while reading the
> code, I'm sure the below commit which has attempted to at least get it
> working with 10.1 is only partially right. See inline.
>
>
>> commit c2d2853c55d7ab12e422301d1c359b4f736b87d8
>> Author: Abrahm Scully
>> Date: Wed Jun 18 22:28:08 2014 -0400
>>
>> Fix build with mesa 10.1.
>>
>> Mesa renamed some constants and a directory.
>>
>> Signed-off-by: Abrahm Scully
>> Reviewed-by: Zhigang Gong
>>
>> diff --git a/CMake/FindMesaSrc.cmake b/CMake/FindMesaSrc.cmake
>> index c1d4fc6..978cb4e 100644
>> --- a/CMake/FindMesaSrc.cmake
>> +++ b/CMake/FindMesaSrc.cmake
>> @@ -18,7 +18,7 @@ SET(MESA_SOURCE_INCLUDES ${MESA_SOURCE_PREFIX}/src/mesa
>> ${MESA_SOURCE_PREFIX}/include
>> ${MESA_SOURCE_PREFIX}/src/mapi
>> ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/i965/
>> - ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/intel/
>> + ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/i915/
>
> The i915 is the "other" intel driver, it's *wrong* to include the
> headers even though they happen to provide the missing definitions which
> were in the headers present in the common "intel" directory. If they're
> still valid for i965 it would be better to define them in the beignet
> source until upsteam Mesa provides an API for beignet to use.
>
Assuming that by "other intel driver" you mean "the driver not
written/supported by Intel", I believe that you're in a mistake. The i915 is
not the same as i915g. The former is the original and supported classic DRI
driver while the latter is a gallium based one, written by Stephane Marchesin
and resides at src/gallium/drivers/i915.
Hope this clears things a bit.
Emil
>> ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/common/)
>> SET(MESA_SOURCE_FOUND 1 CACHE STRING "Set to 1 if mesa source code is
>> found, 0 otherwise")
>> ELSE(MESA_SOURCE_PREFIX)
>> diff --git a/src/intel/intel_dri_resource_sharing.c
>> b/src/intel/intel_dri_resource_sharing.c
>> index b31844e..188c1fa 100644
>> --- a/src/intel/intel_dri_resource_sharing.c
>> +++ b/src/intel/intel_dri_resource_sharing.c
>> @@ -119,12 +119,12 @@ intel_get_gl_obj_from_texture(void *driver,
>> }
>>
>> static GLenum
>> -get_cl_gl_format(gl_format format)
>> +get_cl_gl_format(mesa_format format)
>> {
>> switch (format) {
>> - case MESA_FORMAT_RGBA:
>> + case MESA_FORMAT_R8G8B8A8_UNORM:
>>return GL_RGBA;
>> - case MESA_FORMAT_ARGB:
>> + case MESA_FORMAT_A8R8G8B8_UNORM:
>>return GL_BGRA;
>> default:
>>return GL_BGRA;
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 54372] GLX_INTEL_swap_event crashes driver when swapping window buffers
https://bugs.freedesktop.org/show_bug.cgi?id=54372 --- Comment #25 from danm...@gmail.com --- Created attachment 101536 --> https://bugs.freedesktop.org/attachment.cgi?id=101536&action=edit patch to fix glxusefont -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 54372] GLX_INTEL_swap_event crashes driver when swapping window buffers
https://bugs.freedesktop.org/show_bug.cgi?id=54372 --- Comment #26 from danm...@gmail.com --- Sent, waiting for moderator approval. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Beignet Mesa EGL extension
On Sunday, June 22, 2014 07:37:20 PM Emil Velikov wrote:
> On 19/06/14 12:25, Steven Newbury wrote:
> > I was looking at getting Beignet compiling against current mesa working
> > again a few weeks ago. Really there needs to be some coordination with
> > the Mesa devs to provide a suitable API since what was being used has
> > been since removed. To that end; I've cc'd mesa-dev, hopefully there can
> > be progress made.
> >
> > As to my own efforts; unfortunately, after making some progress, I
> > accidentally lost my patches(!), but since I spent a while reading the
> > code, I'm sure the below commit which has attempted to at least get it
> > working with 10.1 is only partially right. See inline.
> >
> >
> >> commit c2d2853c55d7ab12e422301d1c359b4f736b87d8
> >> Author: Abrahm Scully
> >> Date: Wed Jun 18 22:28:08 2014 -0400
> >>
> >> Fix build with mesa 10.1.
> >>
> >> Mesa renamed some constants and a directory.
> >>
> >> Signed-off-by: Abrahm Scully
> >> Reviewed-by: Zhigang Gong
> >>
> >> diff --git a/CMake/FindMesaSrc.cmake b/CMake/FindMesaSrc.cmake
> >> index c1d4fc6..978cb4e 100644
> >> --- a/CMake/FindMesaSrc.cmake
> >> +++ b/CMake/FindMesaSrc.cmake
> >> @@ -18,7 +18,7 @@ SET(MESA_SOURCE_INCLUDES ${MESA_SOURCE_PREFIX}/src/mesa
> >> ${MESA_SOURCE_PREFIX}/include
> >> ${MESA_SOURCE_PREFIX}/src/mapi
> >>
${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/i965/
> >> -
${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/intel/
> >> +
${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/i915/
> >
> > The i915 is the "other" intel driver, it's *wrong* to include the
> > headers even though they happen to provide the missing definitions which
> > were in the headers present in the common "intel" directory. If they're
> > still valid for i965 it would be better to define them in the beignet
> > source until upsteam Mesa provides an API for beignet to use.
> >
> Assuming that by "other intel driver" you mean "the driver not
> written/supported by Intel", I believe that you're in a mistake. The i915 is
> not the same as i915g. The former is the original and supported classic DRI
> driver while the latter is a gallium based one, written by Stephane
Marchesin
> and resides at src/gallium/drivers/i915.
>
> Hope this clears things a bit.
> Emil
Well, there's that, but Steven is right: Beignet is only for Gen7+ hardware,
which is entirely i965. Including stuff out of the i915 driver (for Gen2-3
hardware) doesn't make much sense.
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Beignet Mesa EGL extension
On 22/06/14 23:22, Kenneth Graunke wrote:
> On Sunday, June 22, 2014 07:37:20 PM Emil Velikov wrote:
>> On 19/06/14 12:25, Steven Newbury wrote:
>>> I was looking at getting Beignet compiling against current mesa working
>>> again a few weeks ago. Really there needs to be some coordination with
>>> the Mesa devs to provide a suitable API since what was being used has
>>> been since removed. To that end; I've cc'd mesa-dev, hopefully there can
>>> be progress made.
>>>
>>> As to my own efforts; unfortunately, after making some progress, I
>>> accidentally lost my patches(!), but since I spent a while reading the
>>> code, I'm sure the below commit which has attempted to at least get it
>>> working with 10.1 is only partially right. See inline.
>>>
>>>
commit c2d2853c55d7ab12e422301d1c359b4f736b87d8
Author: Abrahm Scully
Date: Wed Jun 18 22:28:08 2014 -0400
Fix build with mesa 10.1.
Mesa renamed some constants and a directory.
Signed-off-by: Abrahm Scully
Reviewed-by: Zhigang Gong
diff --git a/CMake/FindMesaSrc.cmake b/CMake/FindMesaSrc.cmake
index c1d4fc6..978cb4e 100644
--- a/CMake/FindMesaSrc.cmake
+++ b/CMake/FindMesaSrc.cmake
@@ -18,7 +18,7 @@ SET(MESA_SOURCE_INCLUDES ${MESA_SOURCE_PREFIX}/src/mesa
${MESA_SOURCE_PREFIX}/include
${MESA_SOURCE_PREFIX}/src/mapi
> ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/i965/
-
> ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/intel/
+
> ${MESA_SOURCE_PREFIX}/src/mesa/drivers/dri/i915/
>>>
>>> The i915 is the "other" intel driver, it's *wrong* to include the
>>> headers even though they happen to provide the missing definitions which
>>> were in the headers present in the common "intel" directory. If they're
>>> still valid for i965 it would be better to define them in the beignet
>>> source until upsteam Mesa provides an API for beignet to use.
>>>
>> Assuming that by "other intel driver" you mean "the driver not
>> written/supported by Intel", I believe that you're in a mistake. The i915 is
>> not the same as i915g. The former is the original and supported classic DRI
>> driver while the latter is a gallium based one, written by Stephane
> Marchesin
>> and resides at src/gallium/drivers/i915.
>>
>> Hope this clears things a bit.
>> Emil
>
> Well, there's that, but Steven is right: Beignet is only for Gen7+ hardware,
> which is entirely i965. Including stuff out of the i915 driver (for Gen2-3
> hardware) doesn't make much sense.
>
Seems like the wording got me there :\
Thanks for the reminder Ken.
-Emil
> --Ken
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] patch: fix glxusexfont
Author: Daniel Manjarres
Date: Sun Jun 22 09:47:58 2014 -0700
glx: Fix glxUseXFont for glxWindow and glxPixmaps
The current implementation of glxUseXFont requires creating
a temporary pixmap and graphics context, which requires a real
old-school X11 Window, not a glxDrawable. This patch changes
things so that glxUseXFont will also accept a glxWindow or
glxPixmap, and lookup the underlying X11 Drawable. Without
this patch glxUseXFont generates a giant stream of Xerrors
bout bad drawables and bad graphics contexts.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372
diff --git a/src/glx/xfont.c b/src/glx/xfont.c
index 316c585..8735386 100644
--- a/src/glx/xfont.c
+++ b/src/glx/xfont.c
@@ -221,6 +221,7 @@ DRI_glXUseXFont(struct glx_context *CC, Font font, int
first, int count, int lis
XGCValues values;
unsigned long valuemask;
XFontStruct *fs;
+ __GLXDRIdrawable *glxdraw;
GLint swapbytes, lsbfirst, rowlength;
GLint skiprows, skippixels, alignment;
@@ -233,6 +234,10 @@ DRI_glXUseXFont(struct glx_context *CC, Font font, int
first, int count, int lis
dpy = CC->currentDpy;
win = CC->currentDrawable;
+ glxdraw = GetGLXDRIDrawable(CC->currentDpy, CC->currentDrawable);
+ if(glxdraw)
+ win = glxdraw->xDrawable;
+
fs = XQueryFont(dpy, font);
if (!fs) {
__glXSetError(CC, GL_INVALID_VALUE);
>From 2db1da2a1a1413ef6d7b89b873f2a045045f4103 Mon Sep 17 00:00:00 2001
From: Daniel Manjarres
Date: Sun, 22 Jun 2014 09:47:58 -0700
Subject: [PATCH] glx: Fix glxUseXFont for glxWindow and glxPixmaps
The current implementation of glxUseXFont requires creating
a temporary pixmap and graphics context, which requires a real
old-school X11 Window, not a glxDrawable. This patch changes
things so that glxUseXFont will also accept a glxWindow or
glxPixmap, and lookup the underlying X11 Drawable. Without
this patch glxUseXFont generates a giant stream of Xerrors
bout bad drawables and bad graphics contexts.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372
---
src/glx/xfont.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glx/xfont.c b/src/glx/xfont.c
index 316c585..8735386 100644
--- a/src/glx/xfont.c
+++ b/src/glx/xfont.c
@@ -221,6 +221,7 @@ DRI_glXUseXFont(struct glx_context *CC, Font font, int first, int count, int lis
XGCValues values;
unsigned long valuemask;
XFontStruct *fs;
+ __GLXDRIdrawable *glxdraw;
GLint swapbytes, lsbfirst, rowlength;
GLint skiprows, skippixels, alignment;
@@ -233,6 +234,10 @@ DRI_glXUseXFont(struct glx_context *CC, Font font, int first, int count, int lis
dpy = CC->currentDpy;
win = CC->currentDrawable;
+ glxdraw = GetGLXDRIDrawable(CC->currentDpy, CC->currentDrawable);
+ if(glxdraw)
+ win = glxdraw->xDrawable;
+
fs = XQueryFont(dpy, font);
if (!fs) {
__glXSetError(CC, GL_INVALID_VALUE);
--
1.8.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] meta: Use AMD_vertex_shader_layer instead of a GS for layered clears.
On i965, enabling and disabling the GS is not free: you have to do a
full pipeline stall, reconfigure the URB and push constant space, and
emit a bunch of state. Most clears aren't layered, so the GS isn't
needed in the common case. But we turned it on anyway.
As far as I know, most GPUs that support layered rendering can support
the GL_AMD_vertex_shader_layer extension. i965 does, and it's also the
only driver using this path that does layered rendering. Doing so
allows us to skip setting up the GS.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/common/meta.c | 53 +-
1 file changed, 16 insertions(+), 37 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index cab0dd8..a4634a3 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1515,23 +1515,15 @@ static void
meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear)
{
const char *vs_source =
+ "#extension GL_AMD_vertex_shader_layer : enable\n"
"attribute vec4 position;\n"
- "void main()\n"
- "{\n"
- " gl_Position = position;\n"
- "}\n";
- const char *gs_source =
- "#version 150\n"
- "layout(triangles) in;\n"
- "layout(triangle_strip, max_vertices = 4) out;\n"
"uniform int layer;\n"
"void main()\n"
"{\n"
- " for (int i = 0; i < 3; i++) {\n"
- "gl_Layer = layer;\n"
- "gl_Position = gl_in[i].gl_Position;\n"
- "EmitVertex();\n"
- " }\n"
+ "#ifdef GL_AMD_vertex_shader_layer\n"
+ " gl_Layer = layer;\n"
+ "#endif\n"
+ " gl_Position = position;\n"
"}\n";
const char *fs_source =
"uniform vec4 color;\n"
@@ -1539,7 +1531,7 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
"{\n"
" gl_FragColor = color;\n"
"}\n";
- GLuint vs, gs = 0, fs;
+ GLuint vs, fs;
bool has_integer_textures;
_mesa_meta_setup_vertex_objects(&clear->VAO, &clear->VBO, true, 3, 0, 0);
@@ -1551,12 +1543,6 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
_mesa_ShaderSource(vs, 1, &vs_source, NULL);
_mesa_CompileShader(vs);
- if (_mesa_has_geometry_shaders(ctx)) {
- gs = _mesa_CreateShader(GL_GEOMETRY_SHADER);
- _mesa_ShaderSource(gs, 1, &gs_source, NULL);
- _mesa_CompileShader(gs);
- }
-
fs = _mesa_CreateShader(GL_FRAGMENT_SHADER);
_mesa_ShaderSource(fs, 1, &fs_source, NULL);
_mesa_CompileShader(fs);
@@ -1564,20 +1550,14 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
clear->ShaderProg = _mesa_CreateProgram();
_mesa_AttachShader(clear->ShaderProg, fs);
_mesa_DeleteShader(fs);
- if (gs != 0)
- _mesa_AttachShader(clear->ShaderProg, gs);
_mesa_AttachShader(clear->ShaderProg, vs);
_mesa_DeleteShader(vs);
_mesa_BindAttribLocation(clear->ShaderProg, 0, "position");
_mesa_ObjectLabel(GL_PROGRAM, clear->ShaderProg, -1, "meta clear");
_mesa_LinkProgram(clear->ShaderProg);
- clear->ColorLocation = _mesa_GetUniformLocation(clear->ShaderProg,
- "color");
- if (gs != 0) {
- clear->LayerLocation = _mesa_GetUniformLocation(clear->ShaderProg,
- "layer");
- }
+ clear->ColorLocation = _mesa_GetUniformLocation(clear->ShaderProg, "color");
+ clear->LayerLocation = _mesa_GetUniformLocation(clear->ShaderProg, "layer");
has_integer_textures = _mesa_is_gles3(ctx) ||
(_mesa_is_desktop_gl(ctx) && ctx->Const.GLSLVersion >= 130);
@@ -1587,9 +1567,14 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
const char *vs_int_source =
ralloc_asprintf(shader_source_mem_ctx,
"#version 130\n"
+ "#extension GL_AMD_vertex_shader_layer : enable\n"
"in vec4 position;\n"
+ "uniform int layer;\n"
"void main()\n"
"{\n"
+ "#ifdef GL_AMD_vertex_shader_layer\n"
+ " gl_Layer = layer;\n"
+ "#endif\n"
" gl_Position = position;\n"
"}\n");
const char *fs_int_source =
@@ -1612,8 +1597,6 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
clear_state *clear)
clear->IntegerShaderProg = _mesa_CreateProgram();
_mesa_AttachShader(clear->IntegerShaderProg, fs);
_mesa_DeleteShader(fs);
- if (gs != 0)
- _mesa_AttachShader(clear->IntegerShaderProg, gs);
_mesa_AttachShader(clear->IntegerShaderProg, vs);
_mesa_DeleteShader(vs);
_mesa_BindAttribLocation(clear->IntegerShaderProg, 0, "position");
@@ -1629,13 +1612,9 @@ meta_glsl_clear_init(struct gl_context *ctx, struct
