Re: [Mesa-dev] [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Thu, Aug 21, 2014 at 11:59:04PM -0700, Kenneth Graunke wrote: > On Friday, August 22, 2014 07:30:37 AM Chris Wilson wrote: > > On Thu, Aug 21, 2014 at 08:11:23PM -0700, Ben Widawsky wrote: > > > The primary goal of these patches is to introduce what I've started > > > calling, "prelocations" on Broadwell. A prelocation is like a > > > relocation, except not. When a GPU client specifies a prelocation, it is > > > instructing the kernel where in the GPU address the buffer should be > > > mapped. The mechanic works very similarly to a relocation except it uses > > > the execbuffer object to obtain the offset, and bind if needed. > > > > You are mixing two APIs. One to preallocate an offset at creation > > and one to presume relocations during execbuffer. I'd much rather keep > > the flexible execbuffer approach outlined and first submitted a couple of > > years ago. > > > > > If a GPU > > > client uses only prelocations, the relocation process can be entirely > > > skipped. This sounds like a big win initially, > > > > Close to zero if the client uses existing interfaces. > > -Chris > > Chris, > > I don't know if you've seen Ben's libdrm and Mesa patches, but with a few > patches to libdrm and virtually zero Mesa changes, he's apparently eliminated > our need to do any relocations for the 3D driver. It wasn't invasive at > all---I was surprised. Indeed, you could do everything inside libdrm with the code I posted 2 years ago. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mapi/glapi/gen/gl_API.xml: Summer cleanup.
This adds all the extension names and numbers, adds some missing numbers and fixes the order in places. Future extension additions should be slightly easier by not requiring to find where it should go anymore. Signed-off-by: Olivier Galibert --- src/mapi/glapi/gen/gl_API.xml | 804 ++ 1 file changed, 578 insertions(+), 226 deletions(-) diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index 73f2f75..e91f37e 100644 --- a/src/mapi/glapi/gen/gl_API.xml +++ b/src/mapi/glapi/gen/gl_API.xml @@ -6275,7 +6275,7 @@ - + @@ -6300,7 +6300,7 @@ - + @@ -6335,6 +6335,9 @@ + + + @@ -6360,10 +6363,10 @@ - - - - + + + + @@ -6776,7 +6779,7 @@ - + @@ -7443,7 +7446,7 @@ parameter was in the NV functions. When this error was discovered and fixed, there was already at least one implementation of GLX protocol for ARB_vertex_program, but there were no - implementations of NV_vertex_program. The sollution was to renumber + implementations of NV_vertex_program. The solution was to renumber the opcodes for NV_vertex_program and convert the unused field in the ARB_vertex_program protocol to unused padding. --> @@ -7683,6 +7686,8 @@ + + @@ -8079,7 +8084,7 @@ -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> @@ -8094,79 +8099,79 @@ -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> - - + + -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> - - + + -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> @@ -8176,15 +8181,15 @@ -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> - + @@ -8205,13 +8210,17 @@ -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> - +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> + + + + + @@ -8243,21 +8252,28 @@ - +http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> + + - +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> + + -http://www.w3.org/2001/XInclude"/> + -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> + -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> + + -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> - + -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> - -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> - + -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XInclude"/> - + + -http://www.w3.org/2001/XInclude"/> +http://www.w3.org/2001/XI
[Mesa-dev] [PATCH] glsl/glsl_parser_extras: Handle GLSL 4.50
Signed-off-by: Olivier Galibert
---
src/glsl/glsl_parser_extras.cpp | 2 +-
src/glsl/glsl_parser_extras.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 490c3c8..87d4846 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -50,7 +50,7 @@ glsl_compute_version_string(void *mem_ctx, bool is_es,
unsigned version)
static const unsigned known_desktop_glsl_versions[] =
- { 110, 120, 130, 140, 150, 330, 400, 410, 420, 430, 440 };
+ { 110, 120, 130, 140, 150, 330, 400, 410, 420, 430, 440, 450 };
_mesa_glsl_parse_state::_mesa_glsl_parse_state(struct gl_context *_ctx,
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index c8b9478..cd252f1 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -215,7 +215,7 @@ struct _mesa_glsl_parse_state {
struct {
unsigned ver;
bool es;
- } supported_versions[12];
+ } supported_versions[14];
bool es_shader;
unsigned language_version;
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: uniform sampler should occupy 1 location
In the future for ARB_bindless_texture we might want this to be 2, I'm not sure if we should just do that now. Dave. On 22 August 2014 09:25, Micael Dias wrote: > --- > If samplers occupy zero locations we can run into a lot of issues. See #82921. > I briefly tested this with my own code (which was previously crashing and > misbehaving) and also ran other apps and everything seems to work fine. > I'm not used to contributing code in this fashion, so please forgive me if I'm > making some mistake. Thanks. > > src/glsl/glsl_types.cpp | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp > index 66e9b13..cc05193 100644 > --- a/src/glsl/glsl_types.cpp > +++ b/src/glsl/glsl_types.cpp > @@ -691,6 +691,8 @@ glsl_type::uniform_locations() const >return size; > case GLSL_TYPE_ARRAY: >return this->length * this->fields.array->uniform_locations(); > + case GLSL_TYPE_SAMPLER: > + return 1; > default: >break; > } > -- > 2.1.0 > > ___ > 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] [RFC PATCH 00/16] A new IR for Mesa
In that case staying as close as possible to spir may make sense? OG. On Fri, Aug 22, 2014 at 5:08 AM, Dave Airlie wrote: > On 22 August 2014 12:46, Jason Ekstrand wrote: >> On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote: >>> >>> On 21 August 2014 19:10, Henri Verbeet wrote: >>> > On 21 August 2014 04:56, Michel Dänzer wrote: >>> >> On 21.08.2014 04:29, Henri Verbeet wrote: >>> >>> For whatever it's worth, I have been avoiding radeonsi in part because >>> >>> of the LLVM dependency. Some of the other issues already mentioned >>> >>> aside, I also think it makes it just painful to do bisects over >>> >>> moderate/longer periods of time. >>> >> >>> >> More painful, sure, but not too bad IME. In particular, if you know the >>> >> regression is in Mesa, you can always use a stable release of LLVM for >>> >> the bisect. You only need to change the --with-llvm-prefix= parameter >>> >> to >>> >> Mesa's configure for that. Of course, it could still be mildly painful >>> >> if you need to go so far back that the current stable LLVM release >>> >> wasn't supported yet. But how often does that happen? Very rarely for >>> >> me. >>> >> >>> > Sure, it's not impossible, but is that really the kind of process you >>> > want users to go through when bisecting a regression? Perhaps throw in >>> > building 32-bit versions of both Mesa and LLVM on 64-bit as well if >>> > they want to run 32-bit applications. >>> > >>> >> Without LLVM, I'm not sure there would be a driver you could avoid. :) >>> >> >>> > R600g didn't really exist either, and that one seems to have worked >>> > out fine. I think in a large part because of work done by Jerome and >>> > Dave in the early days, but regardless. From what I've seen from SI, I >>> > don't think radeonsi needed to be a separate driver to start with, and >>> > while its ISA is certainly different from R600-Cayman, it doesn't >>> > particularly strike me as much harder to work with. >>> > >>> > Back to the more immediate topic though, I think think that on >>> > occasion the discussion is framed as "Is there any reason using LLVM >>> > IR wouldn't work?", while it would perhaps be more appropriate to >>> > think of as "Would using LLVM IR provide enough advantages to justify >>> > adding a LLVM dependency to core Mesa?". >>> >>> Could we use an llvm compatible IR? is also a question I'd like to see >>> answered. >> >> >> What do you mean by llvm compatible? Do you mean forking their IR inside >> mesa or just something that's easy to translate back and forth? >> > > Importing/forking the llvm IR code with a different symbol set, and > trying to not intentionally > be incompatible with their llvm. > > Dave. > ___ > 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] SandyBridge not handling GL_TRIANGLE_STRIP_ADJACENCY with repeating vertex indices correctly
On Thu, 2014-08-14 at 14:28 +0200, Iago Toral Quiroga wrote: [...] > At this point I'd like to hear suggestions for things we could try next > to confirm whether this is a hardware problem or a driver problem, or, > if we agree that this is enough evidence that this must be a hardware > problem, how we can limit its impact, starting, probably, by rewriting > the piglit test so that we don't alter its purpose but avoid the hang on > gen6. We should also discuss if there is a way to work around this > problem so that at least developers running into it (as unlikely as that > may be) don't hang their systems. > > I am going to be on holidays starting tomorrow and will have difficult > and limited Internet access for the most part, but Samuel (in the CC) > will be available next week to try any suggestions you may have. As Iago said, I'm available for trying any suggestions you may have. I'm wondering if you need more information about the issue or if I can run more tests in order to confirm/discard this is a HW problem and the next steps to follow. Best regards, Sam 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
[Mesa-dev] [Bug 82946] New: Build failure while linking libMesaOpenCL.la with any Mesa release >= 10.2: undefined references to .LLST7{1, 5, 9}
https://bugs.freedesktop.org/show_bug.cgi?id=82946
Priority: medium
Bug ID: 82946
Assignee: mesa-dev@lists.freedesktop.org
Summary: Build failure while linking libMesaOpenCL.la with any
Mesa release >= 10.2: undefined references to
.LLST7{1,5,9}
Severity: major
Classification: Unclassified
OS: Linux (All)
Reporter: mc2...@mclink.it
Hardware: x86-64 (AMD64)
Status: NEW
Version: 10.2
Component: Other
Product: Mesa
Created attachment 105097
--> https://bugs.freedesktop.org/attachment.cgi?id=105097&action=edit
Log of a failed build
I'm trying to build a rpm package of Mesa 10.2.6 for Rosa Fresh 2012.1 R3, but
the build process always fails while linking libMesaOpenCL.la in
src/gallium/targets/opencl, with the error message below:
***
Making all in opencl
gmake[3]: Entering directory
`/home/giovanni/rpm/BUILD/Mesa-10.2.6/src/gallium/targets/opencl'
CXXLDlibMesaOpenCL.la
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.a9eb1c180a77705c]+0x1e1):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.a9eb1c180a77705c]+0x2bf):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.a9eb1c180a77705c]+0x391):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.ba46d5e26f0312cc]+0x22c):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.ba46d5e26f0312cc]+0x30a):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.ba46d5e26f0312cc]+0x3dc):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.925e964f0ba680c7]+0x1e1):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.925e964f0ba680c7]+0x2bf):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.925e964f0ba680c7]+0x391):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.cae0c7e56b9d064f]+0x578):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.cae0c7e56b9d064f]+0x656):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.cae0c7e56b9d064f]+0x728):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.b0ea443f945b6ea5]+0x3d1):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.b0ea443f945b6ea5]+0x4af):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.b0ea443f945b6ea5]+0x581):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.8993a09bd283ed4a]+0x441):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.8993a09bd283ed4a]+0x51f):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.8993a09bd283ed4a]+0x5f1):
undefined reference to `.LLST79'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.6e263beb89c080c1]+0x449):
undefined reference to `.LLST71'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.6e263beb89c080c1]+0x527):
undefined reference to `.LLST75'
../../../../src/gallium/state_trackers/clover/.libs/libclover.a(lt9-libclover_la-kernel.o):(.debug_types[wt.6e263beb89c080c1]+0x5f9):
undefined reference to `.LLST79'
collect2: error: ld returned 1 exit status
gmake[3]: *** [libMesaOpenCL.la] Error 1
***
The above error is present for me in any released source from Mesa 10.2 to Mesa
10.2.6, while any source from the 10.1.x series does not fail to build.
My build tools:
automake 1.14
libtool 2.4.2
gcc 4.7.4
llvm/clang 3.4 (I tested also the rel. 3.4.2 in a VM, with the same results)
libc
[Mesa-dev] [Bug 82946] Build failure while linking libMesaOpenCL.la with any Mesa release >= 10.2: undefined references to .LLST7{1, 5, 9}
https://bugs.freedesktop.org/show_bug.cgi?id=82946 Giovanni Mariani changed: What|Removed |Added CC||mc2...@mclink.it -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: First step toward prelocation
On Thu, Aug 21, 2014 at 11:12 PM, Ben Widawsky
wrote:
> This was a quick proof of concept to show the new API for prelocating
> buffers.
>
What are prelocated buffers?
Alex
> It needs way more testing, to not ifdef the no-relocs, and to do a
> libdrm ABI dep bump.
> ---
> src/mesa/drivers/dri/i965/Makefile.am | 1 +
> src/mesa/drivers/dri/i965/brw_performance_monitor.c | 6 +++---
> src/mesa/drivers/dri/i965/brw_program.c | 5 +++--
> src/mesa/drivers/dri/i965/brw_queryobj.c| 6 +++---
> src/mesa/drivers/dri/i965/brw_state_cache.c | 4 ++--
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 +++
> src/mesa/drivers/dri/i965/intel_batchbuffer.h | 8
> 7 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.am
> b/src/mesa/drivers/dri/i965/Makefile.am
> index 5809dc6..4b20d36 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.am
> +++ b/src/mesa/drivers/dri/i965/Makefile.am
> @@ -24,6 +24,7 @@
> include Makefile.sources
>
> AM_CFLAGS = \
> +-DNO_RELOC \
> -I$(top_srcdir)/include \
> -I$(top_srcdir)/src/ \
> -I$(top_srcdir)/src/mapi \
> diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
> b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
> index edfa3d2..e30c527 100644
> --- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
> +++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
> @@ -1105,13 +1105,13 @@ brw_begin_perf_monitor(struct gl_context *ctx,
> * wasting memory for contexts that don't use performance monitors.
> */
>if (!brw->perfmon.bookend_bo) {
> - brw->perfmon.bookend_bo = drm_intel_bo_alloc(brw->bufmgr,
> + brw->perfmon.bookend_bo = drm_intel_bo_alloc_wrapper(brw->bufmgr,
>"OA bookend BO",
>BOOKEND_BO_SIZE_BYTES,
> 64);
>}
>
>monitor->oa_bo =
> - drm_intel_bo_alloc(brw->bufmgr, "perf. monitor OA bo", 4096, 64);
> + drm_intel_bo_alloc_wrapper(brw->bufmgr, "perf. monitor OA bo",
> 4096, 64);
> #ifdef DEBUG
>/* Pre-filling the BO helps debug whether writes landed. */
>drm_intel_bo_map(monitor->oa_bo, true);
> @@ -1146,7 +1146,7 @@ brw_begin_perf_monitor(struct gl_context *ctx,
>
> if (monitor_needs_statistics_registers(brw, m)) {
>monitor->pipeline_stats_bo =
> - drm_intel_bo_alloc(brw->bufmgr, "perf. monitor stats bo", 4096, 64);
> + drm_intel_bo_alloc_wrapper(brw->bufmgr, "perf. monitor stats bo",
> 4096, 64);
>
>/* Take starting snapshots. */
>snapshot_statistics_registers(brw, monitor, 0);
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c
> b/src/mesa/drivers/dri/i965/brw_program.c
> index d782b4f..74ff40c 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -43,6 +43,7 @@
>
> #include "brw_context.h"
> #include "brw_wm.h"
> +#include "intel_batchbuffer.h"
>
> static unsigned
> get_new_program_id(struct intel_screen *screen)
> @@ -242,7 +243,7 @@ brw_get_scratch_bo(struct brw_context *brw,
> }
>
> if (!old_bo) {
> - *scratch_bo = drm_intel_bo_alloc(brw->bufmgr, "scratch bo", size,
> 4096);
> + *scratch_bo = drm_intel_bo_alloc_wrapper(brw->bufmgr, "scratch bo",
> size, 4096);
> }
> }
>
> @@ -265,7 +266,7 @@ void
> brw_init_shader_time(struct brw_context *brw)
> {
> const int max_entries = 4096;
> - brw->shader_time.bo = drm_intel_bo_alloc(brw->bufmgr, "shader time",
> + brw->shader_time.bo = drm_intel_bo_alloc_wrapper(brw->bufmgr, "shader
> time",
> max_entries * SHADER_TIME_STRIDE,
> 4096);
> brw->shader_time.shader_programs = rzalloc_array(brw, struct
> gl_shader_program *,
> diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
> b/src/mesa/drivers/dri/i965/brw_queryobj.c
> index c053c34..cf5a2a5 100644
> --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
> @@ -230,7 +230,7 @@ brw_begin_query(struct gl_context *ctx, struct
> gl_query_object *q)
> * the system was doing other work, such as running other applications.
> */
>drm_intel_bo_unreference(query->bo);
> - query->bo = drm_intel_bo_alloc(brw->bufmgr, "timer query", 4096, 4096);
> + query->bo = drm_intel_bo_alloc_wrapper(brw->bufmgr, "timer query",
> 4096, 4096);
>brw_write_timestamp(brw, query->bo, 0);
>break;
>
> @@ -388,7 +388,7 @@ ensure_bo_has_space(struct gl_context *ctx, struct
> brw_query_object *query)
> brw_queryobj_get_results(ctx, query);
>}
>
> - query->bo = drm_intel_bo_alloc(brw->bufmgr, "query", 4096, 1);
> + query->bo = drm_intel_bo_alloc_wrapper(brw->bufmgr, "query", 4096, 1);
>
[Mesa-dev] [Bug 82946] Build failure while linking libMesaOpenCL.la with any Mesa release >= 10.2: undefined references to .LLST7{1, 5, 9}
https://bugs.freedesktop.org/show_bug.cgi?id=82946 --- Comment #1 from Francisco Jerez --- Seems like a compiler bug to me. Your debug section-related CXXFLAGS (-Wa,--compress-debug-sections -gdwarf-4) probably have an influence, try removing them, or upgrade to a more recent version of GCC (works for me with the same compiler flags on GCC v4.9.1). Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling
Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.
Signed-off-by: Andreas Pokorny
---
src/gallium/state_trackers/dri/dri2.c | 8 +++
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 ---
2 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index a63448d..82f8a47 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1333,6 +1333,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
const __DRIconfig **configs;
struct dri_screen *screen;
struct pipe_screen *pscreen = NULL;
+ uint64_t cap;
screen = CALLOC_STRUCT(dri_screen);
if (!screen)
@@ -1344,6 +1345,13 @@ dri_kms_init_screen(__DRIscreen * sPriv)
sPriv->driverPrivate = (void *)screen;
pscreen = kms_swrast_create_screen(screen->fd);
+
+ if (drmGetCap(sPriv->fd, DRM_CAP_PRIME, &cap) == 0 &&
+ (cap & DRM_PRIME_CAP_IMPORT)) {
+ dri2ImageExtension.createImageFromFds = dri2_from_fds;
+ dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
+ }
+
sPriv->extensions = dri_screen_extensions;
/* dri_init_screen_helper checks pscreen for us */
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index c9934bb..286bd9c 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include "pipe/p_compiler.h"
@@ -210,6 +211,38 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
return kms_sw_dt->mapped;
}
+static struct kms_sw_displaytarget *
+kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd)
+{
+ uint32_t handle;
+ struct kms_sw_displaytarget * kms_sw_dt;
+ int ret;
+
+ ret = drmPrimeFDToHandle(kms_sw->fd, fd, &handle);
+
+ if (ret)
+ return NULL;
+
+ kms_sw_dt = CALLOC_STRUCT(kms_sw_displaytarget);
+ if (!kms_sw_dt)
+ return NULL;
+
+ kms_sw_dt->ref_count = 1;
+ kms_sw_dt->handle = handle;
+ kms_sw_dt->size = lseek(fd, 0, SEEK_END);
+
+ if (kms_sw_dt->size == (off_t)-1) {
+ FREE(kms_sw_dt);
+ return NULL;
+ }
+
+ lseek(fd, 0, SEEK_SET);
+
+ list_add(&kms_sw_dt->link, &kms_sw->bo_list);
+
+ return kms_sw_dt;
+}
+
static void
kms_sw_displaytarget_unmap(struct sw_winsys *ws,
struct sw_displaytarget *dt)
@@ -231,17 +264,34 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws,
struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
struct kms_sw_displaytarget *kms_sw_dt;
- assert(whandle->type == DRM_API_HANDLE_TYPE_KMS);
+ assert(whandle->type == DRM_API_HANDLE_TYPE_KMS ||
+ whandle->type == DRM_API_HANDLE_TYPE_FD);
- LIST_FOR_EACH_ENTRY(kms_sw_dt, &kms_sw->bo_list, link) {
- if (kms_sw_dt->handle == whandle->handle) {
+ switch(whandle->type) {
+ case DRM_API_HANDLE_TYPE_FD:
+ kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw, whandle->handle);
+ if (kms_sw_dt) {
kms_sw_dt->ref_count++;
+ kms_sw_dt->width = templ->width0;
+ kms_sw_dt->height = templ->height0;
+ if (kms_sw_dt->height)
+kms_sw_dt->stride = kms_sw_dt->size/kms_sw_dt->height;
+ *stride = kms_sw_dt->stride;
+ }
+ return (struct sw_displaytarget *)kms_sw_dt;
+ case DRM_API_HANDLE_TYPE_KMS:
+ LIST_FOR_EACH_ENTRY(kms_sw_dt, &kms_sw->bo_list, link) {
+ if (kms_sw_dt->handle == whandle->handle) {
+kms_sw_dt->ref_count++;
- DEBUG("KMS-DEBUG: imported buffer %u (size %u)\n", kms_sw_dt->handle,
kms_sw_dt->size);
+DEBUG("KMS-DEBUG: imported buffer %u (size %u)\n",
kms_sw_dt->handle, kms_sw_dt->size);
- *stride = kms_sw_dt->stride;
- return (struct sw_displaytarget *)kms_sw_dt;
+*stride = kms_sw_dt->stride;
+return (struct sw_displaytarget *)kms_sw_dt;
+ }
}
+ default:
+ break;
}
assert(0);
@@ -253,16 +303,26 @@ kms_sw_displaytarget_get_handle(struct sw_winsys *winsys,
struct sw_displaytarget *dt,
struct winsys_handle *whandle)
{
+ struct kms_sw_winsys *kms_sw = kms_sw_winsys(winsys);
struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
- if (whandle->type == DRM_API_HANDLE_TYPE_KMS) {
+ switch(whandle->type) {
+ case DRM_API_HANDLE_TYPE_KMS:
whandle->handle = kms_sw_dt->handle;
whandle->stride = kms_sw_dt->stride;
- } else {
+ return TRUE;
+ case DRM_API_HANDLE_TYPE_FD:
+ if (!drmPrimeHandleToFD(kms_sw->fd, kms_sw_dt->handle,
+ DRM_CLOEXEC, &whandle->handle)) {
+ whandle->stride = kms_sw_dt->stride;
+ retu
[Mesa-dev] [PATCH] kma-swrast: PRIME support v2
Hi, This adds support for dma_bufs throught fds to kms_swrast. Andreas Pokorny (1): kms-swrast: Support Prime fd handling src/gallium/state_trackers/dri/dri2.c | 8 +++ src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 --- 2 files changed, 78 insertions(+), 10 deletions(-) -- 2.1.0.rc1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson wrote: >> > > If a GPU >> > > client uses only prelocations, the relocation process can be entirely >> > > skipped. This sounds like a big win initially, >> > >> > Close to zero if the client uses existing interfaces. >> > -Chris >> >> Chris, >> >> I don't know if you've seen Ben's libdrm and Mesa patches, but with a few >> patches to libdrm and virtually zero Mesa changes, he's apparently >> eliminated our need to do any relocations for the 3D driver. It wasn't >> invasive at all---I was surprised. > > Indeed, you could do everything inside libdrm with the code I posted 2 > years ago. I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need to walk all the reloc tables (if nothing moved) because userspace didn't go insane and reuse reloc trees. So you'd need to implement a flag + a libdrm function to set that (iirc mesa has been non-stupid since years). And yeah I kinda expect any new reloc-less thing to get benchmarked against an implementation using that, since the 48bit specific thing proposed looks like a fairly short-lived stop-gap, and since the current no-reloc we already have would work everywhere. And yeah I've been poking people to look at this for years. too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote: > On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson > wrote: > >> > > If a GPU > >> > > client uses only prelocations, the relocation process can be entirely > >> > > skipped. This sounds like a big win initially, > >> > > >> > Close to zero if the client uses existing interfaces. > >> > -Chris > >> > >> Chris, > >> > >> I don't know if you've seen Ben's libdrm and Mesa patches, but with a few > >> patches to libdrm and virtually zero Mesa changes, he's apparently > >> eliminated our need to do any relocations for the 3D driver. It wasn't > >> invasive at all---I was surprised. > > > > Indeed, you could do everything inside libdrm with the code I posted 2 > > years ago. > > I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need > to walk all the reloc tables (if nothing moved) because userspace > didn't go insane and reuse reloc trees. So you'd need to implement a > flag + a libdrm function to set that (iirc mesa has been non-stupid > since years). And yeah I kinda expect any new reloc-less thing to get > benchmarked against an implementation using that, since the 48bit > specific thing proposed looks like a fairly short-lived stop-gap, and > since the current no-reloc we already have would work everywhere. And > yeah I've been poking people to look at this for years. too. Here, I was referring to soft-pinning. The API here is essentially comprised of two parts: 1: a pin into the vm upon creation 2: implicit no-relocation upon execbuffer By making those two steps independent, the API as I see is, is more flexible and powerful. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Fri, Aug 22, 2014 at 01:08:02PM +1000, Dave Airlie wrote: > On 22 August 2014 12:46, Jason Ekstrand wrote: > > On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote: > >> > >> On 21 August 2014 19:10, Henri Verbeet wrote: > >> > On 21 August 2014 04:56, Michel Dänzer wrote: > >> >> On 21.08.2014 04:29, Henri Verbeet wrote: > >> >>> For whatever it's worth, I have been avoiding radeonsi in part because > >> >>> of the LLVM dependency. Some of the other issues already mentioned > >> >>> aside, I also think it makes it just painful to do bisects over > >> >>> moderate/longer periods of time. > >> >> > >> >> More painful, sure, but not too bad IME. In particular, if you know the > >> >> regression is in Mesa, you can always use a stable release of LLVM for > >> >> the bisect. You only need to change the --with-llvm-prefix= parameter > >> >> to > >> >> Mesa's configure for that. Of course, it could still be mildly painful > >> >> if you need to go so far back that the current stable LLVM release > >> >> wasn't supported yet. But how often does that happen? Very rarely for > >> >> me. > >> >> > >> > Sure, it's not impossible, but is that really the kind of process you > >> > want users to go through when bisecting a regression? Perhaps throw in > >> > building 32-bit versions of both Mesa and LLVM on 64-bit as well if > >> > they want to run 32-bit applications. > >> > > >> >> Without LLVM, I'm not sure there would be a driver you could avoid. :) > >> >> > >> > R600g didn't really exist either, and that one seems to have worked > >> > out fine. I think in a large part because of work done by Jerome and > >> > Dave in the early days, but regardless. From what I've seen from SI, I > >> > don't think radeonsi needed to be a separate driver to start with, and > >> > while its ISA is certainly different from R600-Cayman, it doesn't > >> > particularly strike me as much harder to work with. > >> > > >> > Back to the more immediate topic though, I think think that on > >> > occasion the discussion is framed as "Is there any reason using LLVM > >> > IR wouldn't work?", while it would perhaps be more appropriate to > >> > think of as "Would using LLVM IR provide enough advantages to justify > >> > adding a LLVM dependency to core Mesa?". > >> > >> Could we use an llvm compatible IR? is also a question I'd like to see > >> answered. > > > > > > What do you mean by llvm compatible? Do you mean forking their IR inside > > mesa or just something that's easy to translate back and forth? > > > > Importing/forking the llvm IR code with a different symbol set, and > trying to not intentionally > be incompatible with their llvm. > What would be the purpose of doing this? Avoiding a dependency on the LLVM libraries? -Tom > Dave. > ___ > 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] [RFC PATCH 00/16] A new IR for Mesa
On 23 August 2014 00:15, Tom Stellard wrote: > On Fri, Aug 22, 2014 at 01:08:02PM +1000, Dave Airlie wrote: >> On 22 August 2014 12:46, Jason Ekstrand wrote: >> > On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote: >> >> >> >> On 21 August 2014 19:10, Henri Verbeet wrote: >> >> > On 21 August 2014 04:56, Michel Dänzer wrote: >> >> >> On 21.08.2014 04:29, Henri Verbeet wrote: >> >> >>> For whatever it's worth, I have been avoiding radeonsi in part because >> >> >>> of the LLVM dependency. Some of the other issues already mentioned >> >> >>> aside, I also think it makes it just painful to do bisects over >> >> >>> moderate/longer periods of time. >> >> >> >> >> >> More painful, sure, but not too bad IME. In particular, if you know the >> >> >> regression is in Mesa, you can always use a stable release of LLVM for >> >> >> the bisect. You only need to change the --with-llvm-prefix= parameter >> >> >> to >> >> >> Mesa's configure for that. Of course, it could still be mildly painful >> >> >> if you need to go so far back that the current stable LLVM release >> >> >> wasn't supported yet. But how often does that happen? Very rarely for >> >> >> me. >> >> >> >> >> > Sure, it's not impossible, but is that really the kind of process you >> >> > want users to go through when bisecting a regression? Perhaps throw in >> >> > building 32-bit versions of both Mesa and LLVM on 64-bit as well if >> >> > they want to run 32-bit applications. >> >> > >> >> >> Without LLVM, I'm not sure there would be a driver you could avoid. :) >> >> >> >> >> > R600g didn't really exist either, and that one seems to have worked >> >> > out fine. I think in a large part because of work done by Jerome and >> >> > Dave in the early days, but regardless. From what I've seen from SI, I >> >> > don't think radeonsi needed to be a separate driver to start with, and >> >> > while its ISA is certainly different from R600-Cayman, it doesn't >> >> > particularly strike me as much harder to work with. >> >> > >> >> > Back to the more immediate topic though, I think think that on >> >> > occasion the discussion is framed as "Is there any reason using LLVM >> >> > IR wouldn't work?", while it would perhaps be more appropriate to >> >> > think of as "Would using LLVM IR provide enough advantages to justify >> >> > adding a LLVM dependency to core Mesa?". >> >> >> >> Could we use an llvm compatible IR? is also a question I'd like to see >> >> answered. >> > >> > >> > What do you mean by llvm compatible? Do you mean forking their IR inside >> > mesa or just something that's easy to translate back and forth? >> > >> >> Importing/forking the llvm IR code with a different symbol set, and >> trying to not intentionally >> be incompatible with their llvm. >> > > What would be the purpose of doing this? Avoiding a dependency on the LLVM > libraries? Spltting the problem of using llvm IR from the problem of linking with llvm, since people appear to be conflating them. So yes avoid the direct dep for now. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: uniform sampler should occupy 1 location
Is this because of the 64 bit handles? If so, I think I agree with you. According to the ARB_bindless_texture spec changes: "When used as shader inputs, outputs, uniform block members, or temporaries, the value of the sampler is a 64-bit unsigned integer handle and never refers to a texture image unit." However, should we consume 2 locs only if ARB_bindless_texture is present, or always? On Fri, Aug 22, 2014 at 8:36 AM, Dave Airlie wrote: > In the future for ARB_bindless_texture we might want this to be 2, I'm > not sure if we should just do that now. > > Dave. > > On 22 August 2014 09:25, Micael Dias wrote: > > --- > > If samplers occupy zero locations we can run into a lot of issues. See > #82921. > > I briefly tested this with my own code (which was previously crashing and > > misbehaving) and also ran other apps and everything seems to work fine. > > I'm not used to contributing code in this fashion, so please forgive me > if I'm > > making some mistake. Thanks. > > > > src/glsl/glsl_types.cpp | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp > > index 66e9b13..cc05193 100644 > > --- a/src/glsl/glsl_types.cpp > > +++ b/src/glsl/glsl_types.cpp > > @@ -691,6 +691,8 @@ glsl_type::uniform_locations() const > >return size; > > case GLSL_TYPE_ARRAY: > >return this->length * this->fields.array->uniform_locations(); > > + case GLSL_TYPE_SAMPLER: > > + return 1; > > default: > >break; > > } > > -- > > 2.1.0 > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Micael Dias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82946] Build failure while linking libMesaOpenCL.la with any Mesa release >= 10.2: undefined references to .LLST7{1, 5, 9}
https://bugs.freedesktop.org/show_bug.cgi?id=82946 --- Comment #2 from Giovanni Mariani --- (In reply to comment #1) > Seems like a compiler bug to me. Your debug section-related CXXFLAGS > (-Wa,--compress-debug-sections -gdwarf-4) probably have an influence, try > removing them, or upgrade to a more recent version of GCC (works for me with > the same compiler flags on GCC v4.9.1). > > Thanks. Removing the above part of CXXFLAGS gives me the same result as the old one... I will look for a gcc upgrade (the nearly done Rosa 2014.1 will have gcc 4.9.1, so perhaps I will wait for it). -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie wrote: > On 22 August 2014 12:46, Jason Ekstrand wrote: >> On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote: >>> >>> On 21 August 2014 19:10, Henri Verbeet wrote: >>> > On 21 August 2014 04:56, Michel Dänzer wrote: >>> >> On 21.08.2014 04:29, Henri Verbeet wrote: >>> >>> For whatever it's worth, I have been avoiding radeonsi in part because >>> >>> of the LLVM dependency. Some of the other issues already mentioned >>> >>> aside, I also think it makes it just painful to do bisects over >>> >>> moderate/longer periods of time. >>> >> >>> >> More painful, sure, but not too bad IME. In particular, if you know the >>> >> regression is in Mesa, you can always use a stable release of LLVM for >>> >> the bisect. You only need to change the --with-llvm-prefix= parameter >>> >> to >>> >> Mesa's configure for that. Of course, it could still be mildly painful >>> >> if you need to go so far back that the current stable LLVM release >>> >> wasn't supported yet. But how often does that happen? Very rarely for >>> >> me. >>> >> >>> > Sure, it's not impossible, but is that really the kind of process you >>> > want users to go through when bisecting a regression? Perhaps throw in >>> > building 32-bit versions of both Mesa and LLVM on 64-bit as well if >>> > they want to run 32-bit applications. >>> > >>> >> Without LLVM, I'm not sure there would be a driver you could avoid. :) >>> >> >>> > R600g didn't really exist either, and that one seems to have worked >>> > out fine. I think in a large part because of work done by Jerome and >>> > Dave in the early days, but regardless. From what I've seen from SI, I >>> > don't think radeonsi needed to be a separate driver to start with, and >>> > while its ISA is certainly different from R600-Cayman, it doesn't >>> > particularly strike me as much harder to work with. >>> > >>> > Back to the more immediate topic though, I think think that on >>> > occasion the discussion is framed as "Is there any reason using LLVM >>> > IR wouldn't work?", while it would perhaps be more appropriate to >>> > think of as "Would using LLVM IR provide enough advantages to justify >>> > adding a LLVM dependency to core Mesa?". >>> >>> Could we use an llvm compatible IR? is also a question I'd like to see >>> answered. >> >> >> What do you mean by llvm compatible? Do you mean forking their IR inside >> mesa or just something that's easy to translate back and forth? >> > > Importing/forking the llvm IR code with a different symbol set, and > trying to not intentionally > be incompatible with their llvm. That sounds like a huge amount of work, possibly even more work than going it on our own because the LLVM project moves really quickly and we'd have to import all of the changes. Also, it seems pretty ugly and I'm sure distro maintainers would just looove a solution like that /s. Just look at the situation with Chromium and Fedora now (or at least last I checked). Connor > > Dave. > ___ > 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] [RFC PATCH 00/16] A new IR for Mesa
Am 22.08.2014 um 17:13 schrieb Connor Abbott: On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie wrote: On 22 August 2014 12:46, Jason Ekstrand wrote: On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote: On 21 August 2014 19:10, Henri Verbeet wrote: On 21 August 2014 04:56, Michel Dänzer wrote: On 21.08.2014 04:29, Henri Verbeet wrote: For whatever it's worth, I have been avoiding radeonsi in part because of the LLVM dependency. Some of the other issues already mentioned aside, I also think it makes it just painful to do bisects over moderate/longer periods of time. More painful, sure, but not too bad IME. In particular, if you know the regression is in Mesa, you can always use a stable release of LLVM for the bisect. You only need to change the --with-llvm-prefix= parameter to Mesa's configure for that. Of course, it could still be mildly painful if you need to go so far back that the current stable LLVM release wasn't supported yet. But how often does that happen? Very rarely for me. Sure, it's not impossible, but is that really the kind of process you want users to go through when bisecting a regression? Perhaps throw in building 32-bit versions of both Mesa and LLVM on 64-bit as well if they want to run 32-bit applications. Without LLVM, I'm not sure there would be a driver you could avoid. :) R600g didn't really exist either, and that one seems to have worked out fine. I think in a large part because of work done by Jerome and Dave in the early days, but regardless. From what I've seen from SI, I don't think radeonsi needed to be a separate driver to start with, and while its ISA is certainly different from R600-Cayman, it doesn't particularly strike me as much harder to work with. Back to the more immediate topic though, I think think that on occasion the discussion is framed as "Is there any reason using LLVM IR wouldn't work?", while it would perhaps be more appropriate to think of as "Would using LLVM IR provide enough advantages to justify adding a LLVM dependency to core Mesa?". Could we use an llvm compatible IR? is also a question I'd like to see answered. What do you mean by llvm compatible? Do you mean forking their IR inside mesa or just something that's easy to translate back and forth? Importing/forking the llvm IR code with a different symbol set, and trying to not intentionally be incompatible with their llvm. That sounds like a huge amount of work, possibly even more work than going it on our own because the LLVM project moves really quickly and we'd have to import all of the changes. Also, it seems pretty ugly and I'm sure distro maintainers would just looove a solution like that /s. Just look at the situation with Chromium and Fedora now (or at least last I checked). Actually the LLVM IR is considered stable and as Dave explained we wouldn't depend on LLVM, but rather just use the same concept for the IR. This actually sounds like a pretty good idea to me. And I would say we should just continue moving the GLSL IR towards SSA and all the specialized GL opcodes into something similar to LLVM intrinsics. Christian. Connor Dave. ___ 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Fri, Aug 22, 2014 at 11:27 AM, Christian König wrote: > Am 22.08.2014 um 17:13 schrieb Connor Abbott: > >> On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie wrote: >>> >>> On 22 August 2014 12:46, Jason Ekstrand wrote: On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote: > > On 21 August 2014 19:10, Henri Verbeet wrote: >> >> On 21 August 2014 04:56, Michel Dänzer wrote: >>> >>> On 21.08.2014 04:29, Henri Verbeet wrote: For whatever it's worth, I have been avoiding radeonsi in part because of the LLVM dependency. Some of the other issues already mentioned aside, I also think it makes it just painful to do bisects over moderate/longer periods of time. >>> >>> More painful, sure, but not too bad IME. In particular, if you know >>> the >>> regression is in Mesa, you can always use a stable release of LLVM >>> for >>> the bisect. You only need to change the --with-llvm-prefix= parameter >>> to >>> Mesa's configure for that. Of course, it could still be mildly >>> painful >>> if you need to go so far back that the current stable LLVM release >>> wasn't supported yet. But how often does that happen? Very rarely for >>> me. >>> >> Sure, it's not impossible, but is that really the kind of process you >> want users to go through when bisecting a regression? Perhaps throw in >> building 32-bit versions of both Mesa and LLVM on 64-bit as well if >> they want to run 32-bit applications. >> >>> Without LLVM, I'm not sure there would be a driver you could avoid. >>> :) >>> >> R600g didn't really exist either, and that one seems to have worked >> out fine. I think in a large part because of work done by Jerome and >> Dave in the early days, but regardless. From what I've seen from SI, I >> don't think radeonsi needed to be a separate driver to start with, and >> while its ISA is certainly different from R600-Cayman, it doesn't >> particularly strike me as much harder to work with. >> >> Back to the more immediate topic though, I think think that on >> occasion the discussion is framed as "Is there any reason using LLVM >> IR wouldn't work?", while it would perhaps be more appropriate to >> think of as "Would using LLVM IR provide enough advantages to justify >> adding a LLVM dependency to core Mesa?". > > Could we use an llvm compatible IR? is also a question I'd like to see > answered. What do you mean by llvm compatible? Do you mean forking their IR inside mesa or just something that's easy to translate back and forth? >>> Importing/forking the llvm IR code with a different symbol set, and >>> trying to not intentionally >>> be incompatible with their llvm. >> >> That sounds like a huge amount of work, possibly even more work than >> going it on our own because the LLVM project moves really quickly and >> we'd have to import all of the changes. Also, it seems pretty ugly and >> I'm sure distro maintainers would just looove a solution like that >> /s. Just look at the situation with Chromium and Fedora now (or at >> least last I checked). > > > Actually the LLVM IR is considered stable and as Dave explained we wouldn't > depend on LLVM, but rather just use the same concept for the IR. Except the optimization passes aren't, and those are what we would actually use the IR for... > > This actually sounds like a pretty good idea to me. And I would say we > should just continue moving the GLSL IR towards SSA and all the specialized > GL opcodes into something similar to LLVM intrinsics. So, in other words, using NIR ;) NIR already has intrinsics, and while it does have some extra things (swizzles, writemasks, modifiers) those are only there to make things a little easier on the drivers that want to use them and absolutely aren't necessary. As of now, we already don't care about writemasks in the optimization passes because they don't matter with SSA, and we can avoid caring about the others as well if it makes optimizations easier. Connor > > Christian. > > >> >> Connor >> >>> Dave. >>> ___ >>> 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Fri, Aug 22, 2014 at 11:27 AM, Christian König wrote: > Am 22.08.2014 um 17:13 schrieb Connor Abbott: > >> On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie wrote: >>> >>> On 22 August 2014 12:46, Jason Ekstrand wrote: On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote: > > On 21 August 2014 19:10, Henri Verbeet wrote: >> >> On 21 August 2014 04:56, Michel Dänzer wrote: >>> >>> On 21.08.2014 04:29, Henri Verbeet wrote: For whatever it's worth, I have been avoiding radeonsi in part because of the LLVM dependency. Some of the other issues already mentioned aside, I also think it makes it just painful to do bisects over moderate/longer periods of time. >>> >>> More painful, sure, but not too bad IME. In particular, if you know >>> the >>> regression is in Mesa, you can always use a stable release of LLVM >>> for >>> the bisect. You only need to change the --with-llvm-prefix= parameter >>> to >>> Mesa's configure for that. Of course, it could still be mildly >>> painful >>> if you need to go so far back that the current stable LLVM release >>> wasn't supported yet. But how often does that happen? Very rarely for >>> me. >>> >> Sure, it's not impossible, but is that really the kind of process you >> want users to go through when bisecting a regression? Perhaps throw in >> building 32-bit versions of both Mesa and LLVM on 64-bit as well if >> they want to run 32-bit applications. >> >>> Without LLVM, I'm not sure there would be a driver you could avoid. >>> :) >>> >> R600g didn't really exist either, and that one seems to have worked >> out fine. I think in a large part because of work done by Jerome and >> Dave in the early days, but regardless. From what I've seen from SI, I >> don't think radeonsi needed to be a separate driver to start with, and >> while its ISA is certainly different from R600-Cayman, it doesn't >> particularly strike me as much harder to work with. >> >> Back to the more immediate topic though, I think think that on >> occasion the discussion is framed as "Is there any reason using LLVM >> IR wouldn't work?", while it would perhaps be more appropriate to >> think of as "Would using LLVM IR provide enough advantages to justify >> adding a LLVM dependency to core Mesa?". > > Could we use an llvm compatible IR? is also a question I'd like to see > answered. What do you mean by llvm compatible? Do you mean forking their IR inside mesa or just something that's easy to translate back and forth? >>> Importing/forking the llvm IR code with a different symbol set, and >>> trying to not intentionally >>> be incompatible with their llvm. >> >> That sounds like a huge amount of work, possibly even more work than >> going it on our own because the LLVM project moves really quickly and >> we'd have to import all of the changes. Also, it seems pretty ugly and >> I'm sure distro maintainers would just looove a solution like that >> /s. Just look at the situation with Chromium and Fedora now (or at >> least last I checked). > > > Actually the LLVM IR is considered stable and as Dave explained we wouldn't > depend on LLVM, but rather just use the same concept for the IR. > > This actually sounds like a pretty good idea to me. And I would say we > should just continue moving the GLSL IR towards SSA and all the specialized > GL opcodes into something similar to LLVM intrinsics. And, coming from the guy who's done the the existing "moving GLSL IR towards SSA," it just sucks. It's not worth it. That was one of the main reasons I started on NIR, besides knowing that the Intel people were against adding a dependency to LLVM to their driver. > > Christian. > > >> >> Connor >> >>> Dave. >>> ___ >>> 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Sat, Aug 23, 2014 at 12:17:00AM +1000, Dave Airlie wrote: > On 23 August 2014 00:15, Tom Stellard wrote: > > On Fri, Aug 22, 2014 at 01:08:02PM +1000, Dave Airlie wrote: > >> On 22 August 2014 12:46, Jason Ekstrand wrote: > >> > On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote: > >> >> > >> >> On 21 August 2014 19:10, Henri Verbeet wrote: > >> >> > On 21 August 2014 04:56, Michel Dänzer wrote: > >> >> >> On 21.08.2014 04:29, Henri Verbeet wrote: > >> >> >>> For whatever it's worth, I have been avoiding radeonsi in part > >> >> >>> because > >> >> >>> of the LLVM dependency. Some of the other issues already mentioned > >> >> >>> aside, I also think it makes it just painful to do bisects over > >> >> >>> moderate/longer periods of time. > >> >> >> > >> >> >> More painful, sure, but not too bad IME. In particular, if you know > >> >> >> the > >> >> >> regression is in Mesa, you can always use a stable release of LLVM > >> >> >> for > >> >> >> the bisect. You only need to change the --with-llvm-prefix= parameter > >> >> >> to > >> >> >> Mesa's configure for that. Of course, it could still be mildly > >> >> >> painful > >> >> >> if you need to go so far back that the current stable LLVM release > >> >> >> wasn't supported yet. But how often does that happen? Very rarely for > >> >> >> me. > >> >> >> > >> >> > Sure, it's not impossible, but is that really the kind of process you > >> >> > want users to go through when bisecting a regression? Perhaps throw in > >> >> > building 32-bit versions of both Mesa and LLVM on 64-bit as well if > >> >> > they want to run 32-bit applications. > >> >> > > >> >> >> Without LLVM, I'm not sure there would be a driver you could avoid. > >> >> >> :) > >> >> >> > >> >> > R600g didn't really exist either, and that one seems to have worked > >> >> > out fine. I think in a large part because of work done by Jerome and > >> >> > Dave in the early days, but regardless. From what I've seen from SI, I > >> >> > don't think radeonsi needed to be a separate driver to start with, and > >> >> > while its ISA is certainly different from R600-Cayman, it doesn't > >> >> > particularly strike me as much harder to work with. > >> >> > > >> >> > Back to the more immediate topic though, I think think that on > >> >> > occasion the discussion is framed as "Is there any reason using LLVM > >> >> > IR wouldn't work?", while it would perhaps be more appropriate to > >> >> > think of as "Would using LLVM IR provide enough advantages to justify > >> >> > adding a LLVM dependency to core Mesa?". > >> >> > >> >> Could we use an llvm compatible IR? is also a question I'd like to see > >> >> answered. > >> > > >> > > >> > What do you mean by llvm compatible? Do you mean forking their IR inside > >> > mesa or just something that's easy to translate back and forth? > >> > > >> > >> Importing/forking the llvm IR code with a different symbol set, and > >> trying to not intentionally > >> be incompatible with their llvm. > >> > > > > What would be the purpose of doing this? Avoiding a dependency on the LLVM > > libraries? > > Spltting the problem of using llvm IR from the problem of linking with > llvm, since people > appear to be conflating them. > > So yes avoid the direct dep for now. > The main advantage of using LLVM IR is having access to all the functionality provided by the libraries, so while it would be possible to use the IR without the library, it would be a lot of work with no benefit. -Tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling
Allows using prime fds as display target and from display target.
Test for PRIME capability after initializing kms_swrast screen.
Signed-off-by: Andreas Pokorny
---
src/gallium/state_trackers/dri/dri2.c | 8 +++
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 ---
2 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index a63448d..82f8a47 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1333,6 +1333,7 @@ dri_kms_init_screen(__DRIscreen * sPriv)
const __DRIconfig **configs;
struct dri_screen *screen;
struct pipe_screen *pscreen = NULL;
+ uint64_t cap;
screen = CALLOC_STRUCT(dri_screen);
if (!screen)
@@ -1344,6 +1345,13 @@ dri_kms_init_screen(__DRIscreen * sPriv)
sPriv->driverPrivate = (void *)screen;
pscreen = kms_swrast_create_screen(screen->fd);
+
+ if (drmGetCap(sPriv->fd, DRM_CAP_PRIME, &cap) == 0 &&
+ (cap & DRM_PRIME_CAP_IMPORT)) {
+ dri2ImageExtension.createImageFromFds = dri2_from_fds;
+ dri2ImageExtension.createImageFromDmaBufs = dri2_from_dma_bufs;
+ }
+
sPriv->extensions = dri_screen_extensions;
/* dri_init_screen_helper checks pscreen for us */
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index c9934bb..ba0660c 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include "pipe/p_compiler.h"
@@ -210,6 +211,38 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
return kms_sw_dt->mapped;
}
+static struct kms_sw_displaytarget *
+kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd)
+{
+ uint32_t handle = -1;
+ struct kms_sw_displaytarget * kms_sw_dt;
+ int ret;
+
+ ret = drmPrimeFDToHandle(kms_sw->fd, fd, &handle);
+
+ if (ret)
+ return NULL;
+
+ kms_sw_dt = CALLOC_STRUCT(kms_sw_displaytarget);
+ if (!kms_sw_dt)
+ return NULL;
+
+ kms_sw_dt->ref_count = 1;
+ kms_sw_dt->handle = handle;
+ kms_sw_dt->size = lseek(fd, 0, SEEK_END);
+
+ if (kms_sw_dt->size == (off_t)-1) {
+ FREE(kms_sw_dt);
+ return NULL;
+ }
+
+ lseek(fd, 0, SEEK_SET);
+
+ list_add(&kms_sw_dt->link, &kms_sw->bo_list);
+
+ return kms_sw_dt;
+}
+
static void
kms_sw_displaytarget_unmap(struct sw_winsys *ws,
struct sw_displaytarget *dt)
@@ -231,17 +264,34 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws,
struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
struct kms_sw_displaytarget *kms_sw_dt;
- assert(whandle->type == DRM_API_HANDLE_TYPE_KMS);
+ assert(whandle->type == DRM_API_HANDLE_TYPE_KMS ||
+ whandle->type == DRM_API_HANDLE_TYPE_FD);
- LIST_FOR_EACH_ENTRY(kms_sw_dt, &kms_sw->bo_list, link) {
- if (kms_sw_dt->handle == whandle->handle) {
+ switch(whandle->type) {
+ case DRM_API_HANDLE_TYPE_FD:
+ kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw, whandle->handle);
+ if (kms_sw_dt) {
kms_sw_dt->ref_count++;
+ kms_sw_dt->width = templ->width0;
+ kms_sw_dt->height = templ->height0;
+ kms_sw_dt->stride = whandle->stride;
+ if (stride)
+*stride = kms_sw_dt->stride;
+ }
+ return (struct sw_displaytarget *)kms_sw_dt;
+ case DRM_API_HANDLE_TYPE_KMS:
+ LIST_FOR_EACH_ENTRY(kms_sw_dt, &kms_sw->bo_list, link) {
+ if (kms_sw_dt->handle == whandle->handle) {
+kms_sw_dt->ref_count++;
- DEBUG("KMS-DEBUG: imported buffer %u (size %u)\n", kms_sw_dt->handle,
kms_sw_dt->size);
+DEBUG("KMS-DEBUG: imported buffer %u (size %u)\n",
kms_sw_dt->handle, kms_sw_dt->size);
- *stride = kms_sw_dt->stride;
- return (struct sw_displaytarget *)kms_sw_dt;
+*stride = kms_sw_dt->stride;
+return (struct sw_displaytarget *)kms_sw_dt;
+ }
}
+ default:
+ break;
}
assert(0);
@@ -253,16 +303,26 @@ kms_sw_displaytarget_get_handle(struct sw_winsys *winsys,
struct sw_displaytarget *dt,
struct winsys_handle *whandle)
{
+ struct kms_sw_winsys *kms_sw = kms_sw_winsys(winsys);
struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
- if (whandle->type == DRM_API_HANDLE_TYPE_KMS) {
+ switch(whandle->type) {
+ case DRM_API_HANDLE_TYPE_KMS:
whandle->handle = kms_sw_dt->handle;
whandle->stride = kms_sw_dt->stride;
- } else {
+ return TRUE;
+ case DRM_API_HANDLE_TYPE_FD:
+ if (!drmPrimeHandleToFD(kms_sw->fd, kms_sw_dt->handle,
+ DRM_CLOEXEC, &whandle->handle)) {
+ whandle->stride = kms_sw_dt->stride;
+ return TRUE;
+ }
+
[Mesa-dev] [PATCH] kms-swrast: Support Prime fd handling v3
Hi, This should be the final version. Not sure why I even messed with guessing the stride value. regards Andreas Pokorny Andreas Pokorny (1): kms-swrast: Support Prime fd handling src/gallium/state_trackers/dri/dri2.c | 8 +++ src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 80 --- 2 files changed, 78 insertions(+), 10 deletions(-) -- 2.1.0.rc1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix JIP/UIP calculations.
On Thursday, August 21, 2014 11:10:26 PM Matt Turner wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82846
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82929
> ---
> Planning to commit this to master as well as to 10.3 directly,
> since BDW is just broken without it.
>
> src/mesa/drivers/dri/i965/brw_eu_compact.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
> b/src/mesa/drivers/dri/i965/brw_eu_compact.c
> index 3680c55..4f509dd 100644
> --- a/src/mesa/drivers/dri/i965/brw_eu_compact.c
> +++ b/src/mesa/drivers/dri/i965/brw_eu_compact.c
> @@ -1029,19 +1029,17 @@ update_uip_jip(struct brw_context *brw, brw_inst
> *insn,
> {
> int scale = brw->gen >= 8 ? sizeof(brw_compact_inst) : 1;
>
> - int32_t jip = brw_inst_jip(brw, insn);
> - jip -= scale *
> - compacted_between(this_old_ip, this_old_ip + jip, compacted_counts);
> - brw_inst_set_jip(brw, insn, jip);
> + int32_t jip = brw_inst_jip(brw, insn) / scale;
> + jip -= compacted_between(this_old_ip, this_old_ip + jip,
> compacted_counts);
> + brw_inst_set_jip(brw, insn, jip * scale);
>
> if (brw_inst_opcode(brw, insn) == BRW_OPCODE_ENDIF ||
> brw_inst_opcode(brw, insn) == BRW_OPCODE_WHILE)
>return;
>
> - int32_t uip = brw_inst_uip(brw, insn);
> - uip -= scale *
> - compacted_between(this_old_ip, this_old_ip + uip, compacted_counts);
> - brw_inst_set_uip(brw, insn, uip);
> + int32_t uip = brw_inst_uip(brw, insn) / scale;
> + uip -= compacted_between(this_old_ip, this_old_ip + uip,
> compacted_counts);
> + brw_inst_set_uip(brw, insn, uip * scale);
> }
>
> void
>
Seems okay to me.
Reviewed-by: Kenneth Graunke
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] i965: First step toward prelocation
On Fri, Aug 22, 2014 at 08:15:28AM -0400, Alex Deucher wrote:
> On Thu, Aug 21, 2014 at 11:12 PM, Ben Widawsky
> wrote:
> > This was a quick proof of concept to show the new API for prelocating
> > buffers.
> >
>
> What are prelocated buffers?
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066432.html
>
> Alex
>
> > It needs way more testing, to not ifdef the no-relocs, and to do a
> > libdrm ABI dep bump.
> > ---
> > src/mesa/drivers/dri/i965/Makefile.am | 1 +
> > src/mesa/drivers/dri/i965/brw_performance_monitor.c | 6 +++---
> > src/mesa/drivers/dri/i965/brw_program.c | 5 +++--
> > src/mesa/drivers/dri/i965/brw_queryobj.c| 6 +++---
> > src/mesa/drivers/dri/i965/brw_state_cache.c | 4 ++--
> > src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 +++
> > src/mesa/drivers/dri/i965/intel_batchbuffer.h | 8
> > 7 files changed, 23 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/Makefile.am
> > b/src/mesa/drivers/dri/i965/Makefile.am
> > index 5809dc6..4b20d36 100644
> > --- a/src/mesa/drivers/dri/i965/Makefile.am
> > +++ b/src/mesa/drivers/dri/i965/Makefile.am
> > @@ -24,6 +24,7 @@
> > include Makefile.sources
> >
> > AM_CFLAGS = \
> > +-DNO_RELOC \
> > -I$(top_srcdir)/include \
> > -I$(top_srcdir)/src/ \
> > -I$(top_srcdir)/src/mapi \
> > diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
> > b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
> > index edfa3d2..e30c527 100644
> > --- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
> > +++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
> > @@ -1105,13 +1105,13 @@ brw_begin_perf_monitor(struct gl_context *ctx,
> > * wasting memory for contexts that don't use performance monitors.
> > */
> >if (!brw->perfmon.bookend_bo) {
> > - brw->perfmon.bookend_bo = drm_intel_bo_alloc(brw->bufmgr,
> > + brw->perfmon.bookend_bo = drm_intel_bo_alloc_wrapper(brw->bufmgr,
> >"OA bookend BO",
> >
> > BOOKEND_BO_SIZE_BYTES, 64);
> >}
> >
> >monitor->oa_bo =
> > - drm_intel_bo_alloc(brw->bufmgr, "perf. monitor OA bo", 4096, 64);
> > + drm_intel_bo_alloc_wrapper(brw->bufmgr, "perf. monitor OA bo",
> > 4096, 64);
> > #ifdef DEBUG
> >/* Pre-filling the BO helps debug whether writes landed. */
> >drm_intel_bo_map(monitor->oa_bo, true);
> > @@ -1146,7 +1146,7 @@ brw_begin_perf_monitor(struct gl_context *ctx,
> >
> > if (monitor_needs_statistics_registers(brw, m)) {
> >monitor->pipeline_stats_bo =
> > - drm_intel_bo_alloc(brw->bufmgr, "perf. monitor stats bo", 4096,
> > 64);
> > + drm_intel_bo_alloc_wrapper(brw->bufmgr, "perf. monitor stats bo",
> > 4096, 64);
> >
> >/* Take starting snapshots. */
> >snapshot_statistics_registers(brw, monitor, 0);
> > diff --git a/src/mesa/drivers/dri/i965/brw_program.c
> > b/src/mesa/drivers/dri/i965/brw_program.c
> > index d782b4f..74ff40c 100644
> > --- a/src/mesa/drivers/dri/i965/brw_program.c
> > +++ b/src/mesa/drivers/dri/i965/brw_program.c
> > @@ -43,6 +43,7 @@
> >
> > #include "brw_context.h"
> > #include "brw_wm.h"
> > +#include "intel_batchbuffer.h"
> >
> > static unsigned
> > get_new_program_id(struct intel_screen *screen)
> > @@ -242,7 +243,7 @@ brw_get_scratch_bo(struct brw_context *brw,
> > }
> >
> > if (!old_bo) {
> > - *scratch_bo = drm_intel_bo_alloc(brw->bufmgr, "scratch bo", size,
> > 4096);
> > + *scratch_bo = drm_intel_bo_alloc_wrapper(brw->bufmgr, "scratch bo",
> > size, 4096);
> > }
> > }
> >
> > @@ -265,7 +266,7 @@ void
> > brw_init_shader_time(struct brw_context *brw)
> > {
> > const int max_entries = 4096;
> > - brw->shader_time.bo = drm_intel_bo_alloc(brw->bufmgr, "shader time",
> > + brw->shader_time.bo = drm_intel_bo_alloc_wrapper(brw->bufmgr, "shader
> > time",
> > max_entries *
> > SHADER_TIME_STRIDE,
> > 4096);
> > brw->shader_time.shader_programs = rzalloc_array(brw, struct
> > gl_shader_program *,
> > diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
> > b/src/mesa/drivers/dri/i965/brw_queryobj.c
> > index c053c34..cf5a2a5 100644
> > --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
> > +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
> > @@ -230,7 +230,7 @@ brw_begin_query(struct gl_context *ctx, struct
> > gl_query_object *q)
> > * the system was doing other work, such as running other
> > applications.
> > */
> >drm_intel_bo_unreference(query->bo);
> > - query->bo = drm_intel_bo_alloc(brw->bufmgr, "timer query", 4096,
> > 4096);
> > + query->bo = drm_intel_bo_alloc_wrapper(brw->bufmgr, "timer query",
> > 4096, 4096);
> >
[Mesa-dev] [Bug 82946] Build failure while linking libMesaOpenCL.la with any Mesa release >= 10.2: undefined references to .LLST7{1, 5, 9}
https://bugs.freedesktop.org/show_bug.cgi?id=82946 Giovanni Mariani changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #3 from Giovanni Mariani --- OK. I tried another time and indeed I can confirm that removing the "-gdwarf-4" from CXXFLAGS fixes the build with gcc 4.7.4 (perhaps the first time I did not massage CXXFLAGS correctly). Hence not a bug in Mesa: closing. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Handle ir_triop_csel in emit_bool_to_cond_code().
ir_triop_csel can return a boolean expression, so we need to handle it
here; we simply forgot when we added it.
Fixes Piglit's EXT_shader_integer_mix/{vs,fs}-mix-if-bool.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 20 ++--
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 20 ++--
2 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index f2c22bb..700115c 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2246,10 +2246,10 @@ fs_visitor::emit_bool_to_cond_code(ir_rvalue *ir)
return;
}
- fs_reg op[2];
+ fs_reg op[3];
fs_inst *inst;
- assert(expr->get_num_operands() <= 2);
+ assert(expr->get_num_operands() <= 3);
for (unsigned int i = 0; i < expr->get_num_operands(); i++) {
assert(expr->operands[i]->type->is_scalar());
@@ -2336,6 +2336,22 @@ fs_visitor::emit_bool_to_cond_code(ir_rvalue *ir)
brw_conditional_for_comparison(expr->operation)));
break;
+ case ir_triop_csel: {
+ /* Expand the boolean condition into the flag register. */
+ inst = emit(MOV(reg_null_d, op[0]));
+ inst->conditional_mod = BRW_CONDITIONAL_NZ;
+
+ /* Select which boolean to return. */
+ fs_reg temp(this, expr->operands[1]->type);
+ inst = emit(SEL(temp, op[1], op[2]));
+ inst->predicate = BRW_PREDICATE_NORMAL;
+
+ /* Expand the result to a condition code. */
+ inst = emit(MOV(reg_null_d, temp));
+ inst->conditional_mod = BRW_CONDITIONAL_NZ;
+ break;
+ }
+
default:
unreachable("not reached");
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 6e48be7..4dcedfe 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -777,10 +777,10 @@ vec4_visitor::emit_bool_to_cond_code(ir_rvalue *ir,
*predicate = BRW_PREDICATE_NORMAL;
if (expr) {
- src_reg op[2];
+ src_reg op[3];
vec4_instruction *inst;
- assert(expr->get_num_operands() <= 2);
+ assert(expr->get_num_operands() <= 3);
for (unsigned int i = 0; i < expr->get_num_operands(); i++) {
expr->operands[i]->accept(this);
op[i] = this->result;
@@ -852,6 +852,22 @@ vec4_visitor::emit_bool_to_cond_code(ir_rvalue *ir,
brw_conditional_for_comparison(expr->operation)));
break;
+ case ir_triop_csel: {
+ /* Expand the boolean condition into the flag register. */
+ inst = emit(MOV(dst_null_d(), op[0]));
+ inst->conditional_mod = BRW_CONDITIONAL_NZ;
+
+ /* Select which boolean to return. */
+ dst_reg temp(this, expr->operands[1]->type);
+ inst = emit(BRW_OPCODE_SEL, temp, op[1], op[2]);
+ inst->predicate = BRW_PREDICATE_NORMAL;
+
+ /* Expand the result to a condition code. */
+ inst = emit(MOV(dst_null_d(), src_reg(temp)));
+ inst->conditional_mod = BRW_CONDITIONAL_NZ;
+ break;
+ }
+
default:
unreachable("not reached");
}
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson wrote: > On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote: >> On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson >> wrote: >> >> > > If a GPU >> >> > > client uses only prelocations, the relocation process can be entirely >> >> > > skipped. This sounds like a big win initially, >> >> > >> >> > Close to zero if the client uses existing interfaces. >> >> > -Chris >> >> >> >> Chris, >> >> >> >> I don't know if you've seen Ben's libdrm and Mesa patches, but with a few >> >> patches to libdrm and virtually zero Mesa changes, he's apparently >> >> eliminated our need to do any relocations for the 3D driver. It wasn't >> >> invasive at all---I was surprised. >> > >> > Indeed, you could do everything inside libdrm with the code I posted 2 >> > years ago. >> >> I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need >> to walk all the reloc tables (if nothing moved) because userspace >> didn't go insane and reuse reloc trees. So you'd need to implement a >> flag + a libdrm function to set that (iirc mesa has been non-stupid >> since years). And yeah I kinda expect any new reloc-less thing to get >> benchmarked against an implementation using that, since the 48bit >> specific thing proposed looks like a fairly short-lived stop-gap, and >> since the current no-reloc we already have would work everywhere. And >> yeah I've been poking people to look at this for years. too. > > Here, I was referring to soft-pinning. The API here is essentially > comprised of two parts: > > 1: a pin into the vm upon creation > 2: implicit no-relocation upon execbuffer > > By making those two steps independent, the API as I see is, is more > flexible and powerful. Well I admit to not having read the patches over the terrible wifi here, but I presumed Ben's patches -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] mesa: Begin tracking whether a program needs re-linking.
On 05/14/2014 05:28 PM, Kenneth Graunke wrote:
> Tracking this will allow us to issue warnings when using a program that
> hasn't yet been relinked, or when re-linking unnecessarily.
>
> The following functions cause changes that don't take effect until the
> program has been re-linked:
>
> - glAttachShader
> - glBindAttribLocation
> - glBindFragDataLocation
> - glBindFragDataLocationIndexed
> - glTransformFeedbackVaryings
> - glProgramParameteri (separable/binary retrievable hint)
> - glUniformBlockBinding
And also glDetachShader, right?
> OpenGL also allows the application to recompile shaders that have been
> attached to programs and linked---at which point, they need relinking.
> That case will be handled shortly.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/main/mtypes.h| 1 +
> src/mesa/main/shader_query.cpp| 3 ++-
> src/mesa/main/shaderapi.c | 6 ++
> src/mesa/main/transformfeedback.c | 1 +
> src/mesa/main/uniforms.c | 2 ++
> 5 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 917d071..741f936 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -2744,6 +2744,7 @@ struct gl_shader_program
> struct gl_active_atomic_buffer *AtomicBuffers;
> unsigned NumAtomicBuffers;
>
> + bool NeedsRelink;
> GLboolean LinkStatus; /**< GL_LINK_STATUS */
> GLboolean Validated;
> GLboolean _Used;/**< Ever used for drawing? */
> diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
> index 36d1d9c..db3be0c 100644
> --- a/src/mesa/main/shader_query.cpp
> +++ b/src/mesa/main/shader_query.cpp
> @@ -74,6 +74,7 @@ _mesa_BindAttribLocation(GLhandleARB program, GLuint index,
> * Note that this attribute binding won't go into effect until
> * glLinkProgram is called again.
> */
> + shProg->NeedsRelink = true;
> }
>
> static bool
> @@ -365,7 +366,7 @@ _mesa_BindFragDataLocationIndexed(GLuint program, GLuint
> colorNumber,
> * Note that this binding won't go into effect until
> * glLinkProgram is called again.
> */
> -
> + shProg->NeedsRelink = true;
> }
>
> GLint GLAPIENTRY
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 28739da..59d30ff 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa/main/shaderapi.c
> @@ -284,6 +284,7 @@ attach_shader(struct gl_context *ctx, GLuint program,
> GLuint shader)
> shProg->Shaders[n] = NULL; /* since realloc() didn't zero the new space */
> _mesa_reference_shader(ctx, &shProg->Shaders[n], sh);
> shProg->NumShaders++;
> + shProg->NeedsRelink = true;
> }
>
>
> @@ -914,6 +915,9 @@ link_program(struct gl_context *ctx, GLuint program)
>
> _mesa_glsl_link_shader(ctx, shProg);
>
> + if (shProg->LinkStatus == GL_TRUE)
> + shProg->NeedsRelink = false;
> +
> if (shProg->LinkStatus == GL_FALSE &&
> (ctx->_Shader->Flags & GLSL_REPORT_ERRORS)) {
>_mesa_debug(ctx, "Error linking program %u:\n%s\n",
> @@ -1770,6 +1774,7 @@ _mesa_ProgramParameteri(GLuint program, GLenum pname,
> GLint value)
> * is loaded again a recompile can be avoided."
> */
>shProg->BinaryRetreivableHint = value;
> + shProg->NeedsRelink = true;
>return;
>
> case GL_PROGRAM_SEPARABLE:
> @@ -1785,6 +1790,7 @@ _mesa_ProgramParameteri(GLuint program, GLenum pname,
> GLint value)
> return;
>}
>shProg->SeparateShader = value;
> + shProg->NeedsRelink = true;
>return;
>
> default:
> diff --git a/src/mesa/main/transformfeedback.c
> b/src/mesa/main/transformfeedback.c
> index a737463..c037faa 100644
> --- a/src/mesa/main/transformfeedback.c
> +++ b/src/mesa/main/transformfeedback.c
> @@ -771,6 +771,7 @@ _mesa_TransformFeedbackVaryings(GLuint program, GLsizei
> count,
> /* No need to invoke FLUSH_VERTICES or flag NewTransformFeedback since
> * the varyings won't be used until shader link time.
> */
> + shProg->NeedsRelink = true;
> }
>
>
> diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
> index 1daade4..39a61f7 100644
> --- a/src/mesa/main/uniforms.c
> +++ b/src/mesa/main/uniforms.c
> @@ -1043,6 +1043,8 @@ _mesa_UniformBlockBinding(GLuint program,
> sh->UniformBlocks[stage_index].Binding = uniformBlockBinding;
>}
>}
> +
> + shProg->NeedsRelink = true;
> }
> }
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 08/18/2014 05:44 AM, Roland Scheidegger wrote:
> Am 16.08.2014 02:12, schrieb Connor Abbott:
>> I know what you might be thinking right now. "Wait, *another* IR? Don't
>> we already have like 5 of those, not counting all the driver-specific
>> ones? Isn't this stuff complicated enough already?" Well, there are some
>> pretty good reasons to start afresh (again...). In the years we've been
>> using GLSL IR, we've come to realize that, in fact, it's not what we
>> want *at all* to do optimizations on. Ian has done a talk at FOSDEM that
>> highlights some of the problems they've run into:
>>
>> https://urldefense.proofpoint.com/v1/url?u=https://video.fosdem.org/2014/H1301_Cornil/Saturday/Three_Years_Experience_with_a_Treelike_Shader_IR.webm&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=iXhCeAYmidPDc1lFo757Cc9V0PvWAN4n3X%2Fw%2B%2F7Lx%2Fs%3D%0A&s=f103fb26bf53eee64318a490517d1ee9ab88ecd29fcdbe49d54b5a27e7581c2e
>>
>> But here's the summary:
>>
>> * GLSL IR is way too much of a memory hog, since it has to make a new
>> variable for each temporary the compiler creates and then each time you
>> want to dereference that temporary you need to create an
>> ir_dereference_variable that points to it which is also very
>> cache-unfriendly ("downright cache-mean!").
>>
>> * The expression trees were originally added so that we could do
>> pattern matching to automatically optimize things, but this turned out
>> to be both very difficult to do and not very helpful. Instead, all it
>> does is add more complexity to the IR without much benefit - with SSA or
>> having proper use-def chains, we could get back what the trees give us
>> while also being able to do lots more optimizations.
>>
>> * We don't have the concept of basic blocks in GLSL IR, which makes a
>> lot of optimizations harder because they were originally designed with
>> basic blocks in mind - take, for example, my SSA series. I had to map a
>> whole lot of concepts that were based on the control flow graph to this
>> tree of statements that GLSL IR uses, and the end result wound up
>> looking nothing at all like the original paper. This problem gets even
>> worse for things like e.g. Global Code Motion that depend upon having
>> the dominance tree.
>>
>> I originally wanted to modify GLSL IR to fix these problems by adding
>> new instruction types that would address these issues and then
>> converting back and forth between the old and the new form, but I
>> realized that fixing all the problems would basically mean a complete
>> rewrite - and if that's the case, then why don't we start from scratch?
>> So I took Ken's suggestions and started designing, and then at Intel
>> over the summer started implementing, a completely new IR which I call
>> NIR that's at a lower level than GLSL IR, but still high-level enough to
>> be mostly device-independant (different drivers may have different
>> passes and different ways of lowering e.g. matrix multiplies) so that
>> we can do generic optimizations on it. Having support for SSA from the
>> beginning was also a must, because lots of optimisations that we really
>> want for cleaning up DX9-translated games are either a lot easier in or
>> made possible by SSA. I also made the decision for it to be typeless,
>> because that's what the cool kids are all doing :) and for a
>> lower-level, flat IR it seemed like the thing to do (it could have gone
>> either way, though). So the key design points of NIR (pronounced either
>> like "near" as in "NIR is near!" or to rhyme with "burr") are:
>>
>> * It's flat (no expression trees)
>>
>> * It's typeless
>>
>> * Modifiers (abs, negate, saturate), swizzles, and write masks are part
>> of ALU instructions
>>
>> * It includes enough GLSL-like things (variables that you can load from
>> or store to, function calls) to be hardware-agnostic (although we don't
>> have a way to represent matrix multiplies right now, but that could
>> easily be added) to be able to do optimizations at a high level, while
>> having lowering passes that convert variables to registers and
>> input/output/uniform loads/stores that will open up more opportunities
>> for optimization and save memory while being more hardware-specific.
>>
>> * Control flow consists of a tree of if statements and loops, like in
>> GLSL IR, except the leaves of the tree are now basic blocks instead of
>> instructions. Also, each basic block keeps track of its successors and
>> predecessors, so the control flow graph is explicit in the IR.
>>
>> * SSA is natively supported, and SSA uses point directly to the SSA
>> definition, which means that the use-def chains are always there, and
>> def-use chains are kept by tracking the set of all uses for each
>> definition.
>>
>> * It's written in C.
>>
>> (see the README in patch 3 and nir.h in patch 4 for more details)
>>
>> Some things that are missing or could be improved:
>>
>> * There's currently no alias tracking for inputs, outputs
Re: [Mesa-dev] [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson wrote: > On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote: >> On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson >> wrote: >> >> > > If a GPU >> >> > > client uses only prelocations, the relocation process can be entirely >> >> > > skipped. This sounds like a big win initially, >> >> > >> >> > Close to zero if the client uses existing interfaces. >> >> > -Chris >> >> >> >> Chris, >> >> >> >> I don't know if you've seen Ben's libdrm and Mesa patches, but with a few >> >> patches to libdrm and virtually zero Mesa changes, he's apparently >> >> eliminated our need to do any relocations for the 3D driver. It wasn't >> >> invasive at all---I was surprised. >> > >> > Indeed, you could do everything inside libdrm with the code I posted 2 >> > years ago. >> >> I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need >> to walk all the reloc tables (if nothing moved) because userspace >> didn't go insane and reuse reloc trees. So you'd need to implement a >> flag + a libdrm function to set that (iirc mesa has been non-stupid >> since years). And yeah I kinda expect any new reloc-less thing to get >> benchmarked against an implementation using that, since the 48bit >> specific thing proposed looks like a fairly short-lived stop-gap, and >> since the current no-reloc we already have would work everywhere. And >> yeah I've been poking people to look at this for years. too. > > Here, I was referring to soft-pinning. The API here is essentially > comprised of two parts: > > 1: a pin into the vm upon creation > 2: implicit no-relocation upon execbuffer > > By making those two steps independent, the API as I see is, is more > flexible and powerful. Well I admit to not having read the patches over the terrible wifi here, but I presumed Ben's patches did implement softpin. I guess I've made a mess of all of this now. In any case I still want to see relative improvements over what we have since the prelocated stuff looks like a gen8 oneshot. And we still can't do relocation-less execbuf because the gpu can't fault, so I'm not sure at all whether this is actually useful for opencl 2.0. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 08/19/2014 11:33 PM, Francisco Jerez wrote: > Connor Abbott writes: > >> On Tue, Aug 19, 2014 at 11:40 AM, Francisco Jerez >> wrote: >>> Tom Stellard writes: >>> On Tue, Aug 19, 2014 at 11:04:59AM -0400, Connor Abbott wrote: > On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer wrote: >> On 19.08.2014 01:28, Connor Abbott wrote: >>> On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer >>> wrote: On 16.08.2014 09:12, Connor Abbott wrote: > I know what you might be thinking right now. "Wait, *another* IR? > Don't > we already have like 5 of those, not counting all the driver-specific > ones? Isn't this stuff complicated enough already?" Well, there are > some > pretty good reasons to start afresh (again...). In the years we've > been > using GLSL IR, we've come to realize that, in fact, it's not what we > want *at all* to do optimizations on. Did you evaluate using LLVM IR instead of inventing yet another one? -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer >>> >>> Yes. See >>> >>> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html >>> >>> and >>> >>> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html >> >> I know Ian can't deal with LLVM for some reason. I was wondering if >> *you* evaluated it, and if so, why you rejected it. >> >> >> -- >> Earthling Michel Dänzer| http://www.amd.com >> Libre software enthusiast |Mesa and X developer > > > Well, first of all, the fact that Ian and Ken don't want to use it > means that any plan to use LLVM for the Intel driver is dead in the > water anyways - you can translate NIR into LLVM if you want, but for > i965 we want to share optimizations between our 2 backends (FS and > vec4) that we can't do today in GLSL IR so this is what we want to use > for that, and since nobody else does anything with the core GLSL > compiler except when they have to, when we start moving things out of > GLSL IR this will probably replace GLSL IR as the infrastructure that > all Mesa drivers use. But with that in mind, here are a few reasons > why we wouldn't want to use LLVM: > > * LLVM wasn't built to understand structured CFG's, meaning that you > need to re-structurize it using a pass that's fragile and prone to > break if some other pass "optimizes" the shader in a way that makes it > non-structured (i.e. not expressible in terms of loops and if > statements). This loss of information also means that passes that need > to know things like, for example, the loop nesting depth need to do an > analysis pass whereas with NIR you can just walk up the control flow > tree and count the number of loops we hit. > LLVM has a pass to structurize the CFG. We use it in the radeon drivers, and it is run after all of the other LLVM optimizations which have no concept of structured CFG. It's not bug free, but it works really well even with all of the complex OpenCL kernels we throw at it. Your point about losing information when the CFG is de-structurized is valid, but for things like loop depth, I'm not sure why we couldn't write an LLVM analysis pass for this (if one doesn't already exist). >>> >>> I don't think this is such a big deal either. At least the >>> structurization pass used on newer AMD hardware isn't "fragile" in the >>> way you seem to imply -- AFAIK (unlike the old AMDIL heuristic >>> algorithm) it's guaranteed to give you a valid structurized output no >>> matter what the previous optimization passes have done to the CFG, >>> modulo bugs. I admit that the situation is nevertheless suboptimal. >>> Ideally this information wouldn't get lost along the way. For the long >>> term we may want to represent structured control flow directly in the IR >>> as you say, I just don't see how reinventing the IR saves us any work if >>> we could just fix the existing one. >> >> It seems to me that something like how we represent control flow is a >> pretty fundamental part of the IR - it affects any optimization pass >> that needs to do anything beyond adding and removing instructions. How >> would you fix that, especially given that LLVM is primarily designed >> for CPU's where you don't want to be restricted to structured control >> flow at all? It seems like our goals (preserve the structure) conflict >> with the way LLVM has been designed. >> > I think we can fix this by introducing new structured variants of the > branch instruction in a way that doesn't alter the fundamental structure > of the IR. E.g.
[Mesa-dev] [PATCH 1/2] u_vbuf: Simplify the format fallback translation.
Individual caps made supporting new fallbacks more complicated than it
needed to be. Instead, just make a table of fallbacks at context init
time.
---
src/gallium/auxiliary/cso_cache/cso_context.c | 12 +-
src/gallium/auxiliary/util/u_vbuf.c | 178 --
src/gallium/auxiliary/util/u_vbuf.h | 11 +-
3 files changed, 84 insertions(+), 117 deletions(-)
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c
b/src/gallium/auxiliary/cso_cache/cso_context.c
index ca91b67..3d8860f 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -239,18 +239,8 @@ static void cso_init_vbuf(struct cso_context *cso)
{
struct u_vbuf_caps caps;
- u_vbuf_get_caps(cso->pipe->screen, &caps);
-
/* Install u_vbuf if there is anything unsupported. */
- if (!caps.buffer_offset_unaligned ||
- !caps.buffer_stride_unaligned ||
- !caps.velem_src_offset_unaligned ||
- !caps.format_fixed32 ||
- !caps.format_float16 ||
- !caps.format_float64 ||
- !caps.format_norm32 ||
- !caps.format_scaled32 ||
- !caps.user_vertex_buffers) {
+ if (u_vbuf_get_caps(cso->pipe->screen, &caps)) {
cso->vbuf = u_vbuf_create(cso->pipe, &caps,
cso->aux_vertex_buffer_index);
}
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
b/src/gallium/auxiliary/util/u_vbuf.c
index c475ee1..42f5915 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliary/util/u_vbuf.c
@@ -191,47 +191,87 @@ u_vbuf_create_vertex_elements(struct u_vbuf *mgr,
unsigned count,
const struct pipe_vertex_element *attribs);
static void u_vbuf_delete_vertex_elements(struct u_vbuf *mgr, void *cso);
+static const struct {
+ enum pipe_format from, to;
+} vbuf_format_fallbacks[] = {
+ { PIPE_FORMAT_R32_FIXED,PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R32G32_FIXED, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R32G32B32_FIXED, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R32G32B32A32_FIXED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R16_FLOAT,PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R16G16_FLOAT, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R16G16B16_FLOAT, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R16G16B16A16_FLOAT, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R64_FLOAT,PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R64G64_FLOAT, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R64G64B64_FLOAT, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R64G64B64A64_FLOAT, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R32_UNORM,PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R32G32_UNORM, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R32G32B32_UNORM, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R32G32B32A32_UNORM, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R32_SNORM,PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R32G32_SNORM, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R32G32B32_SNORM, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R32G32B32A32_SNORM, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R32_USCALED, PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R32G32_USCALED, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R32G32B32_USCALED,PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R32G32B32A32_USCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R32_SSCALED, PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R32G32_SSCALED, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R32G32B32_SSCALED,PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R32G32B32A32_SSCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+};
-void u_vbuf_get_caps(struct pipe_screen *screen, struct u_vbuf_caps *caps)
+boolean u_vbuf_get_caps(struct pipe_screen *screen, struct u_vbuf_caps *caps)
{
- caps->format_fixed32 =
- screen->is_format_supported(screen, PIPE_FORMAT_R32_FIXED, PIPE_BUFFER,
- 0, PIPE_BIND_VERTEX_BUFFER);
-
- caps->format_float16 =
- screen->is_format_supported(screen, PIPE_FORMAT_R16_FLOAT, PIPE_BUFFER,
- 0, PIPE_BIND_VERTEX_BUFFER);
-
- caps->format_float64 =
- screen->is_format_supported(screen, PIPE_FORMAT_R64_FLOAT, PIPE_BUFFER,
- 0, PIPE_BIND_VERTEX_BUFFER);
-
- caps->format_norm32 =
- screen->is_format_supported(screen, PIPE_FORMAT_R32_UNORM, PIPE_BUFFER,
- 0, PIPE_BIND_VERTEX_BUFFER) &&
- screen->is_format_supported(screen, PIPE_FORMAT_R32_SNORM, PIPE_BUFFER,
- 0, PIPE_BIND_VERTEX_BUFFER);
-
- caps->format_scaled32 =
- screen->is_format_supported(screen, PIPE_FORMAT_R32_USCALED, PIPE_BUFFER,
- 0, PIPE_BIND_VERTEX_BUFFER) &&
-
[Mesa-dev] [PATCH 2/2] u_vbuf: Add a few more format fallbacks.
Fixes piglit draw-vertices and gl-2.0-vertexattribpointer on vc4, where
I'm only advertising R32F to RGBA32F support so far.
Note: regresses gl-1.5-normal3b3s-invariance due to introduced flushes and
missing depth buffer load/store support in the driver.
---
src/gallium/auxiliary/util/u_vbuf.c | 32
1 file changed, 32 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
b/src/gallium/auxiliary/util/u_vbuf.c
index 42f5915..a372d69 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliary/util/u_vbuf.c
@@ -222,6 +222,38 @@ static const struct {
{ PIPE_FORMAT_R32G32_SSCALED, PIPE_FORMAT_R32G32_FLOAT },
{ PIPE_FORMAT_R32G32B32_SSCALED,PIPE_FORMAT_R32G32B32_FLOAT },
{ PIPE_FORMAT_R32G32B32A32_SSCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R16_UNORM,PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R16G16_UNORM, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R16G16B16_UNORM, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R16G16B16A16_UNORM, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R16_SNORM,PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R16G16_SNORM, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R16G16B16_SNORM, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R16G16B16A16_SNORM, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R16_USCALED, PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R16G16_USCALED, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R16G16B16_USCALED,PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R16G16B16A16_USCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R16_SSCALED, PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R16G16_SSCALED, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R16G16B16_SSCALED,PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R16G16B16A16_SSCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R8_UNORM, PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R8G8_UNORM, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R8G8B8_UNORM, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R8G8B8A8_UNORM, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R8_SNORM, PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R8G8_SNORM, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R8G8B8_SNORM, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R8G8B8A8_SNORM, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R8_USCALED, PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R8G8_USCALED, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R8G8B8_USCALED, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R8G8B8A8_USCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
+ { PIPE_FORMAT_R8_SSCALED, PIPE_FORMAT_R32_FLOAT },
+ { PIPE_FORMAT_R8G8_SSCALED, PIPE_FORMAT_R32G32_FLOAT },
+ { PIPE_FORMAT_R8G8B8_SSCALED, PIPE_FORMAT_R32G32B32_FLOAT },
+ { PIPE_FORMAT_R8G8B8A8_SSCALED, PIPE_FORMAT_R32G32B32A32_FLOAT },
};
boolean u_vbuf_get_caps(struct pipe_screen *screen, struct u_vbuf_caps *caps)
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 08/20/2014 09:11 AM, Francisco Jerez wrote: > Connor Abbott writes: > >> On Wed, Aug 20, 2014 at 7:01 AM, Francisco Jerez >> wrote: >>> Connor Abbott writes: >>> On Tue, Aug 19, 2014 at 11:33 PM, Francisco Jerez wrote: > Connor Abbott writes: > >> On Tue, Aug 19, 2014 at 11:40 AM, Francisco Jerez >> wrote: >>> Tom Stellard writes: >>> On Tue, Aug 19, 2014 at 11:04:59AM -0400, Connor Abbott wrote: > On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer > wrote: >> On 19.08.2014 01:28, Connor Abbott wrote: >>> On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer >>> wrote: On 16.08.2014 09:12, Connor Abbott wrote: > I know what you might be thinking right now. "Wait, *another* IR? > Don't > we already have like 5 of those, not counting all the > driver-specific > ones? Isn't this stuff complicated enough already?" Well, there > are some > pretty good reasons to start afresh (again...). In the years > we've been > using GLSL IR, we've come to realize that, in fact, it's not what > we > want *at all* to do optimizations on. Did you evaluate using LLVM IR instead of inventing yet another one? -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer >>> >>> Yes. See >>> >>> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html >>> >>> and >>> >>> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html >> >> I know Ian can't deal with LLVM for some reason. I was wondering if >> *you* evaluated it, and if so, why you rejected it. >> >> >> -- >> Earthling Michel Dänzer| >> http://www.amd.com >> Libre software enthusiast |Mesa and X >> developer > > > Well, first of all, the fact that Ian and Ken don't want to use it > means that any plan to use LLVM for the Intel driver is dead in the > water anyways - you can translate NIR into LLVM if you want, but for > i965 we want to share optimizations between our 2 backends (FS and > vec4) that we can't do today in GLSL IR so this is what we want to use > for that, and since nobody else does anything with the core GLSL > compiler except when they have to, when we start moving things out of > GLSL IR this will probably replace GLSL IR as the infrastructure that > all Mesa drivers use. But with that in mind, here are a few reasons > why we wouldn't want to use LLVM: > > * LLVM wasn't built to understand structured CFG's, meaning that you > need to re-structurize it using a pass that's fragile and prone to > break if some other pass "optimizes" the shader in a way that makes it > non-structured (i.e. not expressible in terms of loops and if > statements). This loss of information also means that passes that need > to know things like, for example, the loop nesting depth need to do an > analysis pass whereas with NIR you can just walk up the control flow > tree and count the number of loops we hit. > LLVM has a pass to structurize the CFG. We use it in the radeon drivers, and it is run after all of the other LLVM optimizations which have no concept of structured CFG. It's not bug free, but it works really well even with all of the complex OpenCL kernels we throw at it. Your point about losing information when the CFG is de-structurized is valid, but for things like loop depth, I'm not sure why we couldn't write an LLVM analysis pass for this (if one doesn't already exist). >>> >>> I don't think this is such a big deal either. At least the >>> structurization pass used on newer AMD hardware isn't "fragile" in the >>> way you seem to imply -- AFAIK (unlike the old AMDIL heuristic >>> algorithm) it's guaranteed to give you a valid structurized output no >>> matter what the previous optimization passes have done to the CFG, >>> modulo bugs. I admit that the situation is nevertheless suboptimal. >>> Ideally this information wouldn't get lost along the way. For the long >>> term we may want to represent structured control flow directly in the IR >>> as you say, I just don't see how reinventing the IR saves us any work if >>> we could just fix the existing one. >> >>>
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 08/20/2014 11:58 AM, Tom Stellard wrote: > On Wed, Aug 20, 2014 at 11:13:13AM -0700, Kenneth Graunke wrote: >> On Wednesday, August 20, 2014 06:41:08 PM Michel Dänzer wrote: >>> On 20.08.2014 00:04, Connor Abbott wrote: On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer wrote: > On 19.08.2014 01:28, Connor Abbott wrote: >> On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer >> wrote: >>> On 16.08.2014 09:12, Connor Abbott wrote: I know what you might be thinking right now. "Wait, *another* IR? Don't we already have like 5 of those, not counting all the driver-specific ones? Isn't this stuff complicated enough already?" Well, there are some pretty good reasons to start afresh (again...). In the years we've been using GLSL IR, we've come to realize that, in fact, it's not what we want *at all* to do optimizations on. >>> >>> Did you evaluate using LLVM IR instead of inventing yet another one? >> >> Yes. See >> >> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html >> >> and >> >> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html > > I know Ian can't deal with LLVM for some reason. I was wondering if > *you* evaluated it, and if so, why you rejected it. >>> >>> First of all, thank you for sharing more specific information than >>> 'table-flipping rage'. >>> >>> * LLVM is on a different release schedule (6 months vs. 3 months), has a different review process, etc., which means that to add support for new functionality that involves shaders, we now have to submit patches to two separate projects, and then 2 months later when we ship Mesa it turns out that nobody can actually use the new feature because it depends upon an unreleased version of LLVM that won't be released for another 3 months and then packaged by distros even later... >>> >>> This has indeed been frustrating at times, but it's better now for >>> backend changes since Tom has been making LLVM point releases. >> >> Yeah - absolutely. >> >>> As for the GLSL frontend, I agree with Tom that it shouldn't require >>> that much direct interaction with the LLVM project. >>> >>> we've already had problems where distros refused to ship newer Mesa releases because radeon depended on a version of LLVM newer than the one they were shipping, [...] >>> >>> That's news to me, can you be more specific? >>> >>> That sounds like basically a distro issue though, since different LLVM >>> versions can be installed in parallel (and the one used by default >>> doesn't have to be the newest one). And it even works if another part of >>> the same process uses a different version of LLVM. >> >> Yes, one can argue that it's a distribution issue - but it's an extremely >> painful problem for distributions. >> >> For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to >> 2014-03-22), and I was told this was because of LLVM versioning changes in >> the other drivers (primarily radeon, I believe, but probably also llvmpipe). >> >> Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed that >> in Mesa 9.2.3. But we couldn't get people to actually ship it, and had to >> field tons of bug reports from upset users for several months. >> >> Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo >> Mesa package mantainer) can probably comment more. >> >> I've also heard stories from friends of mine who use radeonsi that they >> couldn't get new GL features or compiler fixes unless they upgrade both Mesa >> /and/ LLVM, and that LLVM was usually either not released or not available >> in their distribution for a few months. >> >> Those are the sorts of things I'd like to avoid. The compiler is easily the >> most crucial part of a modern graphics stack; splitting it out into a >> separate repository and project seems like a nightmare for people who care >> about getting new drivers released and shipped in distributions in a timely >> fashion. >> >> Or, looking at it the other way: today, everything you need as an Intel or >> (AFAIK) Nouveau 3D user is nicely contained within Mesa. Our community has >> complete control over when we do those releases. New important bug fixes, >> performance improvements, or features? Ship a new Mesa, and you're done. >> That's a really nice feature I'd hate to lose. >> > > It has been a challenge to match versions of LLVM and Mesa for radeonsi, > but as Michel mention this has been made easier now that we are doing > LLVM point releases. > > However, as I mentioned before if we were using LLVM IR as a common IR > it is unlikely that there would be any new features in Mesa that would > depend on changes in LLVM. The only thing we would need to modify LLVM > for would be: > - Extending the C API > - Bug fixes for optimization passes > - Optimization pass im
[Mesa-dev] [PATCH] glsl: allow precision qualifier on sampler arrays
If a precision qualifer is allowed on type T, it should be allowed
on an array of T. Refactor the check to ensure this is the case.
---
I wanted to expand the comment to say why is_record() is in there,
but I don't understand why it is. I thought structs couldn't have
precision qualifiers.
src/glsl/ast_to_hir.cpp | 75 +++--
1 file changed, 41 insertions(+), 34 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 30b02d0..998404a 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3202,6 +3202,41 @@ validate_identifier(const char *identifier, YYLTYPE loc,
}
}
+static bool
+precision_qualifier_allowed(const glsl_type *type)
+{
+ /* Precision qualifiers apply to floating point, integer and sampler
+* types.
+*
+* Section 4.5.2 (Precision Qualifiers) of the GLSL 1.30 spec says:
+*"Any floating point or any integer declaration can have the type
+*preceded by one of these precision qualifiers [...] Literal
+*constants do not have precision qualifiers. Neither do Boolean
+*variables.
+*
+* Section 4.5 (Precision and Precision Qualifiers) of the GLSL 1.30
+* spec also says:
+*
+* "Precision qualifiers are added for code portability with OpenGL
+* ES, not for functionality. They have the same syntax as in OpenGL
+* ES."
+*
+* Section 8 (Built-In Functions) of the GLSL ES 1.00 spec says:
+*
+* "uniform lowp sampler2D sampler;
+* highp vec2 coord;
+* ...
+* lowp vec4 col = texture2D (sampler, coord);
+*// texture2D returns lowp"
+*
+* From this, we infer that GLSL 1.30 (and later) should allow precision
+* qualifiers on sampler types just like float and integer types.
+*/
+ return type->is_float()
+ || type->is_integer()
+ || type->is_record()
+ || type->is_sampler();
+}
ir_rvalue *
ast_declarator_list::hir(exec_list *instructions,
@@ -3689,41 +3724,13 @@ ast_declarator_list::hir(exec_list *instructions,
}
- /* Precision qualifiers apply to floating point, integer and sampler
- * types.
- *
- * Section 4.5.2 (Precision Qualifiers) of the GLSL 1.30 spec says:
- *"Any floating point or any integer declaration can have the type
- *preceded by one of these precision qualifiers [...] Literal
- *constants do not have precision qualifiers. Neither do Boolean
- *variables.
- *
- * Section 4.5 (Precision and Precision Qualifiers) of the GLSL 1.30
- * spec also says:
- *
- * "Precision qualifiers are added for code portability with OpenGL
- * ES, not for functionality. They have the same syntax as in OpenGL
- * ES."
- *
- * Section 8 (Built-In Functions) of the GLSL ES 1.00 spec says:
- *
- * "uniform lowp sampler2D sampler;
- * highp vec2 coord;
- * ...
- * lowp vec4 col = texture2D (sampler, coord);
- *// texture2D returns lowp"
- *
- * From this, we infer that GLSL 1.30 (and later) should allow precision
- * qualifiers on sampler types just like float and integer types.
+ /* If a precision qualifier is allowed on a type, it is allowed on
+ * an array of that type.
*/
- if (this->type->qualifier.precision != ast_precision_none
- && !var->type->is_float()
- && !var->type->is_integer()
- && !var->type->is_record()
- && !var->type->is_sampler()
- && !(var->type->is_array()
- && (var->type->fields.array->is_float()
- || var->type->fields.array->is_integer( {
+ if (!(this->type->qualifier.precision == ast_precision_none
+ || precision_qualifier_allowed(var->type)
+ || (var->type->is_array()
+ && precision_qualifier_allowed(var->type->fields.array {
_mesa_glsl_error(&loc, state,
"precision qualifiers apply only to floating point"
--
2.1.0.rc2.206.gedb03e5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: uniform sampler should occupy 1 location
I'm not sure this is correct, and I think we need a more complex fix. As Dave points out, bindless will make it even more complex. In a non-bindless, static-sampler-array-indexing world, applications assume that samplers will use zero uniform locations. The sampler information is baked into the instructions, and it isn't represented anywhere else in GPU memory. As a result, I would not be surprised to see previously working applications fail to link (due to using too many uniforms) with this change. It seems that the only time a sampler needs non-zero space is when it is part of any array samplers (or array of structures containing samplers, etc.) or is bindless. In the array cases, it is probably only necessary when the index is dynamic. I think the array splitting and structure splitting passes may make that moot. The 82921 bug seems to be an orthognal issue. There is a difference between the API visible locations assigned to a uniform and the GPU visible locations where the uniform is stored. My guess is that we're using the same accounting for both in places where we should not. On 08/21/2014 04:25 PM, Micael Dias wrote: > --- > If samplers occupy zero locations we can run into a lot of issues. See #82921. > I briefly tested this with my own code (which was previously crashing and > misbehaving) and also ran other apps and everything seems to work fine. > I'm not used to contributing code in this fashion, so please forgive me if I'm > making some mistake. Thanks. > > src/glsl/glsl_types.cpp | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp > index 66e9b13..cc05193 100644 > --- a/src/glsl/glsl_types.cpp > +++ b/src/glsl/glsl_types.cpp > @@ -691,6 +691,8 @@ glsl_type::uniform_locations() const >return size; > case GLSL_TYPE_ARRAY: >return this->length * this->fields.array->uniform_locations(); > + case GLSL_TYPE_SAMPLER: > + return 1; > default: >break; > } > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Fri, Aug 22, 2014 at 2:17 PM, Tom Stellard wrote: > On Fri, Aug 22, 2014 at 02:10:03PM -0700, Ian Romanick wrote: >> Speaking of new shader stages... how would LLVM handle the 'precise' >> keyword in tesselation shaders? I can envision ways to handle this in >> an IR that we control, but it's less obvious how we would handle it in >> LLVM or another external compiler package. >> > > What exactly does precise do? LLVM has fast-math flags you can apply to > instructions and also some global flags. Just search for precise in https://www.opengl.org/registry/specs/ARB/gpu_shader5.txt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 08/22/2014 02:17 PM, Tom Stellard wrote: > On Fri, Aug 22, 2014 at 02:10:03PM -0700, Ian Romanick wrote: >> On 08/20/2014 11:58 AM, Tom Stellard wrote: >>> On Wed, Aug 20, 2014 at 11:13:13AM -0700, Kenneth Graunke wrote: On Wednesday, August 20, 2014 06:41:08 PM Michel Dänzer wrote: > On 20.08.2014 00:04, Connor Abbott wrote: >> On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer >> wrote: >>> On 19.08.2014 01:28, Connor Abbott wrote: On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer wrote: > On 16.08.2014 09:12, Connor Abbott wrote: >> I know what you might be thinking right now. "Wait, *another* IR? >> Don't >> we already have like 5 of those, not counting all the driver-specific >> ones? Isn't this stuff complicated enough already?" Well, there are >> some >> pretty good reasons to start afresh (again...). In the years we've >> been >> using GLSL IR, we've come to realize that, in fact, it's not what we >> want *at all* to do optimizations on. > > Did you evaluate using LLVM IR instead of inventing yet another one? Yes. See http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html and http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html >>> >>> I know Ian can't deal with LLVM for some reason. I was wondering if >>> *you* evaluated it, and if so, why you rejected it. > > First of all, thank you for sharing more specific information than > 'table-flipping rage'. > > >> * LLVM is on a different release schedule (6 months vs. 3 months), has >> a different review process, etc., which means that to add support for >> new functionality that involves shaders, we now have to submit patches >> to two separate projects, and then 2 months later when we ship Mesa it >> turns out that nobody can actually use the new feature because it >> depends upon an unreleased version of LLVM that won't be released for >> another 3 months and then packaged by distros even later... > > This has indeed been frustrating at times, but it's better now for > backend changes since Tom has been making LLVM point releases. Yeah - absolutely. > As for the GLSL frontend, I agree with Tom that it shouldn't require > that much direct interaction with the LLVM project. > > >> we've already had problems where distros refused to ship newer Mesa >> releases because radeon depended on a version of LLVM newer than the >> one they were shipping, [...] > > That's news to me, can you be more specific? > > That sounds like basically a distro issue though, since different LLVM > versions can be installed in parallel (and the one used by default > doesn't have to be the newest one). And it even works if another part of > the same process uses a different version of LLVM. Yes, one can argue that it's a distribution issue - but it's an extremely painful problem for distributions. For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to 2014-03-22), and I was told this was because of LLVM versioning changes in the other drivers (primarily radeon, I believe, but probably also llvmpipe). Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed that in Mesa 9.2.3. But we couldn't get people to actually ship it, and had to field tons of bug reports from upset users for several months. Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo Mesa package mantainer) can probably comment more. I've also heard stories from friends of mine who use radeonsi that they couldn't get new GL features or compiler fixes unless they upgrade both Mesa /and/ LLVM, and that LLVM was usually either not released or not available in their distribution for a few months. Those are the sorts of things I'd like to avoid. The compiler is easily the most crucial part of a modern graphics stack; splitting it out into a separate repository and project seems like a nightmare for people who care about getting new drivers released and shipped in distributions in a timely fashion. Or, looking at it the other way: today, everything you need as an Intel or (AFAIK) Nouveau 3D user is nicely contained within Mesa. Our community has complete control over when we do those releases. New important bug fixes, performance improvements, or features? Ship a new Mesa, and you're done. That's a really nice feature I'd hate to lose. >>> >>> It has been a challenge to match versions of LLVM and Mesa for radeonsi, >>> but as Michel mention this has been made easier now that we are doing >>> LLVM p
Re: [Mesa-dev] [PATCH] glcpp: Don't use alternation in the lookahead for empty pragmas.
Kenneth Graunke writes:
> Erm. Shouldn't there be a star here? ^^^
Yikes! I don't know which is more embarrassing. The regression that I
committed that showed I didn't take enough care in running piglit, or
this patch which I submitted to fix it which showed I took even less
care in compiling!
> I can't imagine this compiles...or worse, it does, and continues the comment
> to the */ in the rule below...
>
>> +pragma{HSPACE}*/[\r\n] {
>> BEGIN INITIAL;
>> }
That would have been really bad. It looks like the extended comment
could have formed a legal rule.
Fortunately, the patch as sent didn't compile at all. I had actually
compiled this patch earlier and run piglit. I must have introduced the
bug after that, but before sending the patch off.
> With that fixed, and piglit tested, this would get my Reviewed-by.
Thanks. I fixed this, added your Reviewed-by and a CC to stable, and
pushed this out.
-Carl
PS. Oddly, in a complete run of piglit, I saw that piglit's
17000-consecutive-chars-identifier test was fixed by my patch, but that
the 16385-consecutive-chars.frag test was passing before the patch, (but
that's the test that was originally cited in the bugzilla report).
--
carl.d.wo...@intel.com
pgp4DhzPOQbsz.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V4 1/3] mesa: implement GL_MAX_VERTEX_ATTRIB_STRIDE
Patches 1 and 3 are
Reviewed-by: Ian Romanick
On 08/20/2014 01:14 AM, Timothy Arceri wrote:
> V2: moved test for the VertexAttrib*Pointer() functions
> to update_array(), and made constant available for drivers to set
>
> Signed-off-by: Timothy Arceri
> ---
> Although 4.4 is a while away GL_MAX_VERTEX_ATTRIB_STRIDE is used in
> the ARB_direct_state_access spec so it seemed worth while adding this now.
>
> I've added MAX_VERTEX_ATTRIB_STRIDE to ARB_vertex_attrib_binding.xml
> as it didn't seem like it was worth putting it somewhere on its own
> as its really just a bug fix. Let me know if this should be moved.
>
> Finally I've assumed that 2048 is an ok value for i965.
>
> V4: add cap for all gallium drivers set to default (except r600g)
>
> V3: adds values for r600g and radeonsi (I'm unsable to test either of these
> patches)
>
> src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml | 1 +
> src/mesa/main/context.c | 3 +++
> src/mesa/main/get_hash_params.py | 3 +++
> src/mesa/main/mtypes.h | 3 +++
> src/mesa/main/varray.c | 22 ++
> 5 files changed, 32 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml
> b/src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml
> index 0ee6a3c..7e62688 100644
> --- a/src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml
> +++ b/src/mapi/glapi/gen/ARB_vertex_attrib_binding.xml
> @@ -53,6 +53,7 @@
>
>
>
> +
>
>
>
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index 2320842..fbdbd68 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -670,6 +670,9 @@ _mesa_init_constants(struct gl_constants *consts, gl_api
> api)
>? GL_CONTEXT_CORE_PROFILE_BIT
>: GL_CONTEXT_COMPATIBILITY_PROFILE_BIT;
>
> + /* GL 4.4 */
> + consts->MaxVertexAttribStride = 2048;
> +
> /** GL_EXT_gpu_shader4 */
> consts->MinProgramTexelOffset = -8;
> consts->MaxProgramTexelOffset = 7;
> diff --git a/src/mesa/main/get_hash_params.py
> b/src/mesa/main/get_hash_params.py
> index ff85820..aace8a5 100644
> --- a/src/mesa/main/get_hash_params.py
> +++ b/src/mesa/main/get_hash_params.py
> @@ -712,6 +712,9 @@ descriptor=[
>[ "MAX_GEOMETRY_INPUT_COMPONENTS",
> "CONTEXT_INT(Const.Program[MESA_SHADER_GEOMETRY].MaxInputComponents),
> extra_version_32" ],
>[ "MAX_GEOMETRY_OUTPUT_COMPONENTS",
> "CONTEXT_INT(Const.Program[MESA_SHADER_GEOMETRY].MaxOutputComponents),
> extra_version_32" ],
>
> +# GL 4.4
> + [ "MAX_VERTEX_ATTRIB_STRIDE", "CONTEXT_ENUM(Const.MaxVertexAttribStride),
> NO_EXTRA" ],
> +
> # GL_ARB_robustness
>[ "RESET_NOTIFICATION_STRATEGY_ARB", "CONTEXT_ENUM(Const.ResetStrategy),
> NO_EXTRA" ],
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index cb2a4df..adb6788 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3414,6 +3414,9 @@ struct gl_constants
> /** OpenGL version 3.2 */
> GLbitfield ProfileMask; /**< Mask of CONTEXT_x_PROFILE_BIT */
>
> + /** OpenGL version 4.4 */
> + GLuint MaxVertexAttribStride;
> +
> /** GL_EXT_transform_feedback */
> GLuint MaxTransformFeedbackBuffers;
> GLuint MaxTransformFeedbackSeparateComponents;
> diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
> index 5d3cc2a..7d169f9 100644
> --- a/src/mesa/main/varray.c
> +++ b/src/mesa/main/varray.c
> @@ -424,6 +424,13 @@ update_array(struct gl_context *ctx,
>return;
> }
>
> + if (ctx->API == API_OPENGL_CORE && ctx->Version >= 44 &&
> + stride > ctx->Const.MaxVertexAttribStride) {
> + _mesa_error(ctx, GL_INVALID_VALUE, "%s(stride=%d > "
> + "GL_MAX_VERTEX_ATTRIB_STRIDE)", func, stride);
> + return;
> + }
> +
> /* Page 29 (page 44 of the PDF) of the OpenGL 3.3 spec says:
> *
> * "An INVALID_OPERATION error is generated under any of the following
> @@ -1437,6 +1444,13 @@ _mesa_BindVertexBuffer(GLuint bindingIndex, GLuint
> buffer, GLintptr offset,
>return;
> }
>
> + if (ctx->API == API_OPENGL_CORE && ctx->Version >= 44 &&
> + stride > ctx->Const.MaxVertexAttribStride) {
> + _mesa_error(ctx, GL_INVALID_VALUE, "glBindVertexBuffer(stride=%d > "
> + "GL_MAX_VERTEX_ATTRIB_STRIDE)", stride);
> + return;
> + }
> +
> if (buffer ==
> vao->VertexBinding[VERT_ATTRIB_GENERIC(bindingIndex)].BufferObj->Name) {
>vbo = vao->VertexBinding[VERT_ATTRIB_GENERIC(bindingIndex)].BufferObj;
> } else if (buffer != 0) {
> @@ -1565,6 +1579,14 @@ _mesa_BindVertexBuffers(GLuint first, GLsizei count,
> const GLuint *buffers,
> continue;
>}
>
> + if (ctx->API == API_OPENGL_CORE && ctx->Version >= 44 &&
> + strides[i] > ctx->Const.MaxVertexAttribStride) {
> + _mesa_error(ctx, GL_INVALID_VALUE,
> +
Re: [Mesa-dev] [PATCH 04/17] glsl: Add a pass to lower ir_unop_saturate to clamp(x, 0, 1)
On 08/18/2014 05:17 AM, Abdiel Janulgue wrote:
> Signed-off-by: Abdiel Janulgue
> ---
> src/glsl/ir_optimization.h | 1 +
> src/glsl/lower_instructions.cpp | 29 +
> 2 files changed, 30 insertions(+)
>
> diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
> index b83c225..1c6f72b 100644
> --- a/src/glsl/ir_optimization.h
> +++ b/src/glsl/ir_optimization.h
> @@ -40,6 +40,7 @@
> #define LDEXP_TO_ARITH 0x100
> #define CARRY_TO_ARITH 0x200
> #define BORROW_TO_ARITH0x400
> +#define SAT_TO_CLAMP 0x800
>
> /**
> * \see class lower_packing_builtins_visitor
> diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp
> index 176070c..6842853 100644
> --- a/src/glsl/lower_instructions.cpp
> +++ b/src/glsl/lower_instructions.cpp
> @@ -41,6 +41,7 @@
> * - BITFIELD_INSERT_TO_BFM_BFI
> * - CARRY_TO_ARITH
> * - BORROW_TO_ARITH
> + * - SAT_TO_CLAMP
> *
> * SUB_TO_ADD_NEG:
> * ---
> @@ -104,6 +105,10 @@
> *
> * Converts ir_borrow into (x < y).
> *
> + * SAT_TO_CLAMP:
> + * -
> + * Converts ir_unop_saturate into min(max(x, 0.0), 1.0)
> + *
> */
>
> #include "main/core.h" /* for M_LOG2E */
> @@ -139,6 +144,7 @@ private:
> void ldexp_to_arith(ir_expression *);
> void carry_to_arith(ir_expression *);
> void borrow_to_arith(ir_expression *);
> + void sat_to_clamp(ir_expression *);
> };
>
> } /* anonymous namespace */
> @@ -484,6 +490,24 @@
> lower_instructions_visitor::borrow_to_arith(ir_expression *ir)
> this->progress = true;
> }
>
> +void
> +lower_instructions_visitor::sat_to_clamp(ir_expression *ir)
> +{
> + /* Translates
> +* ir_unop_saturate x
> +* into
> +* ir_binop_min (ir_binop_max(x, 0.0), 1.0)
> +*/
I infer from this code that ir_unop_sat can only operate on
floating-point values. If this is the case, you should also add checks
to ir_validate for this condition.
> +
> + ir->operation = ir_binop_min;
> + ir->operands[0] = new(ir) ir_expression(ir_binop_max,
> ir->operands[0]->type,
> + ir->operands[0],
> + new(ir) ir_constant(0.0f));
> + ir->operands[1] = new(ir) ir_constant(1.0f);
> +
> + this->progress = true;
> +}
> +
> ir_visitor_status
> lower_instructions_visitor::visit_leave(ir_expression *ir)
> {
> @@ -540,6 +564,11 @@ lower_instructions_visitor::visit_leave(ir_expression
> *ir)
> borrow_to_arith(ir);
>break;
>
> + case ir_unop_saturate:
> + if (lowering(SAT_TO_CLAMP))
> + sat_to_clamp(ir);
> + break;
> +
> default:
>return visit_continue;
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Clamp/saturate optimizations v3
Patches 2, 3, 4, 5, 6, 9, 10, 11, 12, 15, and 17 are Reviewed-by: Ian Romanick (Additional question below.) On 08/18/2014 05:17 AM, Abdiel Janulgue wrote: > v3 of clamp and saturate optimizations > > Changes since v1: > - Only remove the old try_emit_saturate operations after the new > optimizations are >in place. (Matt, Ian) > - Output [min/max](saturate(x),b) instead of saturate([min/max](x,b)) as > suggested >by Ilia Mirkin. > - The change above required some refactoring in the fs/vec4 backend to allow >propagation of certain instructions with saturate flag to SEL. For other > instructions, >we don't propagate saturate instructions, similar to the previous > behaviour. > Since v2: > - Fix comments to reflect we are doing a commutative operation, add missing > conditions >when optimizing clamp in opt_algebraic pass. > - Refactor try_emit_saturate() in i965/fs instead of completely removing it. > This fixed a >a regression where the changes emitted an (extra) unnecessary saturated > mov when the >expression generating src can do saturate directly instead. > - Fix regression in the i965/vec4 copy-propagate optimization caused by > ignoring >channels in the propagated instruction. > - Count generated loops from the fs/vec4 generator. > > Results from our shader-db: > > total instructions in shared programs: 4538627 -> 4560104 (0.47%) > instructions in affected programs: 45144 -> 66621 (47.57%) > total loops in shared programs:887 -> 711 (-19.84%) > GAINED:0 > LOST: 36 Can we try benchmarking the applications that have shaders that lost SIMD16 before pushing these changes? I'd hate to have an "optimization" that actually makes performance worse. :( > I modified shader-db a bit to catch loops unrolls. The shaders that show > increase in > instruction count are all due to the loop unroll pass triggered by this > optimization > on games that contain looped clamp/saturate operation. The unroll pass also > resulted in a few shaders with looped clamp/sat skipping SIMD16 generation. > > ** No piglit regressions observed ** > > Abdiel Janulgue (17): > i965/vec4/fs: Count loops in shader debug > glsl: Add ir_unop_saturate > glsl: Add constant evaluation of ir_unop_saturate > glsl: Add a pass to lower ir_unop_saturate to clamp(x, 0, 1) > ir_to_mesa, glsl_to_tgsi: lower ir_unop_saturate > ir_to_mesa, glsl_to_tgsi: Add support for ir_unop_saturate > i965/fs: Add support for ir_unop_saturate > i965/vec4: Add support for ir_unop_saturate > glsl: Implement saturate as ir_unop_saturate > glsl: Optimize clamp(x, 0, 1) as saturate(x) > glsl: Optimize clamp(x, 0.0, b), where b < 1.0 as min(saturate(x),b) > glsl: Optimize clamp(x, b, 1.0), where b > 0.0 as max(saturate(x),b) > i965/fs: Allow propagation of instructions with saturate flag to sel > i965/vec4: Allow propagation of instructions with saturate flag to sel > ir_to_mesa, glsl_to_tgsi: Remove try_emit_saturate > i965/fs: Refactor try_emit_saturate > i965/vec4: Remove try_emit_saturate > > src/glsl/ir.cpp | 2 + > src/glsl/ir.h| 1 + > src/glsl/ir_builder.cpp | 6 +- > src/glsl/ir_constant_expression.cpp | 6 ++ > src/glsl/ir_optimization.h | 1 + > src/glsl/ir_validate.cpp | 1 + > src/glsl/lower_instructions.cpp | 29 > src/glsl/opt_algebraic.cpp | 98 > ++ > src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp | 1 + > src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp| 18 - > src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 6 +- > src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 27 --- > src/mesa/drivers/dri/i965/brw_vec4.h | 2 +- > src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 85 > +++--- > src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 6 +- > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 25 ++- > src/mesa/program/ir_to_mesa.cpp | 59 > +++- > src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 63 > +++-- > 18 files changed, 261 insertions(+), 175 deletions(-) > > ___ > 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 01/11] glapi: add ARB_gpu_shader_fp64
Either this patch or a patch right after it should add the
ProgramUniformd and ProgramUniformMatrix*d functions in
ARB_separate_shader_objects. These are already in
ARB_separate_shader_objects.xml, but they're all commented out.
On 08/14/2014 03:52 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Just add the xml file covering this extension,
> and dummy interface files in mesa, and fix up
> sanity tests.
>
> Signed-off-by: Dave Airlie
> ---
> src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml | 143
> +
> src/mapi/glapi/gen/Makefile.am | 1 +
> src/mapi/glapi/gen/gl_API.xml | 2 +
> src/mesa/main/tests/dispatch_sanity.cpp| 36
> src/mesa/main/uniforms.c | 95 +++
> src/mesa/main/uniforms.h | 43 +
> 6 files changed, 302 insertions(+), 18 deletions(-)
> create mode 100644 src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml
>
> diff --git a/src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml
> b/src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml
> new file mode 100644
> index 000..4f860ef
> --- /dev/null
> +++ b/src/mapi/glapi/gen/ARB_gpu_shader_fp64.xml
> @@ -0,0 +1,143 @@
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index 645def4..9471986 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++ b/src/mapi/glapi/gen/Makefile.am
> @@ -131,6 +131,7 @@ API_XML = \
> ARB_framebuffer_object.xml \
> ARB_geometry_shader4.xml \
> ARB_get_program_binary.xml \
> + ARB_gpu_shader_fp64.xml \
> ARB_gpu_shader5.xml \
> ARB_instanced_arrays.xml \
> ARB_internalformat_query.xml \
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index 619717d..235b894 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -8213,6 +8213,8 @@
>
> xmlns:xi="http://www.w3.org/2001/XInclude"/>
>
> + xmlns:xi="http://www.w3.org/2001/XInclude"/>
> +
>
>
>
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 04fa86b..12fc0de 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -669,24 +669,24 @@ const struct function gl_core_functions_possible[] = {
> { "glVertexAttribP4uiv", 43, -1 },
> { "glDrawArraysIndirect", 43, -1 },
> { "glDrawElementsIndirect", 43, -1 },
> -// { "glUniform1d", 43, -1 }, // XXX: Add to xml
> -// { "glUniform2d", 43, -1 }, // XXX: Add to xml
> -// { "glUniform3d", 43, -1 }, // XXX: Add to xml
> -// { "glUniform4d", 43, -1 }, // XXX: Add to xml
> -// { "glUniform1dv", 43, -1 }, // XXX: Add to xml
> -// { "glUniform2dv", 43, -1 }, // XXX: Add to xml
> -// { "glUniform3dv", 43, -1 }, // XXX: Add to xml
> -// { "glUniform4dv", 43, -1 }, // XXX: Add to xml
> -// { "glUniformMatrix2dv", 43, -1 },// XXX: Add to xml
> -// { "glUniformMatrix3dv", 43, -1 },// XXX: Add to xml
> -// { "glUniformMatrix4dv", 43, -1 },// XXX: Add to xml
> -// { "glUniformMatrix2x3dv", 43, -1 }, // XXX: Add to xml
> -// { "glUniformMatrix2x4dv", 43, -1 }, // XXX: Add to xml
> -// { "glUniformMatrix3x2dv", 43, -1 }, // XXX: Add to xml
> -// { "glUniformMatrix3x4dv", 43, -1 }, // XXX: Add to xml
> -// { "glUniformMatrix4x2dv", 43, -1 }, // XXX: Add to xml
> -// { "glUniformMatrix4x
Re: [Mesa-dev] [PATCH 03/11] mesa: add mesa_type_is_double helper function
On 08/14/2014 03:52 AM, Dave Airlie wrote:
> This is a helper to return if a type is based on a double.
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/program/prog_parameter.h | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/src/mesa/program/prog_parameter.h
> b/src/mesa/program/prog_parameter.h
> index 6b3b3c2..9ee0f5e 100644
> --- a/src/mesa/program/prog_parameter.h
> +++ b/src/mesa/program/prog_parameter.h
> @@ -151,6 +151,28 @@ _mesa_lookup_parameter_constant(const struct
> gl_program_parameter_list *list,
> const gl_constant_value v[], GLuint vSize,
> GLint *posOut, GLuint *swizzleOut);
>
> +static INLINE GLboolean mesa_type_is_double(int dataType)
s/GLboolean/bool/ and
Reviewed-by: Ian Romanick
> +{
> + switch (dataType) {
> + case GL_DOUBLE:
> + case GL_DOUBLE_VEC2:
> + case GL_DOUBLE_VEC3:
> + case GL_DOUBLE_VEC4:
> + case GL_DOUBLE_MAT2:
> + case GL_DOUBLE_MAT2x3:
> + case GL_DOUBLE_MAT2x4:
> + case GL_DOUBLE_MAT3:
> + case GL_DOUBLE_MAT3x2:
> + case GL_DOUBLE_MAT3x4:
> + case GL_DOUBLE_MAT4:
> + case GL_DOUBLE_MAT4x2:
> + case GL_DOUBLE_MAT4x3:
> + return GL_TRUE;
> + default:
> + return GL_FALSE;
> + }
> +}
> +
> #ifdef __cplusplus
> }
> #endif
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/11] glsl: add ARB_gpu_shader_fp64 to the glsl extensions.
This patch is
Reviewed-by: Ian Romanick
On 08/14/2014 03:52 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
> ---
> src/glsl/glsl_parser_extras.cpp | 1 +
> src/glsl/glsl_parser_extras.h | 2 ++
> src/glsl/standalone_scaffolding.cpp | 1 +
> 3 files changed, 4 insertions(+)
>
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index ad91c46..53fbb25 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -521,6 +521,7 @@ static const _mesa_glsl_extension
> _mesa_glsl_supported_extensions[] = {
> EXT(ARB_fragment_coord_conventions, true, false,
> ARB_fragment_coord_conventions),
> EXT(ARB_fragment_layer_viewport,true, false,
> ARB_fragment_layer_viewport),
> EXT(ARB_gpu_shader5,true, false, ARB_gpu_shader5),
> + EXT(ARB_gpu_shader_fp64,true, false,
> ARB_gpu_shader_fp64),
> EXT(ARB_sample_shading, true, false, ARB_sample_shading),
> EXT(ARB_separate_shader_objects,true, false, dummy_true),
> EXT(ARB_shader_atomic_counters, true, false,
> ARB_shader_atomic_counters),
> diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
> index ce66e2f..6f5c0b1 100644
> --- a/src/glsl/glsl_parser_extras.h
> +++ b/src/glsl/glsl_parser_extras.h
> @@ -407,6 +407,8 @@ struct _mesa_glsl_parse_state {
> bool ARB_fragment_layer_viewport_warn;
> bool ARB_gpu_shader5_enable;
> bool ARB_gpu_shader5_warn;
> + bool ARB_gpu_shader_fp64_enable;
> + bool ARB_gpu_shader_fp64_warn;
> bool ARB_sample_shading_enable;
> bool ARB_sample_shading_warn;
> bool ARB_separate_shader_objects_enable;
> diff --git a/src/glsl/standalone_scaffolding.cpp
> b/src/glsl/standalone_scaffolding.cpp
> index 2b76dd1..63e3cde 100644
> --- a/src/glsl/standalone_scaffolding.cpp
> +++ b/src/glsl/standalone_scaffolding.cpp
> @@ -100,6 +100,7 @@ void initialize_context_to_defaults(struct gl_context
> *ctx, gl_api api)
> ctx->Extensions.ARB_fragment_coord_conventions = true;
> ctx->Extensions.ARB_fragment_layer_viewport = true;
> ctx->Extensions.ARB_gpu_shader5 = true;
> + ctx->Extensions.ARB_gpu_shader_fp64 = true;
> ctx->Extensions.ARB_sample_shading = true;
> ctx->Extensions.ARB_shader_bit_encoding = true;
> ctx->Extensions.ARB_shader_stencil_export = true;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] auxilary/os: Add Solaris support in os_get_total_physical_memory.
The patch fixes the build on Oracle Solaris.
CC os/os_misc.lo
"os/os_misc.c", line 59: #error: unexpected platform in os_sysinfo.c
Signed-off-by: Vinson Lee
---
src/gallium/auxiliary/os/os_misc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/os/os_misc.c
b/src/gallium/auxiliary/os/os_misc.c
index ef84c79..4c5a22d 100644
--- a/src/gallium/auxiliary/os/os_misc.c
+++ b/src/gallium/auxiliary/os/os_misc.c
@@ -47,7 +47,7 @@
#endif
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) ||
defined(PIPE_OS_SOLARIS)
# include
#elif defined(PIPE_OS_APPLE) || defined(PIPE_OS_BSD)
# include
@@ -111,7 +111,7 @@ os_get_option(const char *name)
bool
os_get_total_physical_memory(uint64_t *size)
{
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) ||
defined(PIPE_OS_SOLARIS)
const long phys_pages = sysconf(_SC_PHYS_PAGES);
const long page_size = sysconf(_SC_PAGE_SIZE);
--
1.7.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/11] glsl: add double support
There is a handful of minor comments below.
There is one additional thing missing: handling doubles in UBOs. Many
places in the linker (a bunch of which I just changed) assume, for
alignment purposes, that every basic type is 4-bytes. Several places in
the std140 packing rules say things like "...rounded up to the base
alignment of a vec4." In most of those places we just set the alignment
to 16 because it will be. :) With dvec4, the alignment could be 32 instead.
I think we can punt on that for a little bit. I'm putting together a
random UBO test generator that should hit "all" the cases. I hope to
have that out on the piglit list next week.
On 08/14/2014 03:52 AM, Dave Airlie wrote:
> This adds the guts of the fp64 implementation to the GLSL compiler.
>
> - builtin double types
> - double constant support
> - lexer parsing for double types (lf, LF)
> - enforcing flat on double fs inputs
> - double operations (d2f,f2d, pack/unpack, frexp - in 2 parts)
> - ir builder bits.
> - double constant expression handling
>
> Signed-off-by: Dave Airlie
> ---
> src/glsl/ast.h | 2 +
> src/glsl/ast_function.cpp | 36 ++
> src/glsl/ast_to_hir.cpp| 28 -
> src/glsl/builtin_type_macros.h | 16 +++
> src/glsl/builtin_types.cpp | 30 +
> src/glsl/glsl_lexer.ll | 42 ++-
> src/glsl/glsl_parser.yy| 33 +-
> src/glsl/glsl_parser_extras.cpp| 4 +
> src/glsl/glsl_types.cpp| 74 ++--
> src/glsl/glsl_types.h | 18 ++-
> src/glsl/ir.cpp| 90 +-
> src/glsl/ir.h | 17 +++
> src/glsl/ir_builder.cpp| 11 ++
> src/glsl/ir_builder.h | 3 +
> src/glsl/ir_clone.cpp | 1 +
> src/glsl/ir_constant_expression.cpp| 207
> -
> src/glsl/ir_print_visitor.cpp | 11 ++
> src/glsl/ir_set_program_inouts.cpp | 24 +++-
> src/glsl/ir_validate.cpp | 45 ++-
> src/glsl/link_uniform_initializers.cpp | 4 +
> src/glsl/link_uniforms.cpp | 2 +
> src/glsl/link_varyings.cpp | 3 +-
> src/mesa/program/ir_to_mesa.cpp| 6 +
> 23 files changed, 641 insertions(+), 66 deletions(-)
>
> diff --git a/src/glsl/ast.h b/src/glsl/ast.h
> index 15bf086..99274ed 100644
> --- a/src/glsl/ast.h
> +++ b/src/glsl/ast.h
> @@ -189,6 +189,7 @@ enum ast_operators {
> ast_uint_constant,
> ast_float_constant,
> ast_bool_constant,
> + ast_double_constant,
>
> ast_sequence,
> ast_aggregate
> @@ -236,6 +237,7 @@ public:
>float float_constant;
>unsigned uint_constant;
>int bool_constant;
> + double double_constant;
> } primary_expression;
>
>
> diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
> index 39c7bee..6169ae6 100644
> --- a/src/glsl/ast_function.cpp
> +++ b/src/glsl/ast_function.cpp
> @@ -570,6 +570,10 @@ convert_component(ir_rvalue *src, const glsl_type
> *desired_type)
>result = new(ctx) ir_expression(ir_unop_i2u,
> new(ctx) ir_expression(ir_unop_b2i, src));
>break;
> + case GLSL_TYPE_DOUBLE:
> + result = new(ctx) ir_expression(ir_unop_f2u,
> + new(ctx) ir_expression(ir_unop_d2f, src));
> + break;
>}
>break;
> case GLSL_TYPE_INT:
> @@ -583,6 +587,10 @@ convert_component(ir_rvalue *src, const glsl_type
> *desired_type)
>case GLSL_TYPE_BOOL:
>result = new(ctx) ir_expression(ir_unop_b2i, src);
>break;
> + case GLSL_TYPE_DOUBLE:
> + result = new(ctx) ir_expression(ir_unop_f2i,
> + new(ctx) ir_expression(ir_unop_d2f, src));
Don't we just want an ir_unop_d2i? There are values that can be exactly
represented in a double and a 32-bit integer that cannot be represented
in a float... right?
> + break;
>}
>break;
> case GLSL_TYPE_FLOAT:
> @@ -596,6 +604,9 @@ convert_component(ir_rvalue *src, const glsl_type
> *desired_type)
>case GLSL_TYPE_BOOL:
>result = new(ctx) ir_expression(ir_unop_b2f, desired_type, src, NULL);
>break;
> + case GLSL_TYPE_DOUBLE:
> + result = new(ctx) ir_expression(ir_unop_d2f, desired_type, src, NULL);
> + break;
>}
>break;
> case GLSL_TYPE_BOOL:
> @@ -610,8 +621,30 @@ convert_component(ir_rvalue *src, const glsl_type
> *desired_type)
>case GLSL_TYPE_FLOAT:
>result = new(ctx) ir_expression(ir_unop_f2b, desired_type, src, NULL);
>break;
> + case GLSL_TYPE_DOUBLE:
> + result = new(ctx) ir_expression(ir_unop_f2b,
> + new(ctx) ir_expression(ir_unop_d2f, src));
> + break;
>}
>break;
> + case GLSL_TYPE_DOUBLE:
> + switch (b) {
> + case GLSL_TYPE_INT:
> + result =
Re: [Mesa-dev] [PATCH] auxilary/os: Add Solaris support in os_get_total_physical_memory.
On 23/08/14 01:28, Vinson Lee wrote:
> The patch fixes the build on Oracle Solaris.
>
> CC os/os_misc.lo
> "os/os_misc.c", line 59: #error: unexpected platform in os_sysinfo.c
>
Does mesa even run on Solaris or is this just to silence the buildbot ?
FWIW Reviewed-by: Emil Velikov
> Signed-off-by: Vinson Lee
> ---
> src/gallium/auxiliary/os/os_misc.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/os/os_misc.c
> b/src/gallium/auxiliary/os/os_misc.c
> index ef84c79..4c5a22d 100644
> --- a/src/gallium/auxiliary/os/os_misc.c
> +++ b/src/gallium/auxiliary/os/os_misc.c
> @@ -47,7 +47,7 @@
> #endif
>
>
> -#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
> +#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) ||
> defined(PIPE_OS_SOLARIS)
> # include
> #elif defined(PIPE_OS_APPLE) || defined(PIPE_OS_BSD)
> # include
> @@ -111,7 +111,7 @@ os_get_option(const char *name)
> bool
> os_get_total_physical_memory(uint64_t *size)
> {
> -#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
> +#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) ||
> defined(PIPE_OS_SOLARIS)
> const long phys_pages = sysconf(_SC_PHYS_PAGES);
> const long page_size = sysconf(_SC_PAGE_SIZE);
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/11] mesa: add double uniform support.
It's hard to tell from just the patch whether this restriction is
enforced:
(15) Can the 64-bit uniform APIs be used to load values for uniforms of
type "bool", "bvec2", "bvec3", or "bvec4"?
RESOLVED: No. OpenGL 2.0 and beyond did allow "bool" variable to be
set with Uniform*i* and Uniform*f APIs, and OpenGL 3.0 extended that
support to Uniform*ui* for orthogonality. But it seems pointless to
extended this capability forward to 64-bit Uniform APIs as well.
On 08/14/2014 03:52 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds support for the new uniform interfaces
> from ARB_gpu_shader_fp64.
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/main/uniform_query.cpp | 50 +
> src/mesa/main/uniforms.c | 91
> +++
> src/mesa/main/uniforms.h | 3 +-
> src/mesa/program/ir_to_mesa.cpp | 17 +++-
> src/mesa/program/prog_parameter.c | 16 ---
> 5 files changed, 143 insertions(+), 34 deletions(-)
>
> diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
> index 7e630e6..d7024cb 100644
> --- a/src/mesa/main/uniform_query.cpp
> +++ b/src/mesa/main/uniform_query.cpp
> @@ -449,6 +449,9 @@ log_uniform(const void *values, enum glsl_base_type
> basicType,
>case GLSL_TYPE_FLOAT:
>printf("%g ", v[i].f);
>break;
> + case GLSL_TYPE_DOUBLE:
> + printf("%g ", *(double* )&v[i * 2].f);
> + break;
>default:
>assert(!"Should not get here.");
>break;
> @@ -509,11 +512,11 @@ _mesa_propagate_uniforms_to_driver_storage(struct
> gl_uniform_storage *uni,
> */
> const unsigned components = MAX2(1, uni->type->vector_elements);
> const unsigned vectors = MAX2(1, uni->type->matrix_columns);
> -
> + const int dmul = uni->type->base_type == GLSL_TYPE_DOUBLE ? 2 : 1;
> /* Store the data in the driver's requested type in the driver's storage
> * areas.
> */
> - unsigned src_vector_byte_stride = components * 4;
> + unsigned src_vector_byte_stride = components * 4 * dmul;
>
> for (i = 0; i < uni->num_driver_storage; i++) {
>struct gl_uniform_driver_storage *const store =
> &uni->driver_storage[i];
> @@ -612,6 +615,7 @@ _mesa_uniform(struct gl_context *ctx, struct
> gl_shader_program *shProg,
> unsigned components;
> unsigned src_components;
> enum glsl_base_type basicType;
> + int size_mul = 1;
>
> struct gl_uniform_storage *const uni =
>validate_uniform_parameters(ctx, shProg, location, count,
> @@ -670,6 +674,26 @@ _mesa_uniform(struct gl_context *ctx, struct
> gl_shader_program *shProg,
>basicType = GLSL_TYPE_INT;
>src_components = 4;
>break;
> + case GL_DOUBLE:
> + basicType = GLSL_TYPE_DOUBLE;
> + src_components = 1;
> + size_mul = 2;
> + break;
> + case GL_DOUBLE_VEC2:
> + basicType = GLSL_TYPE_DOUBLE;
> + src_components = 2;
> + size_mul = 2;
> + break;
> + case GL_DOUBLE_VEC3:
> + basicType = GLSL_TYPE_DOUBLE;
> + src_components = 3;
> + size_mul = 2;
> + break;
> + case GL_DOUBLE_VEC4:
> + basicType = GLSL_TYPE_DOUBLE;
> + src_components = 4;
> + size_mul = 2;
> + break;
> case GL_BOOL:
> case GL_BOOL_VEC2:
> case GL_BOOL_VEC3:
> @@ -683,6 +707,15 @@ _mesa_uniform(struct gl_context *ctx, struct
> gl_shader_program *shProg,
> case GL_FLOAT_MAT4x2:
> case GL_FLOAT_MAT4x3:
> case GL_FLOAT_MAT4:
> + case GL_DOUBLE_MAT2:
> + case GL_DOUBLE_MAT2x3:
> + case GL_DOUBLE_MAT2x4:
> + case GL_DOUBLE_MAT3x2:
> + case GL_DOUBLE_MAT3:
> + case GL_DOUBLE_MAT3x4:
> + case GL_DOUBLE_MAT4x2:
> + case GL_DOUBLE_MAT4x3:
> + case GL_DOUBLE_MAT4:
> default:
>_mesa_problem(NULL, "Invalid type in %s", __func__);
>return;
> @@ -789,7 +822,7 @@ _mesa_uniform(struct gl_context *ctx, struct
> gl_shader_program *shProg,
> */
> if (!uni->type->is_boolean()) {
>memcpy(&uni->storage[components * offset], values,
> - sizeof(uni->storage[0]) * components * count);
> + sizeof(uni->storage[0]) * components * count * size_mul);
> } else {
>const union gl_constant_value *src =
>(const union gl_constant_value *) values;
> @@ -892,13 +925,14 @@ extern "C" void
> _mesa_uniform_matrix(struct gl_context *ctx, struct gl_shader_program
> *shProg,
>GLuint cols, GLuint rows,
> GLint location, GLsizei count,
> - GLboolean transpose, const GLfloat *values)
> + GLboolean transpose,
> + const GLvoid *values, GLenum type)
> {
> unsigned offset;
> unsigned vectors;
> unsigned components;
> unsigned elements;
> -
> + int size_mul = mesa_type_is_double(type) ? 2 : 1;
> struct gl_uniform_storage *const uni =
>validate_uniform_paramet
Re: [Mesa-dev] [PATCH 02/11] mesa: add ARB_gpu_shader_fp64 extension info
On 08/14/2014 03:52 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This just adds the entries to extensions.c and mtypes.h
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/main/extensions.c | 1 +
> src/mesa/main/mtypes.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> index 4f322d0..1445a9d 100644
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -117,6 +117,7 @@ static const struct extension extension_table[] = {
> { "GL_ARB_framebuffer_sRGB",o(EXT_framebuffer_sRGB),
> GL, 1998 },
> { "GL_ARB_get_program_binary", o(dummy_true),
> GL, 2010 },
> { "GL_ARB_gpu_shader5", o(ARB_gpu_shader5),
> GL, 2010 },
> + { "GL_ARB_gpu_shader_fp64", o(ARB_gpu_shader_fp64),
> GL, 2010 },
> { "GL_ARB_half_float_pixel",o(dummy_true),
> GL, 2003 },
> { "GL_ARB_half_float_vertex", o(ARB_half_float_vertex),
> GL, 2008 },
> { "GL_ARB_instanced_arrays",o(ARB_instanced_arrays),
> GL, 2008 },
The extension spec says, "OpenGL 3.2 and GLSL 1.50 are required." Many
times these requirements are excessive... and there just because people
didn't want to think about the interactions with older versions. :) In
this case, however, I think it's reasonable. In GLSL 1.50 the rules
about where interpolation qualifiers were specified changed. The last
bit of issue 9 alludes to this.
(9) Are double-precision "varyings" (values passed between shader stages)
supported by this extension? If so, is double-precision interpolation
is supported?
RESOLVED: Double-precision shader inputs and outputs are supported,
except for vertex shader inputs and fragment shader outputs.
Additionally, double-precision vertex shader inputs are provided by the
separate extension EXT_vertex_attrib_64bit. No known extension provides
double-precision fragment outputs, but that doesn't seem important since
OpenGL provides no pixel/texture formats with double-precision
components that could reasonably receive such outputs.
Interpolation not supported in this extension for double-precision
floating-point components. As with integer types in OpenGL 3.0,
double-precision floating-point fragment shader inputs must be qualified
as "flat".
Note that this extension reformulates the spec language requiring "flat"
qualifiers, in addition to adding doubles to the list of "flat" types.
In GLSL 1.30, the spec applies these requirements to vertex shader
outputs but imposes no requirement on fragment inputs. We move this
requirement to fragment inputs, since vertex shader outputs may be
passed to tessellation or geometry shaders without interpolation, and
thus without the need for qualification by "flat".
Because of this, it seems like we should restrict this extension to
core profile. Opinions?
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 742ce3e..121f2ea 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3572,6 +3572,7 @@ struct gl_extensions
> GLboolean ARB_explicit_uniform_location;
> GLboolean ARB_geometry_shader4;
> GLboolean ARB_gpu_shader5;
> + GLboolean ARB_gpu_shader_fp64;
> GLboolean ARB_half_float_vertex;
> GLboolean ARB_instanced_arrays;
> GLboolean ARB_internalformat_query;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82978] New: [swrast] piglit glsl-uniform-initializer-6 regression
https://bugs.freedesktop.org/show_bug.cgi?id=82978
Priority: medium
Bug ID: 82978
Keywords: regression
CC: anuj.pho...@gmail.com, matts...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [swrast] piglit glsl-uniform-initializer-6 regression
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v...@freedesktop.org
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Mesa core
Product: Mesa
mesa: 12a679a6f61259d833b0d9098b9f6e2607611cc6 (master 10.4.0-devel)
$ ./bin/shader_runner tests/shaders/glsl-uniform-initializer-6.shader_test
-auto
Probe color at (0,0)
Expected: 0.00 1.00 0.00 0.00
Observed: 0.00 0.00 0.00 0.00
PIGLIT: {"result": "fail" }
9e2e7c7dc0ff08a2066435dd519502340955bbd2 is the first bad commit
commit 9e2e7c7dc0ff08a2066435dd519502340955bbd2
Author: Matt Turner
Date: Fri Aug 8 19:46:05 2014 -0700
glsl: Use UniformBooleanTrue value for uniform initializers.
Reviewed-by: Anuj Phogat
:04 04 16675d631f977bec6d671bd8dc577b5372d93d71
05f53d9e7fa6cd90a955125380b647116d102087 Msrc
bisect run success
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] auxilary/os: Add Solaris support in os_get_total_physical_memory.
On Fri, Aug 22, 2014 at 5:44 PM, Emil Velikov wrote:
> On 23/08/14 01:28, Vinson Lee wrote:
>> The patch fixes the build on Oracle Solaris.
>>
>> CC os/os_misc.lo
>> "os/os_misc.c", line 59: #error: unexpected platform in os_sysinfo.c
>>
> Does mesa even run on Solaris or is this just to silence the buildbot ?
>
> FWIW Reviewed-by: Emil Velikov
>
This is just to fix a build. I do not know if it runs or not. It
probably doesn't.
>> Signed-off-by: Vinson Lee
>> ---
>> src/gallium/auxiliary/os/os_misc.c |4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/os/os_misc.c
>> b/src/gallium/auxiliary/os/os_misc.c
>> index ef84c79..4c5a22d 100644
>> --- a/src/gallium/auxiliary/os/os_misc.c
>> +++ b/src/gallium/auxiliary/os/os_misc.c
>> @@ -47,7 +47,7 @@
>> #endif
>>
>>
>> -#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
>> +#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) ||
>> defined(PIPE_OS_SOLARIS)
>> # include
>> #elif defined(PIPE_OS_APPLE) || defined(PIPE_OS_BSD)
>> # include
>> @@ -111,7 +111,7 @@ os_get_option(const char *name)
>> bool
>> os_get_total_physical_memory(uint64_t *size)
>> {
>> -#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN)
>> +#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_CYGWIN) ||
>> defined(PIPE_OS_SOLARIS)
>> const long phys_pages = sysconf(_SC_PHYS_PAGES);
>> const long page_size = sysconf(_SC_PAGE_SIZE);
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [XDC2014] Travel sponsorship
Hi everyone, If you are willing to give a talk at XDC2014 and require travel sponsorship, please send an email to bo...@foundation.x.org (CC: martin.pe...@free.fr) with an estimate of the travel + accommodation cost and the abstract of your talk. Please send us your applications as soon as possible and do so no later than September 5th! Thanks, Martin Peres - On behalf of the board of directors ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82978] [swrast] piglit glsl-uniform-initializer-6 regression
https://bugs.freedesktop.org/show_bug.cgi?id=82978 Vinson Lee changed: What|Removed |Added Keywords||bisected -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77161] [softpipe] piglit fbo-generatemipmap-cubemap S3TC_DXT1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=77161 Vinson Lee changed: What|Removed |Added Keywords||bisected -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75661] st_glsl_to_tgsi.cpp:637:get_opcode: Assertion `src0.type != GLSL_TYPE_STRUCT' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=75661 Vinson Lee changed: What|Removed |Added Keywords||bisected -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
