Re: [Mesa-dev] [PATCH 13/21] glsl: Track explicitly set varying locations
On 04/29/2014 10:57 PM, Timothy Arceri wrote:
Looks like this patch should have been dropped with the removal of
user_location?
Nope. We still need to track the location set in the shader. Now it's
tracked in the same location field as, say, vertex shader inputs instead
of having a special field.
On Tue, 2014-04-29 at 17:52 -0700, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ast_to_hir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 0411bef..e1192ed 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2268,6 +2268,8 @@ validate_explicit_location(const struct
ast_type_qualifier *qual,
assert(!Unexpected shader type);
break;
}
+
+ var-data.location = var-data.location;
} else {
var-data.location = qual-location;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: change invalid texture swizzle error to GL_INVALID_ENUM
Ping.
-Brian
On 04/24/2014 03:29 PM, Brian Paul wrote:
The original GL_EXT_texture_swizzle extensions said GL_INVALID_OPERATION
was to be generated when the an invalid swizzle was passed to
glTexParameter(). But in OpenGL 3.3 and later, the error should be
GL_INVALID_ENUM.
---
src/mesa/main/texparam.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 40790ff..dc17ea5 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -485,7 +485,7 @@ set_tex_parameteri(struct gl_context *ctx,
const GLuint comp = pname - GL_TEXTURE_SWIZZLE_R_EXT;
const GLint swz = comp_to_swizzle(params[0]);
if (swz 0) {
-_mesa_error(ctx, GL_INVALID_OPERATION,
+_mesa_error(ctx, GL_INVALID_ENUM,
glTexParameter(swizzle 0x%x), params[0]);
return GL_FALSE;
}
@@ -510,7 +510,7 @@ set_tex_parameteri(struct gl_context *ctx,
set_swizzle_component(texObj-_Swizzle, comp, swz);
}
else {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, GL_INVALID_ENUM,
glTexParameter(swizzle 0x%x), params[comp]);
return GL_FALSE;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78101] [bisected] Mesa demos fails to link with drawtex.c:34: undefined reference to `glDrawTexfOES'
https://bugs.freedesktop.org/show_bug.cgi?id=78101 --- Comment #4 from Scott Moreau ore...@gmail.com --- (In reply to comment #3) Created attachment 98234 [details] [review] hopeful patch to fix the issue I'm having problems configuring demos build system to reproduce this ... No special configuration for demos is needed. As far as I can tell, mesa just needs to be built with gles1 enabled. however for me it seems the reason for failure is that drawtex.c uses function which is not part of opengles1.1 API but an extension function which should be resolved via eglGetProcAddress instead. Attaching a hopeful fix to try. This patch allows demos to build successfully here. -- 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] mesa: change invalid texture swizzle error to GL_INVALID_ENUM
On 04/24/2014 02:29 PM, Brian Paul wrote:
The original GL_EXT_texture_swizzle extensions said GL_INVALID_OPERATION
was to be generated when the an invalid swizzle was passed to
glTexParameter(). But in OpenGL 3.3 and later, the error should be
GL_INVALID_ENUM.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/main/texparam.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 40790ff..dc17ea5 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -485,7 +485,7 @@ set_tex_parameteri(struct gl_context *ctx,
const GLuint comp = pname - GL_TEXTURE_SWIZZLE_R_EXT;
const GLint swz = comp_to_swizzle(params[0]);
if (swz 0) {
-_mesa_error(ctx, GL_INVALID_OPERATION,
+_mesa_error(ctx, GL_INVALID_ENUM,
glTexParameter(swizzle 0x%x), params[0]);
return GL_FALSE;
}
@@ -510,7 +510,7 @@ set_tex_parameteri(struct gl_context *ctx,
set_swizzle_component(texObj-_Swizzle, comp, swz);
}
else {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, GL_INVALID_ENUM,
glTexParameter(swizzle 0x%x), params[comp]);
return GL_FALSE;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/21] meta: Fix saving the program pipeline state
On 04/29/2014 08:43 PM, Chia-I Wu wrote:
On Wed, Apr 30, 2014 at 8:52 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
This code was broken in some odd ways before. Too much state was being
saved, it was being restored in the wrong order, and in the wrong way.
The biggest problem was that the pipeline object was restored before
restoring the programs attached to the default pipeline.
Fixes a regression in the glean texgen test.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Eric Anholt e...@anholt.net
---
src/mesa/drivers/common/meta.c | 34 --
src/mesa/drivers/common/meta.h | 1 -
2 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index ac27abb..92bc185 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -577,11 +577,15 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield
state)
}
if (ctx-Extensions.ARB_separate_shader_objects) {
- /* Warning it must be done before _mesa_UseProgram call */
- _mesa_reference_pipeline_object(ctx, save-_Shader, ctx-_Shader);
- _mesa_reference_pipeline_object(ctx, save-Pipeline,
- ctx-Pipeline.Current);
- _mesa_BindProgramPipeline(0);
+ /* Warning: This must be done before saving the current programs.
+ * Otherwise the programs attached to the pipeline will be saved
+ * instead of the programs attached to the default pipeline.
+ */
+ if (ctx-Pipeline.Current != ctx-Pipeline.Default) {
+_mesa_reference_pipeline_object(ctx, save-Pipeline,
+ctx-Pipeline.Current);
+_mesa_BindProgramPipeline(0);
+ }
}
for (i = 0; i MESA_SHADER_STAGES; i++) {
@@ -929,14 +933,6 @@ _mesa_meta_end(struct gl_context *ctx)
save-ATIFragmentShaderEnabled);
}
- /* Warning it must be done before _mesa_use_shader_program call */
- if (ctx-Extensions.ARB_separate_shader_objects) {
- _mesa_reference_pipeline_object(ctx, ctx-_Shader, save-_Shader);
- _mesa_reference_pipeline_object(ctx, ctx-Pipeline.Current,
- save-Pipeline);
- _mesa_reference_pipeline_object(ctx, save-Pipeline, NULL);
- }
-
if (ctx-Extensions.ARB_vertex_shader) {
_mesa_use_shader_program(ctx, GL_VERTEX_SHADER,
save-Shader[MESA_SHADER_VERTEX],
@@ -956,10 +952,20 @@ _mesa_meta_end(struct gl_context *ctx)
_mesa_reference_shader_program(ctx, ctx-_Shader-ActiveProgram,
save-ActiveShader);
+ /* Warning: This must be done after _mesa_use_shader_program call.
+ * Otherwise the programs will be restored to the pipeline object
+ * instead of to the default pipeline.
+ */
+ if (save-Pipeline) {
+ assert(ctx-Extensions.ARB_separate_shader_objects);
+ _mesa_bind_pipeline(ctx, save-Pipeline);
This issue does not appear to be fixed
http://lists.freedesktop.org/archives/mesa-dev/2014-April/057999.html
The attached change to piglit triggers it.
What should the result have been with that patch? I tried that with my
current sso6 branch, and
arb_separate_shader_objects-rendezvous_by_location passes with or
without this patch.
+
+ _mesa_reference_pipeline_object(ctx, save-Pipeline, NULL);
+ }
+
for (i = 0; i MESA_SHADER_STAGES; i++)
_mesa_reference_shader_program(ctx, save-Shader[i], NULL);
_mesa_reference_shader_program(ctx, save-ActiveShader, NULL);
- _mesa_reference_pipeline_object(ctx, save-_Shader, NULL);
}
if (state MESA_META_STENCIL_TEST) {
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index fde4f9a..0a34792 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -121,7 +121,6 @@ struct save_state
GLboolean ATIFragmentShaderEnabled;
struct gl_shader_program *Shader[MESA_SHADER_STAGES];
struct gl_shader_program *ActiveShader;
- struct gl_pipeline_object *_Shader;
struct gl_pipeline_object *Pipeline;
/** MESA_META_STENCIL_TEST */
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78101] [bisected] Mesa demos fails to link with drawtex.c:34: undefined reference to `glDrawTexfOES'
https://bugs.freedesktop.org/show_bug.cgi?id=78101 --- Comment #5 from Ian Romanick i...@freedesktop.org --- The demos need to use eglGetProcAddress for extension functions. The patch is the right approach, but having a non-static function pointer with the same name as a function is very dangerous. You wouldn't declare 'int (*printf)(const char *, ...);' in your code and expect things to work, would you? :) This is why GLEW names the function pointers __glewFoo and has a #define glFoo that calls 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] intel, dma-buf import and egl image external
On Tue, Apr 29, 2014 at 01:21:11PM -0700, Eric Anholt wrote: Chad Versace chad.vers...@linux.intel.com writes: On Mon, Mar 24, 2014 at 09:07:32AM +1000, Dave Airlie wrote: On Sat, Mar 8, 2014 at 12:13 AM, Pohjolainen, Topi topi.pohjolai...@intel.com wrote: On Mon, Mar 03, 2014 at 01:19:48PM +1000, Dave Airlie wrote: There is a comment and two checks in the i965 dma-buf importer, * Images originating via EGL_EXT_image_dma_buf_import can be used only * with GL_OES_EGL_image_external only. however I can't find any reference to this in the spec txt, and removing the checks make my test app run fine using TEXTURE_2D. You are correct that there is nothing in the spec about this, but it also leaves it open for the driver to choose on which buffers it allows the external sampling. After quite a bit of debate on when/where it would be safe to use dma-buffers, it was decided that we simply allow dma-buffers for external sampling only - that extension already restricts the use for single-miplevel and read-only which is exactly what we wanted. The same time it wasn't clear what kind of sources we should allow for external sampling (besides dma), and hence we simply kept things as they were before - none other. Note that before the introduction of dma-buffers the image external extension wasn't enabled at all on i965. This is a really bad idea, since it means you can't use dma-buf imported things with standard shader programs, if I want to import a dma-buf I shouldn't have to write specific shader programs or use special bindings, unless the spec says so. Bringing your request to its logical conclusion... Either the spec should be more restrictive, or the implementation shouldn't have arbitrary differences from what other implementations could do. ...leads to disaster. It's naive to expect each implementation to support what other implementations *could*, or even *currently* do. Are you prepared to impelement support for these horrorshows? A. Import a YUV EGLImage backed by two dma_bufs (Y in the first, UV in the second) as a GL_TEXTURE_EXTERNAL_OES and transparently handle the YUV-RGB transcode in your shader code generator? Because, iirc, ARM's EGL/GLES2 stack supports that for Chrome. B. Same idea as A, but support importing the image as a GL_TEXTURE_2D and again transparently handle the YUV-RGB transcode. Because, for all we know, ARM's stack may support that too. Ignore YUV for now. YUV is the thing that image_external is for, with all of its weird requirements and unspecifiedness and making your images undefined on import. What airlied wants (I think) and what I definitely want, is to import normal ARGB dma_bufs and use them with GL_TEXTURE_2D. I think we can do this, and it's just a matter of making some solid tests to make sure we're not screwing up sibling management, and that the offset/stride/etc handling all works. Adding support for GL_TEXTURE_2D from ARGB dma_bufs sounds genuinely useful and a good idea, as long as orphaning is magaged correctly. What I'm opposed to is a blanket policy of if Mesa driver xyz can do abc with dma_buf EGLImages, then i965 must do abc too. That's how I interpreted arlied's the implementation shouldn't have arbitrary differences from what other implementations could do. Looks like I interpreted him incorrectly. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78123] New: svga prints out command errors
https://bugs.freedesktop.org/show_bug.cgi?id=78123 Priority: medium Bug ID: 78123 Assignee: mesa-dev@lists.freedesktop.org Summary: svga prints out command errors Severity: critical Classification: Unclassified OS: Linux (All) Reporter: john.kare.alsa...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa When doing anything 3D related, 'VMware: vmw_ioctl_command error Invalid argument.' is printed This happens since: fe6a854477c2ed30c37c200668a4dc86512120f7 svga/winsys: implement GBS support Arch Linux Linux 3.14.1 libdrm 2.4.53 On VMware Workstation 10.0.2 build-1744117 Windows 8.1 x64 AMD Catalyst 14.10 -- 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] Minecraft crash in nouveau_dri.so
The relevant code:
if (slab-free == 0) {
LIST_DEL(slab-head);
LIST_ADD(slab-head, bucket-full);
}
And the LIST_ADD is line 206 (on the 9.2 branch).
Do you know if multiple GL threads are used? I looked at the code, and
it seems perfectly fine, and hasn't changed in forever
(nouveau_mm_allocate is still the same in 10.2-git). Unless there are
multiple threads that are each doing allocations, in which case,
ka-boom. (In general, nouveau is not safe with simultaneously-running
threads, even if they have separate GL contexts... yet. I've started
looking at it, but there are a lot of pieces to the puzzle.)
-ilia
On Wed, Apr 30, 2014 at 7:13 AM, Kevin H. Hobbs hob...@ohio.edu wrote:
I'm running Minecraft 1.7.9
on Fedora 19 x86_64
with mesa-dri-drivers-9.2.4-1.20131128.fc19.x86_64.
lspci says my graphics card is :
01:00.0 VGA compatible controller: NVIDIA Corporation G86 [Quadro
NVS 290] (rev a1)
The the console output says :
A fatal error has been detected by the Java Runtime Environment:
[06:47:32 INFO]: Client #
[06:47:32 INFO]: Client # SIGSEGV (0xb) at
pc=0x7f75358ab2bd, pid=15253, tid=140141688981248
[06:47:32 INFO]: Client #
[06:47:32 INFO]: Client # JRE version: OpenJDK Runtime
Environment (7.0_55-b13) (build
1.7.0_55-mockbuild_2014_04_16_06_38-b00)
[06:47:32 INFO]: Client # Java VM: OpenJDK 64-Bit Server VM
(24.51-b03 mixed mode linux-amd64 compressed oops)
[06:47:32 INFO]: Client # Problematic frame:
[06:47:32 INFO]: Client # C [nouveau_dri.so+0x4042bd]
nouveau_mm_allocate+0x18d
I ran with ulimit -c unlimited and got a core dump.
Here's what gdb has to say aabout the core :#0
0x00389b8359e9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0 0x00389b8359e9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00389b8370f8 in __GI_abort () at abort.c:90
#2 0x7f75481075d9 in os::abort (dump_core=optimized out)
at
/usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc19.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1594
#3 0x7f7548286a8f in VMError::report_and_die
(this=this@entry=0x7f754796eba0)
at
/usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc19.x86_64/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1078
#4 0x7f754810f51f in JVM_handle_linux_signal (sig=11,
info=0x7f754796edf0, ucVoid=0x7f754796ecc0,
abort_if_unrecognized=optimized out)
at
/usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc19.x86_64/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:531
#5 signal handler called
#6 0x7f75358ab2bd in list_add (list=0x7f75405964b8,
item=0x7f749b96ef60) at
../../../../src/gallium/auxiliary/util/u_double_list.h:61
#7 nouveau_mm_allocate (cache=optimized out, size=optimized
out, bo=bo@entry=0x7f749c676930,
offset=offset@entry=0x7f749c676938) at nouveau_mm.c:206
#8 0x7f75358ac9c2 in nouveau_buffer_allocate
(domain=optimized out, buf=0x7f749c6768e0,
screen=0x7f75405958f0) at nouveau_buffer.c:51
#9 nouveau_buffer_create (pscreen=0x7f75405958f0,
templ=optimized out) at nouveau_buffer.c:583
#10 0x7f7535604d89 in pipe_buffer_create (size=32768,
usage=optimized out, bind=optimized out, screen=optimized
out) at ../../src/gallium/auxiliary/util/u_inlines.h:247
#11 st_bufferobj_data (ctx=optimized out, target=optimized
out, size=32768, data=0x0, usage=optimized out,
obj=0x7f749c676850)
at ../../src/mesa/state_tracker/st_cb_bufferobjects.c:254
#12 0x7f75355efe1a in alloc_vertex_store
(ctx=ctx@entry=0x7f75405fd6e0) at
../../src/mesa/vbo/vbo_save_api.c:199
#13 0x7f75355f05c0 in _save_compile_vertex_list
(ctx=optimized out) at ../../src/mesa/vbo/vbo_save_api.c:454
#14 0x7f75355f0cb1 in _save_wrap_buffers (ctx=optimized
out) at ../../src/mesa/vbo/vbo_save_api.c:497
#15 0x7f75355f5390 in _save_wrap_filled_vertex
(ctx=optimized out) at ../../src/mesa/vbo/vbo_save_api.c:528
#16 0x7f753550c8d9 in _ae_ArrayElement (elt=2815) at
../../src/mesa/main/api_arrayelt.c:1697
#17 0x7f75355efd70 in _save_OBE_DrawArrays (mode=optimized
out, start=optimized out, count=optimized out) at
../../src/mesa/vbo/vbo_save_api.c:1078
#18 0x7f753d081964 in ?? ()
#19 0x in ?? ()
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78101] [bisected] Mesa demos fails to link with drawtex.c:34: undefined reference to `glDrawTexfOES'
https://bugs.freedesktop.org/show_bug.cgi?id=78101 --- Comment #6 from Tapani Pälli lem...@gmail.com --- (In reply to comment #5) The demos need to use eglGetProcAddress for extension functions. The patch is the right approach, but having a non-static function pointer with the same name as a function is very dangerous. You wouldn't declare 'int (*printf)(const char *, ...);' in your code and expect things to work, would you? :) This is why GLEW names the function pointers __glewFoo and has a #define glFoo that calls it. That is why I left OES out of the name but I can change it to something better (?) -- 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] Add an ir_triop_mid3 expression and lower it to mins and maxs.
On 04/30/2014 03:21 AM, Petri Latvala wrote:
On 04/29/2014 09:57 PM, Matt Turner wrote:
On Tue, Apr 29, 2014 at 6:01 AM, Petri Latvala
petri.latv...@intel.com wrote:
For the record, tested this with the following shader:
Cool. Please submit this as a piglit test.
Sent to piglit mailing list, with accompanying tests for min3 and max3.
Wouldn't it be simpler to detect constant arguments in opt_algebraic
and do the optimization there, and just perform the standard lowering
here? It seems cleaner to me. I don't think we generate different code
based on the arguments in any other lowering pass.
I was thinking about that, but ended up optimizing on lowering. My
reasoning was that if mid3(x, 1, 3) was transformed to min(max(x, 1), 3)
in opt_algebraic, backends with theoretical native support for mid3
would then need to recognize that and transform it back to a mid3.
I was thinking we'd emit mid3(x, 1, 3) as the same set of IR as mid3(x,
y, z), but we'd just order the operands so that other optimization
passes could optimize.
Right now we generate:
max(min(a, b), max(min(a, c), b))
With the values from the bug, this becomes:
max(min(a, 1), max(min(a, 3), 1))
What we want is
max(1, min(a, 3))
It's not obvious to me how opt_algebraic could rearrange the expression
tree, for all arrangements of {a, 1, 3}, so that other optimization
passes could do that pruning. However, that does seem like a reasonable
approach for min3 and max3.
If we think it's possible to make opt_algebraic smart enough to do this
tree rearrangement, then we probably don't need ir_triop_mid3 or the
lowering pass at all.
(Are there even any GPUs that can do mid3 directly? AMD?)
I believe the Southern Islands GPUs support these instructions natively.
Certainly whatever GPU is in the Xbox One and PS4 has them.
Of course, it can be said that it's not a regression as mid3 doesn't get
to backends as mid3 before this patch either.
I think when the radeonsi driver grows support for emitting these
instructions, they'll want to change st_glsl_to_tgsi to not lower the
instructions away in the firtst place.
I'll change the patch to do this optimization in opt_algebraic.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: Program RASTER_CONFIG for harvested GPUs v2
v2:
- Write RASTER_CONFIG for all SEs
https://bugs.freedesktop.org/show_bug.cgi?id=60879
---
src/gallium/drivers/radeonsi/si_state.c | 100 --
src/gallium/drivers/radeonsi/sid.h| 8 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 3 +
src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
4 files changed, 106 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 921264e..509ba5b 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3024,6 +3024,17 @@ void si_init_state_functions(struct si_context *sctx)
sctx-b.b.draw_vbo = si_draw_vbo;
}
+static unsigned pkr_mask_to_map(unsigned mask)
+{
+ switch(mask 0x3) {
+ case 0x0:
+ case 0x1: return 0x0;
+ case 0x2: return 0x3;
+ case 0x3: return 0x2;
+ }
+ return 0;
+}
+
void si_init_config(struct si_context *sctx)
{
struct si_pm4_state *pm4 = si_pm4_alloc_state(sctx);
@@ -3101,24 +3112,103 @@ void si_init_config(struct si_context *sctx)
break;
}
} else {
+ unsigned raster_config = 0;
+ unsigned default_rb_mask = 0;
+ unsigned sh_per_se;
+ unsigned num_se;
+ unsigned rb_mask = sctx-screen-b.info.si_backend_enabled_mask;
+ unsigned i;
switch (sctx-screen-b.family) {
case CHIP_TAHITI:
case CHIP_PITCAIRN:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x2a00126a);
+ raster_config = 0x2a00126a;
+ sh_per_se = 2;
+ num_se = 2;
break;
case CHIP_VERDE:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x124a);
+ raster_config = 0x124a;
+ sh_per_se = 2;
+ num_se = 1;
break;
case CHIP_OLAND:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x0082);
+ raster_config = 0x0082;
+ sh_per_se = 1;
+ num_se = 1;
break;
case CHIP_HAINAN:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x);
+ raster_config = 0x;
+ sh_per_se = 1;
+ num_se = 1;
break;
default:
- si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x);
+ raster_config = 0x;
+ sh_per_se = 1;
+ num_se = 1;
break;
}
+
+ if (rb_mask) {
+ /* XXX: I can't figure out what the *_XSEL and *_YSEL
+* fields are for, so I'm leaving them as their default
+* values. */
+ unsigned pkr_mask = (sh_per_se | 0x1);
+ unsigned se0_pkr0 = rb_mask pkr_mask;
+ unsigned se0_pkr1 = (rb_mask = sh_per_se) pkr_mask;
+ unsigned se1_pkr0 = (rb_mask = sh_per_se) pkr_mask;
+ unsigned se1_pkr1 = (rb_mask = sh_per_se) pkr_mask;
+ unsigned se_map = 0;
+ unsigned se0_pkr_map = 0;
+ unsigned se1_pkr_map = 0;
+ unsigned se0_pkr0_rb_map = 0;
+ unsigned se0_pkr1_rb_map = 0;
+ unsigned se1_pkr0_rb_map = 0;
+ unsigned se1_pkr1_rb_map = 0;
+ if (!se0_pkr0 !se0_pkr1) {
+ /* se0 disabled */
+ se_map |= 0x1;
+ }
+ if (se1_pkr0 || se1_pkr1) {
+ /* se1 enabled */
+ se_map |= 0x2;
+ }
+ if (!se0_pkr0) {
+ /* se0 pkr0 disabled */
+ se0_pkr_map |= 0x1;
+ }
+ if (se0_pkr1) {
+ /* se0 pkr1 enabled */
+ se0_pkr_map |= 0x2;
+ }
+ if (!se1_pkr0) {
+ /* se1 pkr0 disabled */
+ se1_pkr_map |= 0x1;
+ }
+ if (se1_pkr1) {
+ /* se1 pkr1 enabled */
+ se1_pkr_map |= 0x2;
+ }
+
+
Re: [Mesa-dev] Minecraft crash in nouveau_dri.so
Ilia, thank you for looking at it.
On 04/30/2014 12:47 PM, Ilia Mirkin wrote:
The relevant code:
if (slab-free == 0) {
LIST_DEL(slab-head);
LIST_ADD(slab-head, bucket-full);
}
And the LIST_ADD is line 206 (on the 9.2 branch).
Do you know if multiple GL threads are used?
I do not know, is there a good way to tell?
According to top java at least is using more than 100% CPU, but I think
there's a client server model even in single player.
I ran Minecraft on another computer with more RAM (12GiB) and a newer
graphics card (GeForce 9800 GTX+) that also uses the nouveau driver and
it worked fine.
I decreased the Render Distance in Minecraft and everything seemed
fine on the first computer (4GiB RAM).
The trouble might only occur in a low memory condition.
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/21] linker: Modify cross_validate_outputs_to_inputs to match using explicit locations
Ian Romanick i...@freedesktop.org writes:
From: Ian Romanick ian.d.roman...@intel.com
This will be used for GL_ARB_separate_shader_objects. That extension
not only allows separable shaders to rendezvous by location, but it also
allows traditionally linked shaders to rendezvous by location. The spec
says:
36. How does the behavior of input/output interface matching differ
between separable programs and non-separable programs?
RESOLVED: The rules for matching individual variables or block
members between stages are identical for separable and
non-separable programs, with one exception -- matching variables
of different type with the same location, as discussed in issue
34, applies only to separable programs.
However, the ability to enforce matching requirements differs
between program types. In non-separable programs, both sides of
an interface are contained in the same linked program. In this
case, if the linker detects a mismatch, it will generate a link
error.
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index e5c2751..232e230 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -172,6 +172,7 @@ cross_validate_outputs_to_inputs(struct gl_shader_program
*prog,
gl_shader *producer, gl_shader *consumer)
{
glsl_symbol_table parameters;
+ ir_variable *explicit_locations[MAX_VARYING] = { NULL, };
/* Find all shader outputs in the producer stage.
*/
@@ -181,7 +182,26 @@ cross_validate_outputs_to_inputs(struct
gl_shader_program *prog,
if ((var == NULL) || (var-data.mode != ir_var_shader_out))
continue;
- parameters.add_variable(var);
+ if (!var-data.explicit_location
+ || var-data.location VARYING_SLOT_VAR0)
+ parameters.add_variable(var);
+ else {
+ /* User-defined varyings with explicit locations are handled
+ * differently because they do not need to have matching names.
+ */
+ const unsigned idx = var-data.location - VARYING_SLOT_VAR0;
+
+ if (explicit_locations[idx] != NULL) {
+linker_error(prog,
+ %s shader has multiple outputs explicitly
+ assigned to location %d\n,
+ _mesa_shader_stage_to_string(producer-Stage),
+ idx);
+return;
Relevant citation:
A program will fail to link if any two fragment shader output variables
are assigned to the same location and index, or if any two output
variables from the same non-fragment shader stage are assigned to the same
location.
I think this has a problem of not throwing an error when your explicit
location array overlaps your explicit location scalar, but I don't think
it's that important.
@@ -1051,8 +1091,13 @@ namespace linker {
bool
populate_consumer_input_sets(void *mem_ctx, exec_list *ir,
hash_table *consumer_inputs,
- hash_table *consumer_interface_inputs)
+ hash_table *consumer_interface_inputs,
+ ir_variable
*consumer_inputs_with_locations[MAX_VARYING])
{
+ memset(consumer_inputs_with_locations,
+ 0,
+ sizeof(consumer_inputs_with_locations[0]) * MAX_VARYING);
+
foreach_list(node, ir) {
ir_variable *const input_var = ((ir_instruction *)
node)-as_variable();
@@ -1060,7 +1105,13 @@ populate_consumer_input_sets(void *mem_ctx, exec_list
*ir,
if (input_var-type-is_interface())
return false;
- if (input_var-get_interface_type() != NULL) {
+ if (input_var-data.explicit_location) {
+/* FINISHME: If the input is an interface, array, or structure,
it
+ * FINISHME: will use multiple slots.
+ */
+consumer_inputs_with_locations[input_var-data.location] =
+ input_var;
I think this FINISHME shouldn't be there. It looks like
assign_varying_locations() only cares about finding the ir_variable at
the start of a contiguous location block. My reasoning:
For !producer, consumer_inputs_with_locations isn't used.
For !consumer, consumer_inputs_with_locations is empty.
For consumer producer, if you were trying to set some ir_variable to
the middle of a location block on the other side of producer/consumer,
cross_validate_outputs_to_inputs() should be link-erroring due to either
type mismatch or location overlaps. If the variables do match up, then
they've got a matching data.location and you only looked at
consumer_inputs_with_locations[var-data.location], not any following
entries for the array/structure.
pgp1J3otjuldz.pgp
Description: PGP signature
___
mesa-dev mailing
Re: [Mesa-dev] [00/21] Last of SSO, take 47
Ian Romanick i...@freedesktop.org writes: A lot the patches in this series were slightly reworked to incorporate Eric's feedback (remove ir_variable::user_location) on the previous attempt. Other than that change, I patch 1 is new, and patch 16 adds previously missing display list support. Patch 2, 3, 13, 16, 17, 18, 20, 21 are: Reviewed-by: Eric Anholt e...@anholt.net I think my patch 15 comments were minor, and if you agree with them (meaning I actually understood what was going on), then apply the r-b there too. Patch 19 is: Acked-by: Eric Anholt e...@anholt.net Patch 14 I don't think is needed (since we've got explicit locations being assigned to corresponding varying slots). pgpPxyWaFTwxQ.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 11/18] i965: Replace the region in DRIimage with just a BO pointer and stride.
Kenneth Graunke kenn...@whitecape.org writes:
On 04/29/2014 04:34 PM, Eric Anholt wrote:
[snip]
@@ -558,12 +572,8 @@ intel_dup_image(__DRIimage *orig_image, void
*loaderPrivate)
if (image == NULL)
return NULL;
- intel_region_reference(image-region, orig_image-region);
- if (image-region == NULL) {
- free(image);
- return NULL;
- }
-
+ drm_intel_bo_reference(orig_image-bo);
+ image-bo = orig_image-bo
I noticed you dropped this NULL check, rather than checking image-bo !=
NULL. Presumably in intel_dup_image, you know that the orig_image BO
actually exists? If so, this seems fine.
Yeah, we only return an image if it's got a BO attached.
(We also only returned images when they had regions attached, so even
the old code was doing a pointless check)
pgpgRT1EXsWaB.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] clover: Add a stub implementation of clCreateImage()
Now that we are uisng the OpenCL 1.2 headers, applications expect all
the OpenCL 1.2 functions to be implemented.
This fixes linking errors with the piglit CL tests.
---
src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
src/gallium/state_trackers/clover/api/dispatch.hpp | 8 +++-
src/gallium/state_trackers/clover/api/memory.cpp | 11 +++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp
b/src/gallium/state_trackers/clover/api/dispatch.cpp
index 2ee6208..488e654 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.cpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
@@ -120,7 +120,7 @@ namespace clover {
clCreateSubDevices,
clRetainDevice,
clReleaseDevice,
- NULL, // clCreateImage
+ clCreateImage,
NULL, // clCreateProgramWithBuiltInKernels
NULL, // clCompileProgram
NULL, // clLinkProgram
diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp
b/src/gallium/state_trackers/clover/api/dispatch.hpp
index 833fb0e..ffae1ae 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.hpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
@@ -653,7 +653,13 @@ struct _cl_icd_dispatch {
CL_API_ENTRY cl_int (CL_API_CALL *clReleaseDevice)(
cl_device_id device);
- void *clCreateImage;
+ CL_API_ENTRY cl_mem (CL_API_CALL *clCreateImage)(
+ cl_context context,
+ cl_mem_flags flags,
+ const cl_image_format *image_format,
+ const cl_image_desc *image_desc,
+ void *host_ptr,
+ cl_int *errcode_ret);
CL_API_ENTRY cl_program (CL_API_CALL *clCreateProgramWithBuiltInKernels)(
cl_context context,
diff --git a/src/gallium/state_trackers/clover/api/memory.cpp
b/src/gallium/state_trackers/clover/api/memory.cpp
index 7ed2191..977e06c 100644
--- a/src/gallium/state_trackers/clover/api/memory.cpp
+++ b/src/gallium/state_trackers/clover/api/memory.cpp
@@ -334,3 +334,14 @@ clSetMemObjectDestructorCallback(cl_mem d_mem,
} catch (error e) {
return e.get();
}
+
+/* This function was added in OpenCL 1.2 */
+CLOVER_API cl_mem
+clCreateImage(cl_context d_ctx, cl_mem_flags flags,
+ const cl_image_format *format,
+ const cl_image_desc *image_desc,
+ void *host_ptr, cl_int *r_errcode) {
+ fprintf(stderr, clCreateImage() not implemented\n);
+ *r_errcode = CL_IMAGE_FORMAT_NOT_SUPPORTED;
+ return NULL;
+}
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Make Broadwell HiZ path arrange for TC flushes.
Chad Versace chad.vers...@linux.intel.com writes: On Mon, Apr 21, 2014 at 02:08:49PM -0700, Kenneth Graunke wrote: HiZ operations make the depth/render caches out of sync with the sampler caches. We need to arrange for a TC flush to happen before the target buffer is used by the sampler. Calling brw_render_cache_set_add_bo makes that happen. On previous generations, brw_blorp_exec took care of flushing the texture cache by calling intel_batchbuffer_emit_mi_flush after doing any rendering. If we were to use the normal drawing path, then brw_postdraw_set_buffers_need_resolve would handle this. On Broadwell, we don't use BLORP, and we don't emit a rectangle primitive via the normal drawing path. The 3DSTATE_WM_HZ_OP and PIPE_CONTROL implicitly make drawing happen. So, none of our existing code makes this flush happen - we need to do it directly. Fixes 11 Piglit copyteximage subtests. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77223 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77226 Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/gen8_depth_state.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c b/src/mesa/drivers/dri/i965/gen8_depth_state.c index 8f5718a..05c3723 100644 --- a/src/mesa/drivers/dri/i965/gen8_depth_state.c +++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c @@ -307,6 +307,9 @@ gen8_hiz_exec(struct brw_context *brw, struct intel_mipmap_tree *mt, OUT_BATCH(0); ADVANCE_BATCH(); + /* Mark this buffer as needing a TC flush, as we've rendered to it. */ + brw_render_cache_set_add_bo(brw, mt-region-bo); + /* We've clobbered all of the depth packets, and the drawing rectangle, * so we need to ensure those packets are re-emitted before the next * primitive. Is this a general requirement for all surfaces? That is, after using a surface as a render target, a texture cache flush is required before sampling from it? Or is this requirement special to HiZ buffers, depth buffers, and/or WM_HZ_OP? The GPU L1/L2 caches are all incoherent with each other. Most of them are read only. If you've dirtied a thing with the render cache (color/Z/stencil render targets, BLT destinations, etc.) and you want to load from it through the sampler, data, or constant caches, you have to flush. pgp6WE_XSVNpW.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 03/14] mesa: Drop _EnabledUnits.
On 04/24/2014 05:50 PM, Eric Anholt wrote:
The field wasn't really valid, since we've got more than 32 units now. It
turns out it was mostly just used for checking != 0, or checking for fixed
function coordinates, though.
---
src/mesa/drivers/common/meta.c | 2 +-
src/mesa/drivers/dri/i915/intel_pixel.c| 2 +-
src/mesa/drivers/dri/i915/intel_pixel_copy.c | 2 +-
src/mesa/drivers/dri/i965/intel_pixel.c| 2 +-
src/mesa/drivers/dri/i965/intel_pixel_copy.c | 2 +-
src/mesa/drivers/dri/nouveau/nv04_state_frag.c | 2 +-
src/mesa/drivers/dri/nouveau/nv10_state_frag.c | 4 ++--
src/mesa/drivers/dri/r200/r200_state_init.c| 4 ++--
src/mesa/drivers/osmesa/osmesa.c | 4 ++--
src/mesa/drivers/x11/xm_line.c | 4 ++--
src/mesa/drivers/x11/xm_tri.c | 2 +-
src/mesa/main/ffvertex_prog.c | 2 +-
src/mesa/main/mtypes.h | 3 ---
src/mesa/main/texstate.c | 4
src/mesa/swrast/s_context.c| 4 ++--
src/mesa/swrast/s_texture.c| 29
+++---
src/mesa/swrast/s_triangle.c | 2 +-
17 files changed, 31 insertions(+), 43 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index ac27abb..0f0cfc7 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -2328,7 +2328,7 @@ _mesa_meta_Bitmap(struct gl_context *ctx,
if (ctx-_ImageTransferState ||
ctx-FragmentProgram._Enabled ||
ctx-Fog.Enabled ||
- ctx-Texture._EnabledUnits ||
+ ctx-Texture._MaxEnabledTexImageUnit != -1 ||
width tex-MaxSize ||
height tex-MaxSize) {
_swrast_Bitmap(ctx, x, y, width, height, unpack, bitmap1);
diff --git a/src/mesa/drivers/dri/i915/intel_pixel.c
b/src/mesa/drivers/dri/i915/intel_pixel.c
index da2f783..6f139e1 100644
--- a/src/mesa/drivers/dri/i915/intel_pixel.c
+++ b/src/mesa/drivers/dri/i915/intel_pixel.c
@@ -77,7 +77,7 @@ intel_check_blit_fragment_ops(struct gl_context * ctx, bool
src_alpha_is_one)
return false;
}
- if (ctx-Texture._EnabledUnits) {
+ if (ctx-Texture._MaxEnabledTexImageUnit != -1) {
DBG(fallback due to texturing\n);
return false;
}
diff --git a/src/mesa/drivers/dri/i915/intel_pixel_copy.c
b/src/mesa/drivers/dri/i915/intel_pixel_copy.c
index 6cfdc92..e7b5353 100644
--- a/src/mesa/drivers/dri/i915/intel_pixel_copy.c
+++ b/src/mesa/drivers/dri/i915/intel_pixel_copy.c
@@ -117,7 +117,7 @@ do_blit_copypixels(struct gl_context * ctx,
}
if (ctx-Fog.Enabled ||
- ctx-Texture._EnabledUnits ||
+ ctx-Texture._MaxEnabledTexImageUnit != -1 ||
ctx-FragmentProgram._Enabled) {
perf_debug(glCopyPixels(): Unsupported fragment shader state\n);
return false;
diff --git a/src/mesa/drivers/dri/i965/intel_pixel.c
b/src/mesa/drivers/dri/i965/intel_pixel.c
index 5f57022..a6db7fa 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel.c
@@ -77,7 +77,7 @@ intel_check_blit_fragment_ops(struct gl_context * ctx, bool
src_alpha_is_one)
return false;
}
- if (ctx-Texture._EnabledUnits) {
+ if (ctx-Texture._MaxEnabledTexImageUnit != -1) {
DBG(fallback due to texturing\n);
return false;
}
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_copy.c
b/src/mesa/drivers/dri/i965/intel_pixel_copy.c
index 858be26..5687c28 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_copy.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_copy.c
@@ -125,7 +125,7 @@ do_blit_copypixels(struct gl_context * ctx,
}
if (ctx-Fog.Enabled ||
- ctx-Texture._EnabledUnits ||
+ ctx-Texture._MaxEnabledTexImageUnit != -1 ||
ctx-FragmentProgram._Enabled) {
perf_debug(glCopyPixels(): Unsupported fragment shader state\n);
return false;
diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_frag.c
b/src/mesa/drivers/dri/nouveau/nv04_state_frag.c
index 17d2781..c48a0b0 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_state_frag.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_state_frag.c
@@ -286,7 +286,7 @@ nv04_emit_tex_env(struct gl_context *ctx, int emit)
/* calculate non-multitex state */
nv04-blend = ~NV04_TEXTURED_TRIANGLE_BLEND_TEXTURE_MAP__MASK;
- if (ctx-Texture._EnabledUnits)
+ if (ctx-Texture._MaxEnabledTexImageUnit != -1)
nv04-blend |= get_texenv_mode(ctx-Texture.Unit[0].EnvMode);
else
nv04-blend |= get_texenv_mode(GL_MODULATE);
diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_frag.c
b/src/mesa/drivers/dri/nouveau/nv10_state_frag.c
index 10f067f..aa7e703 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_state_frag.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_state_frag.c
@@ -353,7 +353,7
Re: [Mesa-dev] [PATCH 6/9] i965/fs: Port untyped surface read support to Broadwell.
Kenneth Graunke kenn...@whitecape.org writes:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
index 856a23e..dae4026 100644
--- a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
@@ -821,6 +821,34 @@
gen8_fs_generator::generate_unpack_half_2x16_split(fs_inst *inst,
}
void
+gen8_fs_generator::generate_untyped_surface_read(fs_inst *ir,
+ struct brw_reg dst,
+ struct brw_reg surf_index)
+{
+ assert(surf_index.file == BRW_IMMEDIATE_VALUE
+ surf_index.type == BRW_REGISTER_TYPE_UD);
+
+ const unsigned num_channels = 1;
unused value?
+
+ unsigned msg_control = 0xe | /* Enable only the R channel */
+ ((dispatch_width == 16 ? 1 : 2) 4); /* Slot Group: SIMD8 or SIMD16 */
In the specs I'm looking at, this is called simd mode, not slot
group (if it was slot group like for aops, I'd be concerned since a
simd16 op needs to use all 16 slots)
pgplMvNUBAP7J.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 4/9] i965: Disassemble atomic operations and other DP:DC1 stuff on Broadwell.
Kenneth Graunke kenn...@whitecape.org writes:
This is similar to what Eric did for Gen7 a little while ago; it also
has support for untyped surface reads.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen8_disasm.c | 65
+
1 file changed, 65 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_disasm.c
b/src/mesa/drivers/dri/i965/gen8_disasm.c
index cc3d864..e0ebd8b 100644
--- a/src/mesa/drivers/dri/i965/gen8_disasm.c
+++ b/src/mesa/drivers/dri/i965/gen8_disasm.c
@@ -222,6 +222,39 @@ static const char *const m_sfid[16] = {
[HSW_SFID_CRE] = cre,
};
+static const char *const dp_dc1_msg_type[16] = {
+ [HSW_DATAPORT_DC_PORT1_UNTYPED_SURFACE_READ] = untyped surface
read,
+ [HSW_DATAPORT_DC_PORT1_UNTYPED_ATOMIC_OP] = DC untyped atomic
op,
+ [HSW_DATAPORT_DC_PORT1_UNTYPED_ATOMIC_OP_SIMD4X2] = DC untyped 4x2
atomic op,
+ [HSW_DATAPORT_DC_PORT1_MEDIA_BLOCK_READ] = DC media block read,
+ [HSW_DATAPORT_DC_PORT1_TYPED_SURFACE_READ]= DC typed surface
read,
+ [HSW_DATAPORT_DC_PORT1_TYPED_ATOMIC_OP] = DC typed atomic,
+ [HSW_DATAPORT_DC_PORT1_TYPED_ATOMIC_OP_SIMD4X2] = DC typed 4x2 atomic
op,
+ [HSW_DATAPORT_DC_PORT1_UNTYPED_SURFACE_WRITE] = DC untyped surface
write,
+ [HSW_DATAPORT_DC_PORT1_MEDIA_BLOCK_WRITE] = DC media block
write,
+ [HSW_DATAPORT_DC_PORT1_ATOMIC_COUNTER_OP] = DC atomic counter
op,
+ [HSW_DATAPORT_DC_PORT1_ATOMIC_COUNTER_OP_SIMD4X2] = DC 4x2 atomic
counter op,
+ [HSW_DATAPORT_DC_PORT1_TYPED_SURFACE_WRITE] = DC typed surface
write,
+};
+
+static const char * const aop[16] = {
+ [BRW_AOP_AND]= and,
+ [BRW_AOP_OR] = or,
+ [BRW_AOP_XOR]= xoo,
xor
+ [BRW_AOP_MOV]= mov,
+ [BRW_AOP_INC]= inc,
+ [BRW_AOP_DEC]= dec,
+ [BRW_AOP_ADD]= add,
+ [BRW_AOP_SUB]= sub,
+ [BRW_AOP_REVSUB] = revsub,
+ [BRW_AOP_IMAX] = imax,
+ [BRW_AOP_IMIN] = imin,
+ [BRW_AOP_UMAX] = umax,
+ [BRW_AOP_UMIN] = umin,
+ [BRW_AOP_CMPWR] = cmpwr,
+ [BRW_AOP_PREDEC] = predec,
+};
+
static const char *const m_math_function[16] = {
[BRW_MATH_FUNCTION_INV]= inv,
[BRW_MATH_FUNCTION_LOG]= log,
@@ -911,6 +944,38 @@ gen8_disassemble(FILE *file, struct gen8_instruction
*inst, int gen)
gen8_function_control(inst));
break;
+ case HSW_SFID_DATAPORT_DATA_CACHE_1:
+ err |= control(file, DP DC1 message type,
+dp_dc1_msg_type, gen8_dp_message_type(inst), space);
+ format(file, , Surface = %d, , gen8_binding_table_index(inst));
+ switch (gen8_dp_message_type(inst)) {
+ case HSW_DATAPORT_DC_PORT1_UNTYPED_ATOMIC_OP:
+ case HSW_DATAPORT_DC_PORT1_TYPED_ATOMIC_OP:
+ case HSW_DATAPORT_DC_PORT1_ATOMIC_COUNTER_OP:
+format(file, SIMD%d,,
+ (gen8_dp_message_control(inst) (1 4)) ? 8 : 16);
+/* fallthrough */
+ case HSW_DATAPORT_DC_PORT1_UNTYPED_ATOMIC_OP_SIMD4X2:
+ case HSW_DATAPORT_DC_PORT1_TYPED_ATOMIC_OP_SIMD4X2:
+ case HSW_DATAPORT_DC_PORT1_ATOMIC_COUNTER_OP_SIMD4X2:
+control(file, atomic op, aop,
+gen8_dp_message_control(inst) 0xf, space);
+break;
+ case HSW_DATAPORT_DC_PORT1_UNTYPED_SURFACE_READ:
+ case HSW_DATAPORT_DC_PORT1_UNTYPED_SURFACE_WRITE:
+ case HSW_DATAPORT_DC_PORT1_TYPED_SURFACE_READ:
+ case HSW_DATAPORT_DC_PORT1_TYPED_SURFACE_WRITE: {
+const char *simd_modes[] = { 4x2, 16, 8 };
static const char *
(otherwise the compiler will emit code to assemble the array on the
stack each time. yay compilers!)
pgpgx_xHfoD0w.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 1/9] i965/fs: Add support for fs_inst::force_writemask_all on Broadwell.
Kenneth Graunke kenn...@whitecape.org writes: This must not have existed when I wrote the original code. The atomic operation header setup code uses this. Other than the tiny comments I had, this series is: Reviewed-by: Eric Anholt e...@anholt.net pgp9IHfdw8ZUH.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 1/4] mesa: Track maximum CurrentTexUnit to reduce glDeleteTextures() overhead.
On 04/25/2014 06:19 PM, Eric Anholt wrote: No more walking 96*6 pointers looking to see if they're the current texture, when we only use the first 2 out of 96 units. -6.26002% +/- 1.87817% effect on cairo runtime on no-fbo-cache glamor (n=36). --- src/mesa/main/mtypes.h | 3 +++ src/mesa/main/texobj.c | 4 +++- src/mesa/main/texstate.c | 6 ++ 3 files changed, 12 insertions(+), 1 deletion(-) The series is: Reviewed-by: Kenneth Graunke kenn...@whitecape.org signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] nouveau: remove cb_dirty, it's never used
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nouveau_buffer.c | 4 +---
src/gallium/drivers/nouveau/nouveau_context.h | 1 -
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index e308ff4..904e2cc 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -521,7 +521,7 @@ nouveau_buffer_transfer_flush_region(struct pipe_context
*pipe,
* was returned was not the real resource's data, this needs to transfer the
* data back to the resource.
*
- * Also marks vbo/cb dirty if the buffer's binding
+ * Also marks vbo dirty based on the buffer's binding
*/
static void
nouveau_buffer_transfer_unmap(struct pipe_context *pipe,
@@ -540,8 +540,6 @@ nouveau_buffer_transfer_unmap(struct pipe_context *pipe,
/* make sure we invalidate dedicated caches */
if (bind (PIPE_BIND_VERTEX_BUFFER | PIPE_BIND_INDEX_BUFFER))
nv-vbo_dirty = TRUE;
- if (bind (PIPE_BIND_CONSTANT_BUFFER))
-nv-cb_dirty = TRUE;
}
util_range_add(buf-valid_buffer_range,
diff --git a/src/gallium/drivers/nouveau/nouveau_context.h
b/src/gallium/drivers/nouveau/nouveau_context.h
index c8d9d84..14608d3 100644
--- a/src/gallium/drivers/nouveau/nouveau_context.h
+++ b/src/gallium/drivers/nouveau/nouveau_context.h
@@ -14,7 +14,6 @@ struct nouveau_context {
struct nouveau_pushbuf *pushbuf;
boolean vbo_dirty;
- boolean cb_dirty;
void (*copy_data)(struct nouveau_context *,
struct nouveau_bo *dst, unsigned, unsigned,
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] nouveau: add ARB_buffer_storage support
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Light testing with dolphin-emu on a G96, seems to mostly work. Saw one or two
glitches (for like 1 frame), but that could well have been a bug in the emu.
It's a little silly to have all this super-super-repetitive code, but short of
rearranging the drivers, no easy way around it.
src/gallium/drivers/nouveau/nouveau_buffer.c | 12 ++--
src/gallium/drivers/nouveau/nv30/nv30_resource.c | 17 +
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 +-
src/gallium/drivers/nouveau/nv30/nv30_vbo.c | 8
src/gallium/drivers/nouveau/nv50/nv50_context.c | 17 +
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-
src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 8
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 17 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 8
10 files changed, 88 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 904e2cc..49ff100 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -342,6 +342,8 @@ nouveau_buffer_should_discard(struct nv04_resource *buf,
unsigned usage)
return FALSE;
if (unlikely(buf-base.bind PIPE_BIND_SHARED))
return FALSE;
+ if (unlikely(usage PIPE_TRANSFER_PERSISTENT))
+ return FALSE;
return buf-mm nouveau_buffer_busy(buf, PIPE_TRANSFER_WRITE);
}
@@ -402,6 +404,9 @@ nouveau_buffer_transfer_map(struct pipe_context *pipe,
!util_ranges_intersect(buf-valid_buffer_range, box-x, box-x +
box-width))
usage |= PIPE_TRANSFER_DISCARD_RANGE | PIPE_TRANSFER_UNSYNCHRONIZED;
+ if (usage PIPE_TRANSFER_PERSISTENT)
+ usage |= PIPE_TRANSFER_UNSYNCHRONIZED;
+
if (buf-domain == NOUVEAU_BO_VRAM) {
if (usage NOUVEAU_TRANSFER_DISCARD) {
/* Set up a staging area for the user to write to. It will be copied
@@ -645,8 +650,11 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
pipe_reference_init(buffer-base.reference, 1);
buffer-base.screen = pscreen;
- if (buffer-base.bind
- (screen-vidmem_bindings screen-sysmem_bindings)) {
+ if (buffer-base.flags (PIPE_RESOURCE_FLAG_MAP_PERSISTENT |
+ PIPE_RESOURCE_FLAG_MAP_COHERENT)) {
+ buffer-domain = NOUVEAU_BO_GART;
+ } else if (buffer-base.bind
+ (screen-vidmem_bindings screen-sysmem_bindings)) {
switch (buffer-base.usage) {
case PIPE_USAGE_DEFAULT:
case PIPE_USAGE_IMMUTABLE:
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_resource.c
b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
index f56ca31..b7a29b9 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_resource.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
@@ -31,6 +31,22 @@
#include nv30/nv30_resource.h
#include nv30/nv30_transfer.h
+static void
+nv30_memory_barrier(struct pipe_context *pipe, unsigned flags)
+{
+ struct nv30_context *nv30 = nv30_context(pipe);
+ int i;
+
+ if (flags PIPE_BARRIER_MAPPED_BUFFER) {
+ for (i = 0; i nv30-num_vtxbufs; ++i) {
+ if (!nv30-vtxbuf[i].buffer)
+continue;
+ if (nv30-vtxbuf[i].buffer-flags PIPE_RESOURCE_FLAG_MAP_PERSISTENT)
+nv30-base.vbo_dirty = TRUE;
+ }
+ }
+}
+
static struct pipe_resource *
nv30_resource_create(struct pipe_screen *pscreen,
const struct pipe_resource *tmpl)
@@ -75,4 +91,5 @@ nv30_resource_init(struct pipe_context *pipe)
pipe-resource_copy_region = nv30_resource_copy_region;
pipe-blit = nv30_blit;
pipe-flush_resource = nv30_flush_resource;
+ pipe-memory_barrier = nv30_memory_barrier;
}
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 8fe3ebf..7157e0c 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -79,6 +79,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_TGSI_TEXCOORD:
case PIPE_CAP_USER_CONSTANT_BUFFERS:
case PIPE_CAP_USER_INDEX_BUFFERS:
+ case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
return 1;
case PIPE_CAP_USER_VERTEX_BUFFERS:
return 0;
@@ -132,7 +133,6 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
case PIPE_CAP_TGSI_VS_LAYER:
case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
case PIPE_CAP_TEXTURE_GATHER_SM5:
- case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_FAKE_SW_MSAA:
case PIPE_CAP_TEXTURE_QUERY_LOD:
case PIPE_CAP_SAMPLE_SHADING:
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_vbo.c
b/src/gallium/drivers/nouveau/nv30/nv30_vbo.c
index d9b3c3e..a4f8085 100644
---
Re: [Mesa-dev] [PATCH 06/10] mesa: Allow srcFormat=GL_DEPTH_STENCIL in _mesa_texstore_xx_xx() functions
On 03/21/2014 03:01 PM, Anuj Phogat wrote:
_mesa_texstore_z24_s8() and _mesa_texstore_z32f_x24s8() are capable of
handling GL_DEPTH_STENCIL format. So, allow it in both the functions.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/main/texstore.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 704ea3f..c30f0de 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -2483,7 +2483,8 @@ _mesa_texstore_z24_s8(TEXSTORE_PARAMS)
srcType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
if (srcFormat == GL_DEPTH_COMPONENT ||
- srcFormat == GL_STENCIL_INDEX) {
+ srcFormat == GL_STENCIL_INDEX ||
+ srcFormat == GL_DEPTH_STENCIL_EXT) {
You should use the undecorated name (just GL_DEPTH_STENCIL).
GLuint *depth = malloc(srcWidth * sizeof(GLuint));
GLubyte *stencil = malloc(srcWidth * sizeof(GLubyte));
@@ -3448,7 +3449,8 @@ _mesa_texstore_z32f_x24s8(TEXSTORE_PARAMS)
srcType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
if (srcFormat == GL_DEPTH_COMPONENT ||
- srcFormat == GL_STENCIL_INDEX) {
+ srcFormat == GL_STENCIL_INDEX ||
+ srcFormat == GL_DEPTH_STENCIL_EXT) {
GLint img, row;
const GLint srcRowStride
= _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] mesa: Add entry for extension ARB_texture_stencil8
Patches 1, 2, 4, 5, 6 (with the small change suggested), 7, 8, 9, and 10 are all Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 03/21/2014 03:01 PM, Anuj Phogat wrote: Cc: mesa-sta...@lists.freedesktop.org Signed-off-by: Anuj Phogat anuj.pho...@gmail.com --- src/mesa/main/mtypes.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index a0d893c..0b754b1 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -3535,6 +3535,7 @@ struct gl_extensions GLboolean ARB_shading_language_420pack; GLboolean ARB_shadow; GLboolean ARB_stencil_texturing; + GLboolean ARB_texture_stencil8; GLboolean ARB_sync; GLboolean ARB_texture_border_clamp; GLboolean ARB_texture_buffer_object; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 13/21] glsl: Track explicitly set varying locations
Sorry to waste more of your time but this is driving me nuts. For my own
education :) can you tell me how this code works? Maybe I'm making
myself look silly by not understanding some basic concept of c++. But to
me it looks like var-data.location already contains the explicit
location and you are just assigning it the value it already contains. Is
there some weird operator overloading going on here?
On Wed, 2014-04-30 at 07:42 -0700, Ian Romanick wrote:
On 04/29/2014 10:57 PM, Timothy Arceri wrote:
Looks like this patch should have been dropped with the removal of
user_location?
Nope. We still need to track the location set in the shader. Now it's
tracked in the same location field as, say, vertex shader inputs instead
of having a special field.
On Tue, 2014-04-29 at 17:52 -0700, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ast_to_hir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 0411bef..e1192ed 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2268,6 +2268,8 @@ validate_explicit_location(const struct
ast_type_qualifier *qual,
assert(!Unexpected shader type);
break;
}
+
+ var-data.location = var-data.location;
} else {
var-data.location = qual-location;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/21] linker: Modify cross_validate_outputs_to_inputs to match using explicit locations
On 04/30/2014 12:40 PM, Eric Anholt wrote:
Ian Romanick i...@freedesktop.org writes:
From: Ian Romanick ian.d.roman...@intel.com
This will be used for GL_ARB_separate_shader_objects. That extension
not only allows separable shaders to rendezvous by location, but it also
allows traditionally linked shaders to rendezvous by location. The spec
says:
36. How does the behavior of input/output interface matching differ
between separable programs and non-separable programs?
RESOLVED: The rules for matching individual variables or block
members between stages are identical for separable and
non-separable programs, with one exception -- matching variables
of different type with the same location, as discussed in issue
34, applies only to separable programs.
However, the ability to enforce matching requirements differs
between program types. In non-separable programs, both sides of
an interface are contained in the same linked program. In this
case, if the linker detects a mismatch, it will generate a link
error.
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index e5c2751..232e230 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -172,6 +172,7 @@ cross_validate_outputs_to_inputs(struct
gl_shader_program *prog,
gl_shader *producer, gl_shader *consumer)
{
glsl_symbol_table parameters;
+ ir_variable *explicit_locations[MAX_VARYING] = { NULL, };
/* Find all shader outputs in the producer stage.
*/
@@ -181,7 +182,26 @@ cross_validate_outputs_to_inputs(struct
gl_shader_program *prog,
if ((var == NULL) || (var-data.mode != ir_var_shader_out))
continue;
- parameters.add_variable(var);
+ if (!var-data.explicit_location
+ || var-data.location VARYING_SLOT_VAR0)
+ parameters.add_variable(var);
+ else {
+ /* User-defined varyings with explicit locations are handled
+ * differently because they do not need to have matching names.
+ */
+ const unsigned idx = var-data.location - VARYING_SLOT_VAR0;
+
+ if (explicit_locations[idx] != NULL) {
+linker_error(prog,
+ %s shader has multiple outputs explicitly
+ assigned to location %d\n,
+ _mesa_shader_stage_to_string(producer-Stage),
+ idx);
+return;
Relevant citation:
A program will fail to link if any two fragment shader output variables
are assigned to the same location and index, or if any two output
variables from the same non-fragment shader stage are assigned to the same
location.
I think this has a problem of not throwing an error when your explicit
location array overlaps your explicit location scalar, but I don't think
it's that important.
I think you're correct on both counts. I'm not sure if the
closed-source drivers enforce this either. More tests.
@@ -1051,8 +1091,13 @@ namespace linker {
bool
populate_consumer_input_sets(void *mem_ctx, exec_list *ir,
hash_table *consumer_inputs,
- hash_table *consumer_interface_inputs)
+ hash_table *consumer_interface_inputs,
+ ir_variable
*consumer_inputs_with_locations[MAX_VARYING])
{
+ memset(consumer_inputs_with_locations,
+ 0,
+ sizeof(consumer_inputs_with_locations[0]) * MAX_VARYING);
+
foreach_list(node, ir) {
ir_variable *const input_var = ((ir_instruction *)
node)-as_variable();
@@ -1060,7 +1105,13 @@ populate_consumer_input_sets(void *mem_ctx, exec_list
*ir,
if (input_var-type-is_interface())
return false;
- if (input_var-get_interface_type() != NULL) {
+ if (input_var-data.explicit_location) {
+/* FINISHME: If the input is an interface, array, or structure,
it
+ * FINISHME: will use multiple slots.
+ */
+consumer_inputs_with_locations[input_var-data.location] =
+ input_var;
I think this FINISHME shouldn't be there. It looks like
assign_varying_locations() only cares about finding the ir_variable at
the start of a contiguous location block. My reasoning:
For !producer, consumer_inputs_with_locations isn't used.
For !consumer, consumer_inputs_with_locations is empty.
For consumer producer, if you were trying to set some ir_variable to
the middle of a location block on the other side of producer/consumer,
cross_validate_outputs_to_inputs() should be link-erroring due to either
type mismatch or location overlaps. If the variables do match up, then
they've got a matching data.location and you only looked at
Re: [Mesa-dev] [00/21] Last of SSO, take 47
On 04/30/2014 12:41 PM, Eric Anholt wrote: Ian Romanick i...@freedesktop.org writes: A lot the patches in this series were slightly reworked to incorporate Eric's feedback (remove ir_variable::user_location) on the previous attempt. Other than that change, I patch 1 is new, and patch 16 adds previously missing display list support. Patch 2, 3, 13, 16, 17, 18, 20, 21 are: Reviewed-by: Eric Anholt e...@anholt.net I think my patch 15 comments were minor, and if you agree with them (meaning I actually understood what was going on), then apply the r-b there too. Patch 19 is: Acked-by: Eric Anholt e...@anholt.net Patch 14 I don't think is needed (since we've got explicit locations being assigned to corresponding varying slots). The sorting is so that a vertex shader that does out vec4 a; out vec4 b; and a fragment shader that does in vec4 b; in vec4 a; will assign the same locations for a and b. If both shaders have the same set of varyings, they'll all get the same locations. Without sorting, we assign the locations based on the order in which variables appear in the shader text. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] osmesa: (trivial) fix typo
From: Roland Scheidegger srol...@vmware.com c703658b3965bf2e4f3593a0d54be03e8e8b1436 used Texture.MaxEnabledTexImageUnit instead of Texture._MaxEnabledTexImageUnit. --- src/mesa/drivers/osmesa/osmesa.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/osmesa/osmesa.c b/src/mesa/drivers/osmesa/osmesa.c index 6026fd5..ab9ac31 100644 --- a/src/mesa/drivers/osmesa/osmesa.c +++ b/src/mesa/drivers/osmesa/osmesa.c @@ -207,7 +207,7 @@ osmesa_choose_line_function( struct gl_context *ctx ) if (ctx-RenderMode != GL_RENDER || ctx-Line.SmoothFlag || - ctx-Texture.MaxEnabledTexImageUnit == -1 || + ctx-Texture._MaxEnabledTexImageUnit == -1 || ctx-Light.ShadeModel != GL_FLAT || ctx-Line.Width != 1.0F || ctx-Line.StippleFlag || -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallivm: fix 2 leaks in disassembly code
From: Roland Scheidegger srol...@vmware.com don't leak the MCSubtargetInfo (not really big, was already fixed with llvm master) and TargetMachine (big). While this is only used for debugging the leak is large enough to get you into trouble in some cases. Tested with llvm 3.1 and master. Before (llvm 3.1), GALLIVM_DEBUG=asm glxgears: ==14152== LEAK SUMMARY: ==14152==definitely lost: 105,228 bytes in 20 blocks ==14152==indirectly lost: 347,252 bytes in 261 blocks ==14152== possibly lost: 866,625 bytes in 1,453 blocks ==14152==still reachable: 7,344,677 bytes in 6,494 blocks ==14152== suppressed: 0 bytes in 0 blocks After: ==13799== LEAK SUMMARY: ==13799==definitely lost: 3,108 bytes in 6 blocks ==13799==indirectly lost: 0 bytes in 0 blocks ==13799== possibly lost: 804,143 bytes in 1,429 blocks ==13799==still reachable: 7,314,267 bytes in 6,473 blocks ==13799== suppressed: 0 bytes in 0 blocks --- src/gallium/auxiliary/gallivm/lp_bld_debug.cpp |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp index 541cf9e..7e43b51 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp +++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp @@ -36,6 +36,7 @@ #if HAVE_LLVM = 0x0300 #include llvm/Support/TargetRegistry.h +#include llvm/MC/MCSubtargetInfo.h #else /* HAVE_LLVM 0x0300 */ #include llvm/Target/TargetRegistry.h #endif /* HAVE_LLVM 0x0300 */ @@ -254,7 +255,7 @@ disassemble(const void* func, llvm::raw_ostream Out) OwningPtrMCContext MCCtx(new MCContext(AsmInfo.get(), MRI.get(), 0)); OwningPtrconst MCDisassembler DisAsm(T-createMCDisassembler(*STI, *MCCtx)); #elif HAVE_LLVM = 0x0300 - const MCSubtargetInfo *STI = T-createMCSubtargetInfo(Triple, sys::getHostCPUName(), ); + OwningPtrconst MCSubtargetInfo STI(T-createMCSubtargetInfo(Triple, sys::getHostCPUName(), )); OwningPtrconst MCDisassembler DisAsm(T-createMCDisassembler(*STI)); #else OwningPtrconst MCDisassembler DisAsm(T-createMCDisassembler()); @@ -294,11 +295,11 @@ disassemble(const void* func, llvm::raw_ostream Out) #if defined(DEBUG) || defined(PROFILE) options.NoFramePointerElim = true; #endif - TargetMachine *TM = T-createTargetMachine(Triple, sys::getHostCPUName(), , options); + OwningPtrTargetMachine TM(T-createTargetMachine(Triple, sys::getHostCPUName(), , options)); #elif HAVE_LLVM == 0x0300 - TargetMachine *TM = T-createTargetMachine(Triple, sys::getHostCPUName(), ); + OwningPtrTargetMachine TM(T-createTargetMachine(Triple, sys::getHostCPUName(), )); #else - TargetMachine *TM = T-createTargetMachine(Triple, ); + OwningPtrTargetMachine TM(T-createTargetMachine(Triple, )); #endif const TargetInstrInfo *TII = TM-getInstrInfo(); -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] R600/SI: Add processor type for Mullins.
From: Samuel Li samuel...@amd.com Signed-off-by: Samuel Li samuel...@amd.com Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- lib/Target/R600/Processors.td | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td index fde4481..ce17d7c 100644 --- a/lib/Target/R600/Processors.td +++ b/lib/Target/R600/Processors.td @@ -106,3 +106,5 @@ def : Prockabini, SI_Itin, [FeatureSeaIslands]; def : Prockaveri, SI_Itin, [FeatureSeaIslands]; def : Prochawaii, SI_Itin, [FeatureSeaIslands]; + +def : Procmullins,SI_Itin, [FeatureSeaIslands]; -- 1.8.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx/drisw: fix memory leak when destroying screen.
From: Roland Scheidegger srol...@vmware.com --- src/glx/drisw_glx.c |1 + 1 file changed, 1 insertion(+) diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c index 751626b..5885b66 100644 --- a/src/glx/drisw_glx.c +++ b/src/glx/drisw_glx.c @@ -619,6 +619,7 @@ driswDestroyScreen(struct glx_screen *base) psc-driScreen = NULL; if (psc-driver) dlclose(psc-driver); + free(psc); } #define SWRAST_DRIVER_NAME swrast -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 13/21] glsl: Track explicitly set varying locations
On 04/30/2014 02:26 PM, Timothy Arceri wrote:
Sorry to waste more of your time but this is driving me nuts. For my own
education :) can you tell me how this code works? Maybe I'm making
myself look silly by not understanding some basic concept of c++. But to
me it looks like var-data.location already contains the explicit
location and you are just assigning it the value it already contains. Is
there some weird operator overloading going on here?
I went back and looked at the code so that I could give a good answer...
and you were right in the first place. :) Good catch. I'll remove this
patch from the series.
On Wed, 2014-04-30 at 07:42 -0700, Ian Romanick wrote:
On 04/29/2014 10:57 PM, Timothy Arceri wrote:
Looks like this patch should have been dropped with the removal of
user_location?
Nope. We still need to track the location set in the shader. Now it's
tracked in the same location field as, say, vertex shader inputs instead
of having a special field.
On Tue, 2014-04-29 at 17:52 -0700, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/glsl/ast_to_hir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 0411bef..e1192ed 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2268,6 +2268,8 @@ validate_explicit_location(const struct
ast_type_qualifier *qual,
assert(!Unexpected shader type);
break;
}
+
+ var-data.location = var-data.location;
} else {
var-data.location = qual-location;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] osmesa: (trivial) fix typo
On 04/30/2014 04:41 PM, srol...@vmware.com wrote: From: Roland Scheidegger srol...@vmware.com c703658b3965bf2e4f3593a0d54be03e8e8b1436 used Texture.MaxEnabledTexImageUnit instead of Texture._MaxEnabledTexImageUnit. --- src/mesa/drivers/osmesa/osmesa.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/osmesa/osmesa.c b/src/mesa/drivers/osmesa/osmesa.c index 6026fd5..ab9ac31 100644 --- a/src/mesa/drivers/osmesa/osmesa.c +++ b/src/mesa/drivers/osmesa/osmesa.c @@ -207,7 +207,7 @@ osmesa_choose_line_function( struct gl_context *ctx ) if (ctx-RenderMode != GL_RENDER || ctx-Line.SmoothFlag || - ctx-Texture.MaxEnabledTexImageUnit == -1 || + ctx-Texture._MaxEnabledTexImageUnit == -1 || ctx-Light.ShadeModel != GL_FLAT || ctx-Line.Width != 1.0F || ctx-Line.StippleFlag || Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx/drisw: fix memory leak when destroying screen.
On 04/30/2014 05:04 PM, srol...@vmware.com wrote: From: Roland Scheidegger srol...@vmware.com --- src/glx/drisw_glx.c |1 + 1 file changed, 1 insertion(+) diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c index 751626b..5885b66 100644 --- a/src/glx/drisw_glx.c +++ b/src/glx/drisw_glx.c @@ -619,6 +619,7 @@ driswDestroyScreen(struct glx_screen *base) psc-driScreen = NULL; if (psc-driver) dlclose(psc-driver); + free(psc); } #define SWRAST_DRIVER_NAME swrast Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radeonsi: add Mullins pci ids.
From: Samuel Li samuel...@amd.com Signed-off-by: Samuel Li samuel...@amd.com Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- include/pci_ids/radeonsi_pci_ids.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/pci_ids/radeonsi_pci_ids.h b/include/pci_ids/radeonsi_pci_ids.h index 7b42d5e..5099c74 100644 --- a/include/pci_ids/radeonsi_pci_ids.h +++ b/include/pci_ids/radeonsi_pci_ids.h @@ -97,6 +97,23 @@ CHIPSET(0x983D, KABINI_983D, KABINI) CHIPSET(0x983E, KABINI_983E, KABINI) CHIPSET(0x983F, KABINI_983F, KABINI) +CHIPSET(0x9850, MULLINS_9850, MULLINS) +CHIPSET(0x9851, MULLINS_9851, MULLINS) +CHIPSET(0x9852, MULLINS_9852, MULLINS) +CHIPSET(0x9853, MULLINS_9853, MULLINS) +CHIPSET(0x9854, MULLINS_9854, MULLINS) +CHIPSET(0x9855, MULLINS_9855, MULLINS) +CHIPSET(0x9856, MULLINS_9856, MULLINS) +CHIPSET(0x9857, MULLINS_9857, MULLINS) +CHIPSET(0x9858, MULLINS_9858, MULLINS) +CHIPSET(0x9859, MULLINS_9859, MULLINS) +CHIPSET(0x985A, MULLINS_985A, MULLINS) +CHIPSET(0x985B, MULLINS_985B, MULLINS) +CHIPSET(0x985C, MULLINS_985C, MULLINS) +CHIPSET(0x985D, MULLINS_985D, MULLINS) +CHIPSET(0x985E, MULLINS_985E, MULLINS) +CHIPSET(0x985F, MULLINS_985F, MULLINS) + CHIPSET(0x1304, KAVERI_1304, KAVERI) CHIPSET(0x1305, KAVERI_1305, KAVERI) CHIPSET(0x1306, KAVERI_1306, KAVERI) -- 1.8.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radeonsi: add support for Mullins asics.
From: Samuel Li samuel...@amd.com
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
src/gallium/drivers/radeonsi/si_state.c | 2 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
4 files changed, 6 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 957186a..600f89b 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -293,6 +293,7 @@ static const char* r600_get_name(struct pipe_screen*
pscreen)
case CHIP_KAVERI: return AMD KAVERI;
case CHIP_KABINI: return AMD KABINI;
case CHIP_HAWAII: return AMD HAWAII;
+ case CHIP_MULLINS: return AMD MULLINS;
default: return AMD unknown;
}
}
@@ -410,6 +411,7 @@ const char *r600_get_llvm_processor_name(enum radeon_family
family)
case CHIP_KABINI: return kabini;
case CHIP_KAVERI: return kaveri;
case CHIP_HAWAII: return hawaii;
+ case CHIP_MULLINS: return mullins;
default: return ;
#endif
}
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 80f54e2..6d5408b 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3101,6 +3101,8 @@ void si_init_config(struct si_context *sctx)
/* XXX todo */
case CHIP_KABINI:
/* XXX todo */
+ case CHIP_MULLINS:
+ /* XXX todo */
default:
si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x);
si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1,
0x);
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 7618316..e54e79e 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -276,6 +276,7 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws)
case CHIP_KAVERI:
case CHIP_KABINI:
case CHIP_HAWAII:
+case CHIP_MULLINS:
ws-info.chip_class = CIK;
break;
}
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index 1cb17bb..2d13550 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -130,6 +130,7 @@ enum radeon_family {
CHIP_KAVERI,
CHIP_KABINI,
CHIP_HAWAII,
+CHIP_MULLINS,
CHIP_LAST,
};
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: add support for Mullins asics.
For the series:
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Thu, May 1, 2014 at 1:30 AM, Alex Deucher alexdeuc...@gmail.com wrote:
From: Samuel Li samuel...@amd.com
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
src/gallium/drivers/radeonsi/si_state.c | 2 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
4 files changed, 6 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 957186a..600f89b 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -293,6 +293,7 @@ static const char* r600_get_name(struct pipe_screen*
pscreen)
case CHIP_KAVERI: return AMD KAVERI;
case CHIP_KABINI: return AMD KABINI;
case CHIP_HAWAII: return AMD HAWAII;
+ case CHIP_MULLINS: return AMD MULLINS;
default: return AMD unknown;
}
}
@@ -410,6 +411,7 @@ const char *r600_get_llvm_processor_name(enum
radeon_family family)
case CHIP_KABINI: return kabini;
case CHIP_KAVERI: return kaveri;
case CHIP_HAWAII: return hawaii;
+ case CHIP_MULLINS: return mullins;
default: return ;
#endif
}
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 80f54e2..6d5408b 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3101,6 +3101,8 @@ void si_init_config(struct si_context *sctx)
/* XXX todo */
case CHIP_KABINI:
/* XXX todo */
+ case CHIP_MULLINS:
+ /* XXX todo */
default:
si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x);
si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1,
0x);
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 7618316..e54e79e 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -276,6 +276,7 @@ static boolean do_winsys_init(struct radeon_drm_winsys
*ws)
case CHIP_KAVERI:
case CHIP_KABINI:
case CHIP_HAWAII:
+case CHIP_MULLINS:
ws-info.chip_class = CIK;
break;
}
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index 1cb17bb..2d13550 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -130,6 +130,7 @@ enum radeon_family {
CHIP_KAVERI,
CHIP_KABINI,
CHIP_HAWAII,
+CHIP_MULLINS,
CHIP_LAST,
};
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallivm: fix 2 leaks in disassembly code
On 04/30/2014 04:41 PM, srol...@vmware.com wrote: From: Roland Scheidegger srol...@vmware.com don't leak the MCSubtargetInfo (not really big, was already fixed with llvm master) and TargetMachine (big). While this is only used for debugging the leak is large enough to get you into trouble in some cases. Tested with llvm 3.1 and master. Before (llvm 3.1), GALLIVM_DEBUG=asm glxgears: ==14152== LEAK SUMMARY: ==14152==definitely lost: 105,228 bytes in 20 blocks ==14152==indirectly lost: 347,252 bytes in 261 blocks ==14152== possibly lost: 866,625 bytes in 1,453 blocks ==14152==still reachable: 7,344,677 bytes in 6,494 blocks ==14152== suppressed: 0 bytes in 0 blocks After: ==13799== LEAK SUMMARY: ==13799==definitely lost: 3,108 bytes in 6 blocks ==13799==indirectly lost: 0 bytes in 0 blocks ==13799== possibly lost: 804,143 bytes in 1,429 blocks ==13799==still reachable: 7,314,267 bytes in 6,473 blocks ==13799== suppressed: 0 bytes in 0 blocks --- src/gallium/auxiliary/gallivm/lp_bld_debug.cpp |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp index 541cf9e..7e43b51 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp +++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp @@ -36,6 +36,7 @@ #if HAVE_LLVM = 0x0300 #include llvm/Support/TargetRegistry.h +#include llvm/MC/MCSubtargetInfo.h #else /* HAVE_LLVM 0x0300 */ #include llvm/Target/TargetRegistry.h #endif /* HAVE_LLVM 0x0300 */ @@ -254,7 +255,7 @@ disassemble(const void* func, llvm::raw_ostream Out) OwningPtrMCContext MCCtx(new MCContext(AsmInfo.get(), MRI.get(), 0)); OwningPtrconst MCDisassembler DisAsm(T-createMCDisassembler(*STI, *MCCtx)); #elif HAVE_LLVM = 0x0300 - const MCSubtargetInfo *STI = T-createMCSubtargetInfo(Triple, sys::getHostCPUName(), ); + OwningPtrconst MCSubtargetInfo STI(T-createMCSubtargetInfo(Triple, sys::getHostCPUName(), )); OwningPtrconst MCDisassembler DisAsm(T-createMCDisassembler(*STI)); #else OwningPtrconst MCDisassembler DisAsm(T-createMCDisassembler()); @@ -294,11 +295,11 @@ disassemble(const void* func, llvm::raw_ostream Out) #if defined(DEBUG) || defined(PROFILE) options.NoFramePointerElim = true; #endif - TargetMachine *TM = T-createTargetMachine(Triple, sys::getHostCPUName(), , options); + OwningPtrTargetMachine TM(T-createTargetMachine(Triple, sys::getHostCPUName(), , options)); #elif HAVE_LLVM == 0x0300 - TargetMachine *TM = T-createTargetMachine(Triple, sys::getHostCPUName(), ); + OwningPtrTargetMachine TM(T-createTargetMachine(Triple, sys::getHostCPUName(), )); #else - TargetMachine *TM = T-createTargetMachine(Triple, ); + OwningPtrTargetMachine TM(T-createTargetMachine(Triple, )); #endif const TargetInstrInfo *TII = TM-getInstrInfo(); I'm not too familiar with that code, but looks OK AFAICT. Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [00/21] Last of SSO, take 47
Ian Romanick i...@freedesktop.org writes: On 04/30/2014 12:41 PM, Eric Anholt wrote: Ian Romanick i...@freedesktop.org writes: A lot the patches in this series were slightly reworked to incorporate Eric's feedback (remove ir_variable::user_location) on the previous attempt. Other than that change, I patch 1 is new, and patch 16 adds previously missing display list support. Patch 2, 3, 13, 16, 17, 18, 20, 21 are: Reviewed-by: Eric Anholt e...@anholt.net I think my patch 15 comments were minor, and if you agree with them (meaning I actually understood what was going on), then apply the r-b there too. Patch 19 is: Acked-by: Eric Anholt e...@anholt.net Patch 14 I don't think is needed (since we've got explicit locations being assigned to corresponding varying slots). The sorting is so that a vertex shader that does out vec4 a; out vec4 b; and a fragment shader that does in vec4 b; in vec4 a; will assign the same locations for a and b. If both shaders have the same set of varyings, they'll all get the same locations. Without sorting, we assign the locations based on the order in which variables appear in the shader text. In SSO, we aren't assigning locations, because we have explicit locations for everything. In non-SSO, we either have explicit locations, or we're matching ir_variables up by name and assigning the dynamic locations to the same name across both producer and consumer. pgpZggEugACbe.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 1/2] radeonsi: add support for Mullins asics.
BTW, we may need to release libdrm_radeon first before we can commit this.
Marek
On Thu, May 1, 2014 at 1:30 AM, Alex Deucher alexdeuc...@gmail.com wrote:
From: Samuel Li samuel...@amd.com
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
src/gallium/drivers/radeonsi/si_state.c | 2 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
4 files changed, 6 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 957186a..600f89b 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -293,6 +293,7 @@ static const char* r600_get_name(struct pipe_screen*
pscreen)
case CHIP_KAVERI: return AMD KAVERI;
case CHIP_KABINI: return AMD KABINI;
case CHIP_HAWAII: return AMD HAWAII;
+ case CHIP_MULLINS: return AMD MULLINS;
default: return AMD unknown;
}
}
@@ -410,6 +411,7 @@ const char *r600_get_llvm_processor_name(enum
radeon_family family)
case CHIP_KABINI: return kabini;
case CHIP_KAVERI: return kaveri;
case CHIP_HAWAII: return hawaii;
+ case CHIP_MULLINS: return mullins;
default: return ;
#endif
}
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 80f54e2..6d5408b 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3101,6 +3101,8 @@ void si_init_config(struct si_context *sctx)
/* XXX todo */
case CHIP_KABINI:
/* XXX todo */
+ case CHIP_MULLINS:
+ /* XXX todo */
default:
si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG,
0x);
si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1,
0x);
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 7618316..e54e79e 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -276,6 +276,7 @@ static boolean do_winsys_init(struct radeon_drm_winsys
*ws)
case CHIP_KAVERI:
case CHIP_KABINI:
case CHIP_HAWAII:
+case CHIP_MULLINS:
ws-info.chip_class = CIK;
break;
}
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index 1cb17bb..2d13550 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -130,6 +130,7 @@ enum radeon_family {
CHIP_KAVERI,
CHIP_KABINI,
CHIP_HAWAII,
+CHIP_MULLINS,
CHIP_LAST,
};
--
1.8.3.1
___
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 05/21] meta: Fix saving the program pipeline state
On Thu, May 1, 2014 at 12:11 AM, Ian Romanick i...@freedesktop.org wrote:
On 04/29/2014 08:43 PM, Chia-I Wu wrote:
On Wed, Apr 30, 2014 at 8:52 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
This code was broken in some odd ways before. Too much state was being
saved, it was being restored in the wrong order, and in the wrong way.
The biggest problem was that the pipeline object was restored before
restoring the programs attached to the default pipeline.
Fixes a regression in the glean texgen test.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Eric Anholt e...@anholt.net
---
src/mesa/drivers/common/meta.c | 34 --
src/mesa/drivers/common/meta.h | 1 -
2 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index ac27abb..92bc185 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -577,11 +577,15 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield
state)
}
if (ctx-Extensions.ARB_separate_shader_objects) {
- /* Warning it must be done before _mesa_UseProgram call */
- _mesa_reference_pipeline_object(ctx, save-_Shader,
ctx-_Shader);
- _mesa_reference_pipeline_object(ctx, save-Pipeline,
- ctx-Pipeline.Current);
- _mesa_BindProgramPipeline(0);
+ /* Warning: This must be done before saving the current programs.
+ * Otherwise the programs attached to the pipeline will be saved
+ * instead of the programs attached to the default pipeline.
+ */
+ if (ctx-Pipeline.Current != ctx-Pipeline.Default) {
+_mesa_reference_pipeline_object(ctx, save-Pipeline,
+ctx-Pipeline.Current);
+_mesa_BindProgramPipeline(0);
+ }
}
for (i = 0; i MESA_SHADER_STAGES; i++) {
@@ -929,14 +933,6 @@ _mesa_meta_end(struct gl_context *ctx)
save-ATIFragmentShaderEnabled);
}
- /* Warning it must be done before _mesa_use_shader_program call */
- if (ctx-Extensions.ARB_separate_shader_objects) {
- _mesa_reference_pipeline_object(ctx, ctx-_Shader,
save-_Shader);
- _mesa_reference_pipeline_object(ctx, ctx-Pipeline.Current,
- save-Pipeline);
- _mesa_reference_pipeline_object(ctx, save-Pipeline, NULL);
- }
-
if (ctx-Extensions.ARB_vertex_shader) {
_mesa_use_shader_program(ctx, GL_VERTEX_SHADER,
save-Shader[MESA_SHADER_VERTEX],
@@ -956,10 +952,20 @@ _mesa_meta_end(struct gl_context *ctx)
_mesa_reference_shader_program(ctx, ctx-_Shader-ActiveProgram,
save-ActiveShader);
+ /* Warning: This must be done after _mesa_use_shader_program call.
+ * Otherwise the programs will be restored to the pipeline object
+ * instead of to the default pipeline.
+ */
+ if (save-Pipeline) {
+ assert(ctx-Extensions.ARB_separate_shader_objects);
+ _mesa_bind_pipeline(ctx, save-Pipeline);
This issue does not appear to be fixed
http://lists.freedesktop.org/archives/mesa-dev/2014-April/057999.html
The attached change to piglit triggers it.
What should the result have been with that patch? I tried that with my
current sso6 branch, and
arb_separate_shader_objects-rendezvous_by_location passes with or
without this patch.
The patch should not affect the result, but I got this error after applying it
$ ./bin/arb_separate_shader_object-rendezvous_by_location -auto
Probe color at (0,0)
Expected: 0.00 1.00 0.00 1.00
Observed: 1.00 1.00 1.00 1.00
PIGLIT: {'result': 'fail' }
I am also on sso6 (except that I merged it to master).
+
+ _mesa_reference_pipeline_object(ctx, save-Pipeline, NULL);
+ }
+
for (i = 0; i MESA_SHADER_STAGES; i++)
_mesa_reference_shader_program(ctx, save-Shader[i], NULL);
_mesa_reference_shader_program(ctx, save-ActiveShader, NULL);
- _mesa_reference_pipeline_object(ctx, save-_Shader, NULL);
}
if (state MESA_META_STENCIL_TEST) {
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index fde4f9a..0a34792 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -121,7 +121,6 @@ struct save_state
GLboolean ATIFragmentShaderEnabled;
struct gl_shader_program *Shader[MESA_SHADER_STAGES];
struct gl_shader_program *ActiveShader;
- struct gl_pipeline_object *_Shader;
struct gl_pipeline_object *Pipeline;
/** MESA_META_STENCIL_TEST */
--
1.8.1.4
Re: [Mesa-dev] [PATCH 15/18] i965: Drop region usage from DRI2 winsys-allocated buffers.
On Tue, Apr 29, 2014 at 4:34 PM, Eric Anholt e...@anholt.net wrote:
---
src/mesa/drivers/dri/i965/intel_screen.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
Oh, right, I forgot about the __DRIbuffer usage. This really show how
intel_region just added redundancy.
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index ab95a39..454f1cb 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1371,7 +1371,7 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
struct intel_buffer {
__DRIbuffer base;
- struct intel_region *region;
+ drm_intel_bo *bo;
};
static __DRIbuffer *
@@ -1390,23 +1390,27 @@ intelAllocateBuffer(__DRIscreen *screen,
return NULL;
/* The front and back buffers are color buffers, which are X tiled. */
- intelBuffer-region = intel_region_alloc(intelScreen,
-I915_TILING_X,
-format / 8,
-width,
-height,
-true);
-
- if (intelBuffer-region == NULL) {
+ uint32_t tiling = I915_TILING_X;
+ unsigned long pitch;
+ int cpp = format / 8;
+ intelBuffer-bo = drm_intel_bo_alloc_tiled(intelScreen-bufmgr,
+ intelAllocateBuffer,
+ width,
+ height,
+ cpp,
+ tiling, pitch,
+ BO_ALLOC_FOR_RENDER);
+
+ if (intelBuffer-bo == NULL) {
free(intelBuffer);
return NULL;
}
- drm_intel_bo_flink(intelBuffer-region-bo, intelBuffer-base.name);
+ drm_intel_bo_flink(intelBuffer-bo, intelBuffer-base.name);
intelBuffer-base.attachment = attachment;
- intelBuffer-base.cpp = intelBuffer-region-cpp;
- intelBuffer-base.pitch = intelBuffer-region-pitch;
+ intelBuffer-base.cpp = cpp;
+ intelBuffer-base.pitch = pitch;
return intelBuffer-base;
}
@@ -1416,7 +1420,7 @@ intelReleaseBuffer(__DRIscreen *screen, __DRIbuffer
*buffer)
{
struct intel_buffer *intelBuffer = (struct intel_buffer *) buffer;
- intel_region_release(intelBuffer-region);
+ drm_intel_bo_unreference(intelBuffer-bo);
free(intelBuffer);
}
--
1.9.2
___
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 10/18] i965: Make intel_set_texture_region just take a BO and pitch.
On Tue, Apr 29, 2014 at 4:34 PM, Eric Anholt e...@anholt.net wrote:
I want to do this to get the region removed from DRI images. However, it
does mean that we won't share the intel_region between the rb and the
texture for texture_from_pixmap. I think that's fine.
My review got stuck on this one as I though we were going to put a
miptree in the __DRIimage struct and then we could just share the
miptree instead. But you have a good point that that's problematic
from a thread-safety point of view and this works just as well, if not
better (less overhead). This and the rest of the series
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/intel_tex_image.c | 56
++---
1 file changed, 27 insertions(+), 29 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index 46cbaf7..b7fab39 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -201,22 +201,21 @@ intelTexImage(struct gl_context * ctx,
/**
- * Binds a region to a texture image, like it was uploaded by glTexImage2D().
+ * Binds a BO to a texture image, as if it was uploaded by glTexImage2D().
*
* Used for GLX_EXT_texture_from_pixmap and EGL image extensions,
*/
static void
-intel_set_texture_image_region(struct gl_context *ctx,
- struct gl_texture_image *image,
- struct intel_region *region,
- GLenum target,
- GLenum internalFormat,
- mesa_format format,
- uint32_t offset,
- GLuint width,
- GLuint height,
- GLuint tile_x,
- GLuint tile_y)
+intel_set_texture_image_bo(struct gl_context *ctx,
+ struct gl_texture_image *image,
+ drm_intel_bo *bo,
+ GLenum target,
+ GLenum internalFormat,
+ mesa_format format,
+ uint32_t offset,
+ GLuint width, GLuint height,
+ GLuint pitch,
+ GLuint tile_x, GLuint tile_y)
{
struct brw_context *brw = brw_context(ctx);
struct intel_texture_image *intel_image = intel_texture_image(image);
@@ -230,13 +229,10 @@ intel_set_texture_image_region(struct gl_context *ctx,
ctx-Driver.FreeTextureImageBuffer(ctx, image);
- intel_image-mt = intel_miptree_create_layout(brw, target,
image-TexFormat,
- 0, 0,
- width, height, 1,
- true, 0 /* num_samples */);
+ intel_image-mt = intel_miptree_create_for_bo(brw, bo, image-TexFormat,
+ 0, width, height, pitch);
if (intel_image-mt == NULL)
return;
- intel_region_reference(intel_image-mt-region, region);
intel_image-mt-total_width = width;
intel_image-mt-total_height = height;
intel_image-mt-level[0].slice[0].x_offset = tile_x;
@@ -258,8 +254,8 @@ intel_set_texture_image_region(struct gl_context *ctx,
intel_texobj-needs_validate = true;
intel_image-mt-offset = offset;
- assert(region-pitch % region-cpp == 0);
- intel_image-base.RowStride = region-pitch / region-cpp;
+ assert(pitch % intel_image-mt-region-cpp == 0);
+ intel_image-base.RowStride = pitch / intel_image-mt-region-cpp;
/* Immediately validate the image to the object. */
intel_miptree_reference(intel_texobj-mt, intel_image-mt);
@@ -312,11 +308,12 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
_mesa_lock_texture(brw-ctx, texObj);
texImage = _mesa_get_tex_image(ctx, texObj, target, level);
intel_miptree_make_shareable(brw, rb-mt);
- intel_set_texture_image_region(ctx, texImage, rb-mt-region, target,
- internalFormat, texFormat, 0,
- rb-mt-region-width,
- rb-mt-region-height,
- 0, 0);
+ intel_set_texture_image_bo(ctx, texImage, rb-mt-region-bo, target,
+ internalFormat, texFormat, 0,
+ rb-mt-region-width,
+ rb-mt-region-height,
+ rb-mt-region-pitch,
+ 0, 0);
_mesa_unlock_texture(brw-ctx, texObj);
}
@@ -406,11 +403,12 @@ intel_image_target_texture_2d(struct gl_context *ctx,
GLenum target,
return;
}
- intel_set_texture_image_region(ctx, texImage, image-region,
-
Re: [Mesa-dev] [PATCH 03/18] i965: Fix another broken offset-aligned-to-tile test.
Patches 1-3 are Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/18] i965: Move intel_region_get_tile_offsets() to be a miptree function.
/** + * This function computes masks that may be used to select the bits of the X + * and Y coordinates that indicate the offset within a tile. If the region is Tiny nit --- ^^ + * untiled, the masks are set to 0. + */ But whatever. Patch 4 is Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/18] i965: Move intel_region_get_aligned_offset() to be a miptree function.
@@ -856,16 +856,16 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context
*brw,
/* 3DSTATE_HIER_DEPTH_BUFFER */
{
- struct intel_region *hiz_region = params-depth.mt-hiz_mt-region;
+ struct intel_mipmap_tree *hiz_mt = params-depth.mt-hiz_mt;
While you're on a data structure rampage, it would be nice to do
s/hiz_mt/hiz_bo/ too. But that surgery isn't nearly as straightforward
as region removal.
/**
* This function computes masks that may be used to select the bits of the X
- * and Y coordinates that indicate the offset within a tile. If the region
is
+ * and Y coordinates that indicate the offset within a tile. If the BO is
Ah, you got my nit in the previous patch --^
This hunk should be squashed, but... whatever.
* untiled, the masks are set to 0.
*/
void
+uint32_t
+intel_miptree_get_aligned_offset(const struct intel_mipmap_tree *mt,
+ uint32_t x, uint32_t y,
+ bool map_stencil_as_y_tiled)
+{
I feel the suspense...
+ int cpp = mt-region-cpp;
I'm waiting for this ^ to die in the finale mega patch.
Patches up to here are
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/18] i965: Drop pointless cast of texObj to intelObj.
Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
