[Mesa-dev] [Bug 90048] shaderapi.h:235:50: error: expected ‘{’ before ‘?=,=?UTF-8?Q?’ token
https://bugs.freedesktop.org/show_bug.cgi?id=90048
Bug ID: 90048
Summary: shaderapi.h:235:50: error: expected ‘{’ before ‘,’
token
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Keywords: regression
Severity: blocker
Priority: medium
Component: Mesa core
Assignee: mesa-dev@lists.freedesktop.org
Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
mesa: f78b2c432f31a18794b9f62f0a0cfb8eca256151 (master 10.6.0-devel)
MinGW build error
Compiling src/mesa/drivers/common/meta_tex_subimage.c ...
In file included from src/mesa/drivers/common/meta_tex_subimage.c:37:0:
src/mesa/main/shaderapi.h:235:50: error: expected ‘{’ before ‘,’ token
GLenum interface, const char *name);
^
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90048] shaderapi.h:235:50: error: expected ‘{’ before ‘?=,=?UTF-8?Q?’ token
https://bugs.freedesktop.org/show_bug.cgi?id=90048 Vinson Lee changed: What|Removed |Added Keywords||bisected CC||lem...@gmail.com, ||martin.pe...@free.fr --- Comment #1 from Vinson Lee --- 161f57f6103802de55d792bcc6a4370afa5c5173 is the first bad commit commit 161f57f6103802de55d792bcc6a4370afa5c5173 Author: Tapani Pälli Date: Tue Mar 10 09:30:30 2015 +0200 mesa: glGetProgramResourceIndex Patch adds required helper functions to shaderapi.h and the actual implementation. v2: code cleanup (Ilia Mirkin) corresponding Piglit test: arb_program_interface_query-getprogramresourceindex Signed-off-by: Tapani Pälli Reviewed-by: Martin Peres :04 04 1c1cd0464953b6239e43d7007db9454e87a1c12c 1ff2ac35aa06aecdb2251b5af4db831b4ccece15 Msrc bisect run success -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90048] shaderapi.h:235:50: error: expected ‘{’ before ‘?=,=?UTF-8?Q?’ token
https://bugs.freedesktop.org/show_bug.cgi?id=90048 --- Comment #2 from Tapani Pälli --- sorry, will try to dig what is causing this -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90048] shaderapi.h:235:50: error: expected ‘{’ before ‘?=,=?UTF-8?Q?’ token
https://bugs.freedesktop.org/show_bug.cgi?id=90048 --- Comment #3 from Tapani Pälli --- Created attachment 115113 --> https://bugs.freedesktop.org/attachment.cgi?id=115113&action=edit fix attempt does this fix the issue? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90048] shaderapi.h:235:50: error: expected ‘{’ before ‘?=,=?UTF-8?Q?’ token
https://bugs.freedesktop.org/show_bug.cgi?id=90048 --- Comment #4 from Vinson Lee --- (In reply to Tapani Pälli from comment #3) > Created attachment 115113 [details] [review] > fix attempt > > does this fix the issue? No. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90048] shaderapi.h:235:50: error: expected ‘{’ before ‘?=,=?UTF-8?Q?’ token
https://bugs.freedesktop.org/show_bug.cgi?id=90048
--- Comment #5 from Vinson Lee ---
A definition of interface must be getting included from some MinGW header file.
This patch works around the compile error.
diff --git a/src/mesa/main/shaderapi.h b/src/mesa/main/shaderapi.h
index 0cd2fad..d313581 100644
--- a/src/mesa/main/shaderapi.h
+++ b/src/mesa/main/shaderapi.h
@@ -35,6 +35,7 @@
extern "C" {
#endif
+#undef interface
struct _glapi_table;
struct gl_context;
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90048] shaderapi.h:235:50: error: expected ‘{’ before ‘?=,=?UTF-8?Q?’ token
https://bugs.freedesktop.org/show_bug.cgi?id=90048
--- Comment #6 from Tapani Pälli ---
(In reply to Vinson Lee from comment #5)
> A definition of interface must be getting included from some MinGW header
> file.
>
> This patch works around the compile error.
>
> diff --git a/src/mesa/main/shaderapi.h b/src/mesa/main/shaderapi.h
> index 0cd2fad..d313581 100644
> --- a/src/mesa/main/shaderapi.h
> +++ b/src/mesa/main/shaderapi.h
> @@ -35,6 +35,7 @@
> extern "C" {
> #endif
>
> +#undef interface
>
> struct _glapi_table;
> struct gl_context;
ok, thanks for fixing the issue!
Reviewed-by: Tapani Pälli
--
You are receiving this mail because:
You are the QA Contact for the bug.
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 v2 00/24] ARB_program_interface_query
I took the liberty to push a follow-up change to rename `interface` to `program `programInterface`. `interface` caused build failures on Windows, as it is a define -- an alias for `struct` keyword, used when declaring COM interfaces in C or C++. I chose `programInterface` to match the the name name used in GL_ARB_program_interface_query spec/headers (which was in fact chosen like that for the very same reason). This is my commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=037e0e78abf0c312f737d33f3c33e37b22bf226d Even `programInterface` was the chosen name in the extension, I admit is a tad long. I just want to fix the build asap, but if you prefer to rename to something smaller (e.g, `iface`) I'm happy to do it too. Jose On 01/04/15 13:14, Tapani Pälli wrote: Hello; Here's the v2 implementation of ARB_program_interface_query extension. I have addressed errors found by Ilia Mirkin in his review and there are several small fixes here and there for bugs revealed with Martin's Piglit tests. Patches add a resource list as part of gl_shader_program which contains all different resources. List is then used to implement extension functions as well as following existing queries: GetActiveAttrib GetAttribLocation GetUniformLocation GetActiveUniformName GetUniformIndices GetActiveUniform GetActiveUniformsiv GetUniformBlockIndex GetActiveUniformBlockName GetActiveUniformBlockiv GetActiveAtomicCounterBufferiv GetTransformFeedbackVarying GetFragDataLocation GetFragDataIndex No Piglit regressions with these changes. There are Piglit tests for the extension in the Piglit mailing list, all of these pass: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_piglit_2015-2DApril_015457.html&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3M&s=xQYf3XSyViAxeZGMVr3QiQgsl228e0lTG7L_Kli3ctM&e= Extension specification: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opengl.org_registry_specs_ARB_program-5Finterface-5Fquery.txt&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3M&s=exUys8YSrdaLlgkKQs9pcqsRLY7AtjRRk7FyGW4kvno&e= Git branch with all the patches: https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Etpalli_mesa_log_-3Fh-3Dpiq&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3M&s=GdA-NzXKst7bl3fFT5Lbj622qrZoNeQs4dLu41WJ7zw&e= Thanks; Tapani Pälli (24): linker: fix varying linking if SSO program has only gs and fs glapi: add GL_ARB_program_interface_query skeleton mesa/glsl: build list of program resources during linking mesa: glGetProgramInterfaceiv mesa: glGetProgramResourceIndex mesa: glGetProgramResourceName mesa: glGetProgramResourceLocation mesa: glGetProgramResourceLocationIndex mesa: implementation of glGetProgramResourceiv mesa: enable GL_ARB_program_interface_query extension mesa: refactor GetActiveAttrib mesa: refactor GetAttribLocation mesa: refactor GetFragDataLocation mesa: refactor GetFragDataIndex mesa: mesa_bufferiv utility function for buffer objects mesa: refactor GetActiveUniformsiv, use _mesa_program_resource_prop mesa: refactor GetTransformFeedbackVarying mesa: refactor GetActiveUniform mesa: refactor GetActiveUniformName mesa: remove unused _mesa_get_uniform_name mesa: refactor GetActiveUniformBlockName mesa: refactor GetUniformLocation mesa: refactor GetUniformIndices mesa: refactor GetUniformBlockIndex docs/GL3.txt | 4 +- docs/relnotes/10.6.0.html | 1 + src/glsl/linker.cpp| 211 +- src/mapi/glapi/gen/ARB_program_interface_query.xml | 109 +++ src/mapi/glapi/gen/gl_API.xml | 4 +- src/mapi/glapi/gen/gl_genexec.py | 1 + src/mesa/Makefile.sources | 2 + src/mesa/main/extensions.c | 1 + src/mesa/main/mtypes.h | 14 + src/mesa/main/program_resource.c | 417 +++ src/mesa/main/program_resource.h | 58 ++ src/mesa/main/shader_query.cpp | 764 ++--- src/mesa/main/shaderapi.h | 45 ++ src/mesa/main/shaderobj.c | 6 + src/mesa/main/tests/dispatch_sanity.cpp| 12 +- src/mesa/main/transformfeedback.c | 19 +- src/mesa/main/uniform_query.cpp| 138 ++-- src/mesa/main/uniforms.c | 294 +++- src/mesa/main/uniforms.h | 5 - 19 files changed, 1687 insertions(+), 418 deletions(-) c
Re: [Mesa-dev] [PATCH v2 00/24] ARB_program_interface_query
On 04/16/2015 12:32 PM, Jose Fonseca wrote: I took the liberty to push a follow-up change to rename `interface` to `program `programInterface`. `interface` caused build failures on Windows, as it is a define -- an alias for `struct` keyword, used when declaring COM interfaces in C or C++. I chose `programInterface` to match the the name name used in GL_ARB_program_interface_query spec/headers (which was in fact chosen like that for the very same reason). This is my commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=037e0e78abf0c312f737d33f3c33e37b22bf226d OK, I see. This rename change is fine with me, Even `programInterface` was the chosen name in the extension, I admit is a tad long. I just want to fix the build asap, but if you prefer to rename to something smaller (e.g, `iface`) I'm happy to do it too. Jose On 01/04/15 13:14, Tapani Pälli wrote: Hello; Here's the v2 implementation of ARB_program_interface_query extension. I have addressed errors found by Ilia Mirkin in his review and there are several small fixes here and there for bugs revealed with Martin's Piglit tests. Patches add a resource list as part of gl_shader_program which contains all different resources. List is then used to implement extension functions as well as following existing queries: GetActiveAttrib GetAttribLocation GetUniformLocation GetActiveUniformName GetUniformIndices GetActiveUniform GetActiveUniformsiv GetUniformBlockIndex GetActiveUniformBlockName GetActiveUniformBlockiv GetActiveAtomicCounterBufferiv GetTransformFeedbackVarying GetFragDataLocation GetFragDataIndex No Piglit regressions with these changes. There are Piglit tests for the extension in the Piglit mailing list, all of these pass: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_piglit_2015-2DApril_015457.html&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3M&s=xQYf3XSyViAxeZGMVr3QiQgsl228e0lTG7L_Kli3ctM&e= Extension specification: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opengl.org_registry_specs_ARB_program-5Finterface-5Fquery.txt&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3M&s=exUys8YSrdaLlgkKQs9pcqsRLY7AtjRRk7FyGW4kvno&e= Git branch with all the patches: https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Etpalli_mesa_log_-3Fh-3Dpiq&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3M&s=GdA-NzXKst7bl3fFT5Lbj622qrZoNeQs4dLu41WJ7zw&e= Thanks; Tapani Pälli (24): linker: fix varying linking if SSO program has only gs and fs glapi: add GL_ARB_program_interface_query skeleton mesa/glsl: build list of program resources during linking mesa: glGetProgramInterfaceiv mesa: glGetProgramResourceIndex mesa: glGetProgramResourceName mesa: glGetProgramResourceLocation mesa: glGetProgramResourceLocationIndex mesa: implementation of glGetProgramResourceiv mesa: enable GL_ARB_program_interface_query extension mesa: refactor GetActiveAttrib mesa: refactor GetAttribLocation mesa: refactor GetFragDataLocation mesa: refactor GetFragDataIndex mesa: mesa_bufferiv utility function for buffer objects mesa: refactor GetActiveUniformsiv, use _mesa_program_resource_prop mesa: refactor GetTransformFeedbackVarying mesa: refactor GetActiveUniform mesa: refactor GetActiveUniformName mesa: remove unused _mesa_get_uniform_name mesa: refactor GetActiveUniformBlockName mesa: refactor GetUniformLocation mesa: refactor GetUniformIndices mesa: refactor GetUniformBlockIndex docs/GL3.txt | 4 +- docs/relnotes/10.6.0.html | 1 + src/glsl/linker.cpp| 211 +- src/mapi/glapi/gen/ARB_program_interface_query.xml | 109 +++ src/mapi/glapi/gen/gl_API.xml | 4 +- src/mapi/glapi/gen/gl_genexec.py | 1 + src/mesa/Makefile.sources | 2 + src/mesa/main/extensions.c | 1 + src/mesa/main/mtypes.h | 14 + src/mesa/main/program_resource.c | 417 +++ src/mesa/main/program_resource.h | 58 ++ src/mesa/main/shader_query.cpp | 764 ++--- src/mesa/main/shaderapi.h | 45 ++ src/mesa/main/shaderobj.c | 6 + src/mesa/main/tests/dispatch_sanity.cpp| 12 +- src/mesa/main/transformfeedback.c | 19 +- src/mesa/main/uniform_query.cpp| 138 ++-- src/mesa/main/uniforms.c | 294 +++- src/mesa
[Mesa-dev] [Bug 90048] shaderapi.h:235:50: error: expected ‘{’ before ‘?=,=?UTF-8?Q?’ token
https://bugs.freedesktop.org/show_bug.cgi?id=90048 José Fonseca changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from José Fonseca --- Sorry, I noticed the build failure, and checked if there was any patch posted to mesa-dev, but I didn't notice this bug report until now (because the subject has some non-ASCII characters so the subject of the notification emails I got were totally garbled.) In fact I just took the liberty of pushing a different fix: http://cgit.freedesktop.org/mesa/mesa/commit/?id=037e0e78abf0c312f737d33f3c33e37b22bf226d My apologies. -- You are receiving this mail because: You are the QA Contact for the bug. 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 4/9] prog; add weak _mesa_error_no_memory() symbol and add it to libglsl_util
On 15 April 2015 at 23:25, Rob Clark wrote: > On Wed, Apr 15, 2015 at 6:15 PM, Ian Romanick wrote: >> On 04/15/2015 10:56 AM, Emil Velikov wrote: >>> On 15 April 2015 at 18:33, Matt Turner wrote: On Wed, Apr 15, 2015 at 7:08 AM, Emil Velikov wrote: > Rather than forcing everyone to provide their own definition of the symbol > provide a common weak one, which anyone can override if needed. > > This resolved the build of the standalone pipe-drivers, as it provides a > default symbol which was missing previously. > > Cc: Rob Clark > Signed-off-by: Emil Velikov > --- > src/Makefile.am| 3 ++- > src/glsl/SConscript| 2 ++ > src/mesa/Android.libmesa_glsl_utils.mk | 6 -- > src/mesa/program/weak_errors.c | 30 > ++ Is program/ really the right place for this? (maybe main/ instead?) >>> Hmm main/ might be better indeed. If there are any recommendations >>> about the name I'll gladly take it :) >> >> So... who is going to use this other than src/glsl/main.cpp and >> src/glsl/tests? It seems like you could just put the (non-weak) symbol >> in a common file that only those things link. >> Everyone who uses NIR (and does not include mesa) - currently drivers/freedreno/ir3_compiler, targets/xa, targets/nine, targets/pipe-loader. >> Is the goal just code sharing, or is the goal partitioning src/glsl from >> src/mesa? The former probably isn't worth the effort, and the latter >> should have a more systematic approach... and I could get behind that. > > fwiw, the goal is sharing libnir (both vc4 and freedreno/ir3 use it, > and I expect others might like to at some point).. but that currently > brings along some glsl dependencies, which bring along the > _mesa_error_no_memory() dependency.. > First goal is to consolidate the four identical functions and prevent adding a fifth one, the latter of which is required in order to fix the build. As a long term plan (for which I will greatly appreciate all your help) is to decouple nir (glsl) from mesa. We can avoid the weak symbol magic, but each user will need to pick the default implementation (C file) which is also fine with me. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon: replace __FUNCTION__ with __func__
Consistently just use C99's __func__ everywhere.
No functional changes.
Signed-off-by: Marius Predut
---
src/mesa/drivers/dri/r200/r200_blit.c |2 +-
src/mesa/drivers/dri/r200/r200_cmdbuf.c| 10 +++
src/mesa/drivers/dri/r200/r200_ioctl.c |2 +-
src/mesa/drivers/dri/r200/r200_sanity.c|2 +-
src/mesa/drivers/dri/r200/r200_state.c | 22 +++
src/mesa/drivers/dri/r200/r200_state.h |2 +-
src/mesa/drivers/dri/r200/r200_swtcl.c |2 +-
src/mesa/drivers/dri/r200/r200_tcl.c |4 +--
src/mesa/drivers/dri/r200/r200_tex.c | 14 +-
src/mesa/drivers/dri/r200/r200_texstate.c |6 ++---
src/mesa/drivers/dri/r200/r200_vertprog.c | 16 +--
src/mesa/drivers/dri/radeon/radeon_blit.c |2 +-
src/mesa/drivers/dri/radeon/radeon_cmdbuf.h|6 ++---
src/mesa/drivers/dri/radeon/radeon_common.c| 12 -
.../drivers/dri/radeon/radeon_common_context.c | 10 +++
src/mesa/drivers/dri/radeon/radeon_debug.h |2 +-
src/mesa/drivers/dri/radeon/radeon_dma.c | 28 ++--
src/mesa/drivers/dri/radeon/radeon_fbo.c |2 +-
src/mesa/drivers/dri/radeon/radeon_ioctl.c | 14 +-
src/mesa/drivers/dri/radeon/radeon_maos_arrays.c |8 +++---
src/mesa/drivers/dri/radeon/radeon_maos_vbtmp.h|2 +-
src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c |6 ++---
src/mesa/drivers/dri/radeon/radeon_queryobj.c | 16 +--
src/mesa/drivers/dri/radeon/radeon_screen.c|2 +-
src/mesa/drivers/dri/radeon/radeon_state.c | 12 -
src/mesa/drivers/dri/radeon/radeon_state.h |2 +-
src/mesa/drivers/dri/radeon/radeon_swtcl.c |4 +--
src/mesa/drivers/dri/radeon/radeon_tcl.c |4 +--
src/mesa/drivers/dri/radeon/radeon_tex.c | 10 +++
src/mesa/drivers/dri/radeon/radeon_tex_copy.c |2 +-
src/mesa/drivers/dri/radeon/radeon_texstate.c |4 +--
src/mesa/drivers/dri/radeon/radeon_texture.c |2 +-
32 files changed, 116 insertions(+), 116 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_blit.c
b/src/mesa/drivers/dri/r200/r200_blit.c
index a33f338..3adc694 100644
--- a/src/mesa/drivers/dri/r200/r200_blit.c
+++ b/src/mesa/drivers/dri/r200/r200_blit.c
@@ -527,7 +527,7 @@ unsigned r200_blit(struct gl_context *ctx,
/* Flush is needed to make sure that source buffer has correct data */
radeonFlush(&r200->radeon.glCtx);
-rcommonEnsureCmdBufSpace(&r200->radeon, 102, __FUNCTION__);
+rcommonEnsureCmdBufSpace(&r200->radeon, 102, __func__);
if (!validate_buffers(r200, src_bo, dst_bo))
return GL_FALSE;
diff --git a/src/mesa/drivers/dri/r200/r200_cmdbuf.c
b/src/mesa/drivers/dri/r200/r200_cmdbuf.c
index 13ac5af..83846d6 100644
--- a/src/mesa/drivers/dri/r200/r200_cmdbuf.c
+++ b/src/mesa/drivers/dri/r200/r200_cmdbuf.c
@@ -124,7 +124,7 @@ void r200EmitVbufPrim( r200ContextPtr rmesa,
radeonEmitState(&rmesa->radeon);
radeon_print(RADEON_RENDER|RADEON_SWRENDER,RADEON_VERBOSE,
- "%s cmd_used/4: %d prim %x nr %d\n", __FUNCTION__,
+ "%s cmd_used/4: %d prim %x nr %d\n", __func__,
rmesa->store.cmd_used/4, primitive, vertex_nr);
BEGIN_BATCH(3);
@@ -162,7 +162,7 @@ void r200FlushElts(struct gl_context *ctx)
r200ContextPtr rmesa = R200_CONTEXT(ctx);
int nr, elt_used = rmesa->tcl.elt_used;
- radeon_print(RADEON_RENDER, RADEON_VERBOSE, "%s %x %d\n", __FUNCTION__,
rmesa->tcl.hw_primitive, elt_used);
+ radeon_print(RADEON_RENDER, RADEON_VERBOSE, "%s %x %d\n", __func__,
rmesa->tcl.hw_primitive, elt_used);
assert( rmesa->radeon.dma.flush == r200FlushElts );
rmesa->radeon.dma.flush = NULL;
@@ -187,7 +187,7 @@ GLushort *r200AllocEltsOpenEnded( r200ContextPtr rmesa,
{
GLushort *retval;
- radeon_print(RADEON_RENDER, RADEON_VERBOSE, "%s %d prim %x\n",
__FUNCTION__, min_nr, primitive);
+ radeon_print(RADEON_RENDER, RADEON_VERBOSE, "%s %d prim %x\n", __func__,
min_nr, primitive);
assert((primitive & R200_VF_PRIM_WALK_IND));
@@ -225,7 +225,7 @@ void r200EmitVertexAOS( r200ContextPtr rmesa,
BATCH_LOCALS(&rmesa->radeon);
radeon_print(RADEON_SWRENDER, RADEON_VERBOSE, "%s: vertex_size 0x%x offset
0x%x \n",
- __FUNCTION__, vertex_size, offset);
+ __func__, vertex_size, offset);
BEGIN_BATCH(7);
@@ -245,7 +245,7 @@ void r200EmitAOS(r200ContextPtr rmesa, GLuint nr, GLuint
offset)
radeon_print(RADEON_RENDER, RADEON_VERBOSE,
"%s: nr=%d, ofs=0x%08x\n",
- __FUNCTION__, nr, offset);
+ __func__, nr, offset);
BEGIN_BATCH(sz+2+ (nr*2));
OUT_BATCH_PACKET3(R200_CP_CMD_3D_LOAD_VBPNTR, sz - 1);
diff --git a/src/mesa/drivers/dri/r200/r200_ioctl.c
b/src/mesa/dri
[Mesa-dev] [PATCH] main: remove __FUNCTION__ defined because it is obsolete
Consistently just use C99's __func__ everywhere.
No functional changes.
Apply this patch after "radeon: replace __FUNCTION__ with __func__" patch.
Signed-off-by: Marius Predut
---
src/mesa/main/compiler.h |5 -
1 file changed, 5 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 55152fd..93b4e6f 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -60,11 +60,6 @@ extern "C" {
#endif
-/* XXX: Use standard `__func__` instead */
-#ifndef __FUNCTION__
-# define __FUNCTION__ __func__
-#endif
-
/**
* Either define MESA_BIG_ENDIAN or MESA_LITTLE_ENDIAN, and CPU_TO_LE32.
* Do not use these unless absolutely necessary!
--
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] glx: Allow to create any OpenGL ES version.
On 15 April 2015 at 21:39, Chad Versace wrote:
> On Wed 15 Apr 2015, Emil Velikov wrote:
>>
>> On 14 April 2015 at 17:22, Ian Romanick wrote:
>>>
>>> On 04/14/2015 08:36 AM, Emil Velikov wrote:
On 14 April 2015 at 13:52, Jose Fonseca wrote:
>
> On 13/04/15 22:59, Ian Romanick wrote:
>>
>>
>> On 04/10/2015 03:36 PM, Jose Fonseca wrote:
>>>
>>>
>>> From: José Fonseca
>
>
> diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
> index 8192c54..192525a 100644
> --- a/src/glx/dri2_glx.c
> +++ b/src/glx/dri2_glx.c
> @@ -1102,7 +1102,7 @@ dri2BindExtensions(struct dri2_screen *psc,
> struct
> glx_display * priv,
>__glXEnableDirectExtension(&psc->base,
> "GLX_ARB_create_context");
>__glXEnableDirectExtension(&psc->base,
> "GLX_ARB_create_context_profile");
>
> - if ((mask & (1 << __DRI_API_GLES2)) != 0) {
> + if ((mask & ((1 << __DRI_API_GLES2) | (1 << __DRI_API_GLES3)))
> != 0)
>>>
>>>
>>> Since ES3 is a superset of ES2, this shouldn't be necessary. I can't
>>> imagine a driver only setting __DRI_API_GLES3... and the common code may
>>> not even make that possible. We could, however, enable
>>> GLX_EXT_create_context_es2_profile if only __DRI_API_GLES is set. I
>>> don't really feel like testing any drivers that only support ES 1.x, do
>>> you? :)
>
>
>> Think of it as allowing gles1 support via GLX (apart from gles2/3),
>> rather than testing gles1 only drivers. I would assume that you
>> already support gles1 via EGL so things should just work for GLX.
>> Either way the decision is not mine to make ;-)
>
>
> Drivers that support GLES1 but not GLES2 are easily created. All that's
> needed is rebuilding i965 with --enable-gles1 --disable-gles2, right?
>
True, and it works by default via EGL. We'll need the __DRI_API_GLES
check, as Ian mentioned, for GLX to make use of it.
Considering GLES1 is tested (to a degree) over EGL, one might as well
enable it via GLX. Some of the tests might not pass, but there won't
be any regressions at least :-P
> I also have no time to rebuild the xserver. I try that once in a blue
> moon, and everytime it leads to broken input drivers and the need for
> vodka.
Hot potato ;-) I won't mind prepping and testing it over the next week
or so, but I'm not sure when it will end up committed.
My last xserver pull request (trivial fixes) is from 24th May, is not
committed despite a couple of pings. Suspecting that it might have
been redirected to /dev/null :-\
Cheers
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/9] prog; add weak _mesa_error_no_memory() symbol and add it to libglsl_util
On 15/04/15 23:25, Rob Clark wrote: On Wed, Apr 15, 2015 at 6:15 PM, Ian Romanick wrote: On 04/15/2015 10:56 AM, Emil Velikov wrote: On 15 April 2015 at 18:33, Matt Turner wrote: On Wed, Apr 15, 2015 at 7:08 AM, Emil Velikov wrote: Rather than forcing everyone to provide their own definition of the symbol provide a common weak one, which anyone can override if needed. This resolved the build of the standalone pipe-drivers, as it provides a default symbol which was missing previously. Cc: Rob Clark Signed-off-by: Emil Velikov --- src/Makefile.am| 3 ++- src/glsl/SConscript| 2 ++ src/mesa/Android.libmesa_glsl_utils.mk | 6 -- src/mesa/program/weak_errors.c | 30 ++ Is program/ really the right place for this? (maybe main/ instead?) Hmm main/ might be better indeed. If there are any recommendations about the name I'll gladly take it :) So... who is going to use this other than src/glsl/main.cpp and src/glsl/tests? It seems like you could just put the (non-weak) symbol in a common file that only those things link. Is the goal just code sharing, or is the goal partitioning src/glsl from src/mesa? The former probably isn't worth the effort, and the latter should have a more systematic approach... and I could get behind that. fwiw, the goal is sharing libnir (both vc4 and freedreno/ir3 use it, and I expect others might like to at some point).. but that currently brings along some glsl dependencies, which bring along the _mesa_error_no_memory() dependency.. I wonder if it would be better to have glsl depend on nir (ie move the glsl bits nir needs into nir), so that nir can be safely inside gallium drivers which shouldn't depend on OpenGL specific headers. I guess the issue here is that nir is not built universally (in particular we need to update scons to start using it for Windows builds.) Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] main: remove __FUNCTION__ defined because it is obsolete
Hi Marius, On 16 April 2015 at 11:36, Marius Predut wrote: > Consistently just use C99's __func__ everywhere. > No functional changes. > Apply this patch after "radeon: replace __FUNCTION__ with __func__" patch. > Tip: If you send the patches as series (git format-patch -2) this will implicitly provide/preserve the dependency chain. Both patches are trivial enough, plus other places of mesa have their own redefinition of the symbol. I'll do a quick build test and push them in the next few hours. Unless there are any objections of course :-) > Signed-off-by: Marius Predut Reviewed-by: Emil Velikov Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/9] prog; add weak _mesa_error_no_memory() symbol and add it to libglsl_util
On 16 April 2015 at 11:50, Jose Fonseca wrote: > On 15/04/15 23:25, Rob Clark wrote: >> >> On Wed, Apr 15, 2015 at 6:15 PM, Ian Romanick wrote: >>> >>> On 04/15/2015 10:56 AM, Emil Velikov wrote: On 15 April 2015 at 18:33, Matt Turner wrote: > > On Wed, Apr 15, 2015 at 7:08 AM, Emil Velikov > wrote: >> >> Rather than forcing everyone to provide their own definition of the >> symbol >> provide a common weak one, which anyone can override if needed. >> >> This resolved the build of the standalone pipe-drivers, as it provides >> a >> default symbol which was missing previously. >> >> Cc: Rob Clark >> Signed-off-by: Emil Velikov >> --- >> src/Makefile.am| 3 ++- >> src/glsl/SConscript| 2 ++ >> src/mesa/Android.libmesa_glsl_utils.mk | 6 -- >> src/mesa/program/weak_errors.c | 30 >> ++ > > > Is program/ really the right place for this? (maybe main/ instead?) Hmm main/ might be better indeed. If there are any recommendations about the name I'll gladly take it :) >>> >>> >>> So... who is going to use this other than src/glsl/main.cpp and >>> src/glsl/tests? It seems like you could just put the (non-weak) symbol >>> in a common file that only those things link. >>> >>> Is the goal just code sharing, or is the goal partitioning src/glsl from >>> src/mesa? The former probably isn't worth the effort, and the latter >>> should have a more systematic approach... and I could get behind that. >> >> >> fwiw, the goal is sharing libnir (both vc4 and freedreno/ir3 use it, >> and I expect others might like to at some point).. but that currently >> brings along some glsl dependencies, which bring along the >> _mesa_error_no_memory() dependency.. > > > I wonder if it would be better to have glsl depend on nir (ie move the glsl > bits nir needs into nir), so that nir can be safely inside gallium drivers > which shouldn't depend on OpenGL specific headers. > Fwiw here are the sources required in order for one to use nir (haven't gone through the headers) glsl/glsl_types.cpp glsl/builtin_types.cpp glsl/glsl_symbol_table.cpp plus the following three (also know as libglsl_util) mesa/main/imports.c mesa/program/prog_hash_table.c << this one is different from src/util/hash_table.c or the one we have in gallium mesa/program/symbol_table.c > I guess the issue here is that nir is not built universally (in particular > we need to update scons to start using it for Windows builds.) > One could hack the current automake approach in SCons without a problem. It won't be pretty though. -Emil P.S. Is it me or does most users of ralloc do not handle OOM conditions ? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] libgl-gdi: Prevent "pure virtual method called" error when.
When running piglit w/ llvmpipe on Windows several tests terminate
abnormally just when the test exits.
The problem was that LLVMContextDispose was being called
after LLVM global destructors.
---
src/gallium/targets/libgl-gdi/libgl_gdi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/gallium/targets/libgl-gdi/libgl_gdi.c
b/src/gallium/targets/libgl-gdi/libgl_gdi.c
index a2fb161..922c186 100644
--- a/src/gallium/targets/libgl-gdi/libgl_gdi.c
+++ b/src/gallium/targets/libgl-gdi/libgl_gdi.c
@@ -38,6 +38,7 @@
#include "util/u_debug.h"
#include "stw_winsys.h"
+#include "stw_device.h"
#include "gdi/gdi_sw_winsys.h"
#include "softpipe/sp_texture.h"
@@ -143,8 +144,12 @@ static const struct stw_winsys stw_winsys = {
};
+EXTERN_C BOOL WINAPI
+DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved);
+
+
BOOL WINAPI
-DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
+DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
switch (fdwReason) {
case DLL_PROCESS_ATTACH:
@@ -161,9 +166,22 @@ DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID
lpReserved)
break;
case DLL_PROCESS_DETACH:
- if (lpReserved == NULL) {
+ if (lpvReserved == NULL) {
+ // We're being unloaded from the process.
stw_cleanup_thread();
stw_cleanup();
+ } else {
+ // Process itself is terminating, and all threads and modules are
+ // being detached.
+ //
+ // The order threads (including llvmpipe rasterizer threads) are
+ // destroyed can not be relied up, so it's not safe to cleanup.
+ //
+ // However global destructors (e.g., LLVM's) will still be called, and
+ // if Microsoft OPENGL32.DLL's DllMain is called after us, it will
+ // still try to invoke DrvDeleteContext to destroys all outstanding,
+ // so set stw_dev to NULL to return immediately if that happens.
+ stw_dev = NULL;
}
break;
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl/dri2: Fix GCC maybe-uninitialized warning.
On 26 March 2015 at 00:40, Ilia Mirkin wrote:
> On Wed, Mar 25, 2015 at 8:31 PM, Matt Turner wrote:
>> On Wed, Mar 25, 2015 at 4:15 PM, Jan Vesely wrote:
>>> On Wed, 2015-03-25 at 18:55 -0400, Ilia Mirkin wrote:
On Wed, Mar 25, 2015 at 6:51 PM, Jan Vesely wrote:
> On Fri, 2015-03-06 at 23:54 -0800, Vinson Lee wrote:
>> egl_dri2.c: In function ‘dri2_bind_tex_image’:
>> egl_dri2.c:1240:4: warning: ‘format’ may be used uninitialized in this
>> function [-Wmaybe-uninitialized]
>> (*dri2_dpy->tex_buffer->setTexBuffer2)(dri2_ctx->dri_context,
>> ^
>>
>> Suggested-by: Ilia Mirkin
>> Signed-off-by: Vinson Lee
>> ---
>> src/egl/drivers/dri2/egl_dri2.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/egl_dri2.c
>> b/src/egl/drivers/dri2/egl_dri2.c
>> index d503196..c5c475d 100644
>> --- a/src/egl/drivers/dri2/egl_dri2.c
>> +++ b/src/egl/drivers/dri2/egl_dri2.c
>> @@ -1226,7 +1226,8 @@ dri2_bind_tex_image(_EGLDriver *drv,
>>format = __DRI_TEXTURE_FORMAT_RGBA;
>>break;
>> default:
>> - assert(0);
>> + _eglError(EGL_BAD_SURFACE, "unrecognized format");
>> + return EGL_FALSE;
>
> does using:
> unreachable("unrecognized format");
> instead of
> assert(0);
> fix the warning?
unreachable is for *truly* unreachable code... it sounded like this
was reachable with bad input.
>>>
>>> maybe I misunderstood the situation.
>>> since there is assert(0) I assumed it can never happen.
>>> combination of assert(0) and return is very confusing:
>>> either the code is reachable and should have a correct error path (in
>>> which case there should not be assert(0)),
>>> or the code is not reachable in which case unreachable does just fine
>>> and you should not have the error path.
>>>
>>> it looks to me that using assert and return just makes sure that the
>>> error path is never run on debug build.
>>>
>>> anyway, it was just a suggestion. I won't argue one way or another,
>>> since I don't work with/understand those parts of the code.
>>
>> I agree. If the code had an assert(0) it's pretty clearly a case for
>> unreachable.
>
> I dunno, I've seen assert's thrown in all over the place where the
> assumption was that they'd only trigger on debug builds. Not sure if
> this is one of those cases, but I have a hard time convincing myself
> that there's no way an unexpected value can get in there. The downside
> of unreachable() is that it ends up as an infinite loop or other sorts
> of funny control flow, which can be quite difficult to debug (in a
> production build).
Fwiw I agree with Ilia here. Currently we have cases where asset(0)
does not (seem to) imply unreachable. That may have been the original
idea, although not any more. In the odd case like this, a few bytes of
code might be better than getting stuck in an infinite loop ?
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] main: remove __FUNCTION__ defined because it is obsolete
> -Original Message- > From: Emil Velikov [mailto:emil.l.veli...@gmail.com] > Sent: Thursday, April 16, 2015 1:53 PM > To: Predut, Marius > Cc: ML mesa-dev > Subject: Re: [Mesa-dev] [PATCH] main: remove __FUNCTION__ defined because it > is obsolete > > Hi Marius, > > On 16 April 2015 at 11:36, Marius Predut wrote: > > Consistently just use C99's __func__ everywhere. > > No functional changes. > > Apply this patch after "radeon: replace __FUNCTION__ with __func__" patch. > > > Tip: If you send the patches as series (git format-patch -2) this will > implicitly provide/preserve the dependency chain. Ok thanks, in this case if u plan commit it , may be is better to adjust the comment by removing last line. > > Both patches are trivial enough, plus other places of mesa have their own > redefinition of the symbol. I'll do a quick build test and push them in the > next few hours. Unless there are any objections of course > :-) > > > Signed-off-by: Marius Predut > Reviewed-by: Emil Velikov > > Thanks > Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] libgl-gdi: Prevent "pure virtual method called" error when.
Makes sense I guess. That teardown all feels so unnatural unfortunately :-(.
Roland
Am 16.04.2015 um 14:09 schrieb Jose Fonseca:
> When running piglit w/ llvmpipe on Windows several tests terminate
> abnormally just when the test exits.
>
> The problem was that LLVMContextDispose was being called
> after LLVM global destructors.
> ---
> src/gallium/targets/libgl-gdi/libgl_gdi.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/targets/libgl-gdi/libgl_gdi.c
> b/src/gallium/targets/libgl-gdi/libgl_gdi.c
> index a2fb161..922c186 100644
> --- a/src/gallium/targets/libgl-gdi/libgl_gdi.c
> +++ b/src/gallium/targets/libgl-gdi/libgl_gdi.c
> @@ -38,6 +38,7 @@
>
> #include "util/u_debug.h"
> #include "stw_winsys.h"
> +#include "stw_device.h"
> #include "gdi/gdi_sw_winsys.h"
>
> #include "softpipe/sp_texture.h"
> @@ -143,8 +144,12 @@ static const struct stw_winsys stw_winsys = {
> };
>
>
> +EXTERN_C BOOL WINAPI
> +DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved);
> +
> +
> BOOL WINAPI
> -DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
> +DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
> {
> switch (fdwReason) {
> case DLL_PROCESS_ATTACH:
> @@ -161,9 +166,22 @@ DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID
> lpReserved)
>break;
>
> case DLL_PROCESS_DETACH:
> - if (lpReserved == NULL) {
> + if (lpvReserved == NULL) {
> + // We're being unloaded from the process.
> stw_cleanup_thread();
> stw_cleanup();
> + } else {
> + // Process itself is terminating, and all threads and modules are
> + // being detached.
> + //
> + // The order threads (including llvmpipe rasterizer threads) are
> + // destroyed can not be relied up, so it's not safe to cleanup.
> + //
> + // However global destructors (e.g., LLVM's) will still be called,
> and
> + // if Microsoft OPENGL32.DLL's DllMain is called after us, it will
> + // still try to invoke DrvDeleteContext to destroys all outstanding,
> + // so set stw_dev to NULL to return immediately if that happens.
> + stw_dev = NULL;
>}
>break;
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Rewrite ir_tex to ir_txl with lod 0 for vertex shaders
On Wed, Apr 15, 2015 at 6:06 PM, Ian Romanick wrote:
> On 04/15/2015 04:28 PM, Kenneth Graunke wrote:
>> On Wednesday, April 15, 2015 02:47:01 PM Ian Romanick wrote:
>>> On 04/15/2015 12:41 PM, Kristian Høgsberg wrote:
The ir_tex opcode turns into a sample or sample_c message, which will try
to
compute derivatives to determine the lod. This produces garbage for
non-fragment shaders where the sample coordinates don't correspond to
subspans.
We fix this by rewriting the opcode from ir_tex to ir_txl and setting the
lod to 0.
>>>
>>> This seems logical, but... why the heck hasn't this been a problem
>>> before? Is this some weirdness of just BSW? Should we perhaps only do
>>> this on BSW?
>>
>> In the vec4 backend, we've always made ir_tex use the SAMPLE_LOD message
>> with lod set to 0.0 - so Gen4-7.5 have always done this workaround.
>>
>> When Kristian added SIMD8 VS support (Oct 2014, Gen8+), we started using
>> SAMPLE (by virtue of not changing the FS behavior). We honestly have no
>
> Yes, that's the part the slipped my mind. In that case, FWIW,
>
> Reviewed-by: Ian Romanick
Appreciate it. Patch pushed.
Kristian
>> idea why it appears to work on Broadwell - it sure seems like it ought
>> to be broken there. Maybe we've just been lucky.
>>
>> There's also a message header bit for "Force LOD to Zero", which the
>> docs say is mandatory if you're going to use the "SAMPLE" message in
>> SIMD4x2 stages (i.e. not fragment). We've wondered whether headerless
>> messages in non-fragment stages magically get that right. That could
>> make the issue less noticable...
>>
>> Using SAMPLE_LOD is easier than setting the message header bit, and
>> seems just as effective. I think we should do it on Broadwell too.
>>
>> Thanks for fixing this, Kristian!
>>
>> Cc: "10.5"
>> Reviewed-by: Kenneth Graunke
>>
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=89457
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89457
>>>
>>> That allows the bin/bugzilla_mesa.sh script to find it for generating
>>> release notes.
>>>
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 0049b2d..4e99366 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1839,6 +1839,15 @@ fs_visitor::emit_texture_gen7(ir_texture_opcode op,
fs_reg dst,
offset_value.file != BAD_FILE && offset_value.file != IMM;
bool coordinate_done = false;
+ /* The sampler can only meaningfully compute LOD for fragment shader
+* messages. For all other stages, we change the opcode to ir_txl and
+* hardcode the LOD to 0.
+*/
+ if (stage != MESA_SHADER_FRAGMENT && op == ir_tex) {
+ op = ir_txl;
+ lod = fs_reg(0.0f);
+ }
+
/* Set up the LOD info */
switch (op) {
case ir_tex:
>>>
>>> ___
>>> 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 23/38] main: _mesa_blit_framebuffer updates its arbitrary framebuffers.
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Previously, we used _mesa_update_state to update the currently bound
> framebuffers prior to performing a blit. Now that _mesa_blit_framebuffer
> uses arbitrary framebuffers, _mesa_update_state is not specific enough.
> ---
> src/mesa/main/blit.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/main/blit.c b/src/mesa/main/blit.c
> index e03b5dc..1569004 100644
> --- a/src/mesa/main/blit.c
> +++ b/src/mesa/main/blit.c
> @@ -33,6 +33,7 @@
> #include "enums.h"
> #include "blit.h"
> #include "fbobject.h"
> +#include "framebuffer.h"
> #include "glformats.h"
> #include "mtypes.h"
> #include "state.h"
> @@ -161,9 +162,11 @@ _mesa_blit_framebuffer(struct gl_context *ctx,
>
> FLUSH_VERTICES(ctx, 0);
>
> - if (ctx->NewState) {
> - _mesa_update_state(ctx);
> - }
> + /* Update completeness status of readFb and drawFb. */
> + _mesa_update_framebuffer(ctx, readFb, drawFb);
> +
> + /* Make sure drawFb has an initialized bounding box. */
> + _mesa_update_draw_buffer_bounds(ctx, drawFb);
> if (!readFb || !drawFb) {
>/* This will normally never happen but someday we may want to
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 24/38] main: Refactor invalidate_framebuffer_storage.
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mesa/main/fbobject.c | 38 +++---
> 1 file changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 467a8cd..7a1684c 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -3468,19 +3468,13 @@ _mesa_GetNamedFramebufferAttachmentParameteriv(GLuint
> framebuffer,
>
>
> static void
> -invalidate_framebuffer_storage(GLenum target, GLsizei numAttachments,
> +invalidate_framebuffer_storage(struct gl_context *ctx,
> + struct gl_framebuffer *fb,
> + GLsizei numAttachments,
> const GLenum *attachments, GLint x, GLint y,
> GLsizei width, GLsizei height, const char
> *name)
> {
> int i;
> - struct gl_framebuffer *fb;
> - GET_CURRENT_CONTEXT(ctx);
> -
> - fb = get_framebuffer_target(ctx, target);
> - if (!fb) {
> - _mesa_error(ctx, GL_INVALID_ENUM, "%s(target)", name);
> - return;
> - }
>
> if (numAttachments < 0) {
>_mesa_error(ctx, GL_INVALID_VALUE,
> @@ -3590,7 +3584,18 @@ _mesa_InvalidateSubFramebuffer(GLenum target, GLsizei
> numAttachments,
> const GLenum *attachments, GLint x, GLint y,
> GLsizei width, GLsizei height)
> {
> - invalidate_framebuffer_storage(target, numAttachments, attachments,
> + struct gl_framebuffer *fb;
> + GET_CURRENT_CONTEXT(ctx);
> +
> + fb = get_framebuffer_target(ctx, target);
> + if (!fb) {
> + _mesa_error(ctx, GL_INVALID_ENUM,
> + "glInvalidateSubFramebuffer(invalid target %s)",
> + _mesa_lookup_enum_by_nr(target));
> + return;
> + }
> +
> + invalidate_framebuffer_storage(ctx, fb, numAttachments, attachments,
>x, y, width, height,
>"glInvalidateSubFramebuffer");
> }
> @@ -3600,6 +3605,17 @@ void GLAPIENTRY
> _mesa_InvalidateFramebuffer(GLenum target, GLsizei numAttachments,
> const GLenum *attachments)
> {
> + struct gl_framebuffer *fb;
> + GET_CURRENT_CONTEXT(ctx);
> +
> + fb = get_framebuffer_target(ctx, target);
> + if (!fb) {
> + _mesa_error(ctx, GL_INVALID_ENUM,
> + "glInvalidateFramebuffer(invalid target %s)",
> + _mesa_lookup_enum_by_nr(target));
> + return;
> + }
> +
> /* The GL_ARB_invalidate_subdata spec says:
> *
> * "The command
> @@ -3612,7 +3628,7 @@ _mesa_InvalidateFramebuffer(GLenum target, GLsizei
> numAttachments,
> * , equal to 0, 0, ,
> * respectively."
> */
> - invalidate_framebuffer_storage(target, numAttachments, attachments,
> + invalidate_framebuffer_storage(ctx, fb, numAttachments, attachments,
>0, 0,
>MAX_VIEWPORT_WIDTH, MAX_VIEWPORT_HEIGHT,
>"glInvalidateFramebuffer");
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 25/38] main: Complete error conditions for glInvalidate*Framebuffer.
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mesa/main/fbobject.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 7a1684c..0b4cabe 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -3476,12 +3476,29 @@ invalidate_framebuffer_storage(struct gl_context *ctx,
> {
> int i;
>
> + /* Section 17.4 Whole Framebuffer Operations of the OpenGL 4.5 Core
> +* Spec (2.2.2015, PDF page 522) says:
> +*"An INVALID_VALUE error is generated if numAttachments, width, or
> +*height is negative."
> +*/
> if (numAttachments < 0) {
>_mesa_error(ctx, GL_INVALID_VALUE,
>"%s(numAttachments < 0)", name);
>return;
> }
>
> + if (width < 0) {
> + _mesa_error(ctx, GL_INVALID_VALUE,
> + "%s(width < 0)", name);
> + return;
> + }
> +
> + if (height < 0) {
> + _mesa_error(ctx, GL_INVALID_VALUE,
> + "%s(height < 0)", name);
> + return;
> + }
> +
> /* The GL_ARB_invalidate_subdata spec says:
> *
> * "If an attachment is specified that does not exist in the
> @@ -3574,7 +3591,8 @@ invalidate_framebuffer_storage(struct gl_context *ctx,
> return;
>
> invalid_enum:
> - _mesa_error(ctx, GL_INVALID_ENUM, "%s(attachment)", name);
> + _mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid attachment %s)", name,
> + _mesa_lookup_enum_by_nr(attachments[i]));
> return;
> }
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 26/38] main: Add entry points for InvalidateNamedFramebuffer[Sub]Data.
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 16 ++
> src/mesa/main/fbobject.c | 67
> ++
> src/mesa/main/fbobject.h | 12 +
> src/mesa/main/tests/dispatch_sanity.cpp| 2 +
> 4 files changed, 97 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 4e5ba0b..0939b8b 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -140,6 +140,22 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
>
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 0b4cabe..72d87db 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -3618,6 +3618,34 @@ _mesa_InvalidateSubFramebuffer(GLenum target, GLsizei
> numAttachments,
>"glInvalidateSubFramebuffer");
> }
>
> +void GLAPIENTRY
> +_mesa_InvalidateNamedFramebufferSubData(GLuint framebuffer,
> +GLsizei numAttachments,
> +const GLenum *attachments,
> +GLint x, GLint y,
> +GLsizei width, GLsizei height)
> +{
> + struct gl_framebuffer *fb;
> + GET_CURRENT_CONTEXT(ctx);
> +
> + /* The OpenGL 4.5 core spec (02.02.2015) says (in Section 17.4 Whole
> +* Framebuffer Operations, PDF page 522): "If framebuffer is zero, the
> +* default draw framebuffer is affected."
> +*/
> + if (framebuffer) {
> + fb = _mesa_lookup_framebuffer_err(ctx, framebuffer,
> +
> "glInvalidateNamedFramebufferSubData");
> + if (!fb)
> + return;
> + }
> + else
> + fb = ctx->WinSysDrawBuffer;
> +
> + invalidate_framebuffer_storage(ctx, fb, numAttachments, attachments,
> + x, y, width, height,
> + "glInvalidateNamedFramebufferSubData");
> +}
> +
>
> void GLAPIENTRY
> _mesa_InvalidateFramebuffer(GLenum target, GLsizei numAttachments,
> @@ -3652,6 +3680,45 @@ _mesa_InvalidateFramebuffer(GLenum target, GLsizei
> numAttachments,
>"glInvalidateFramebuffer");
> }
>
> +void GLAPIENTRY
> +_mesa_InvalidateNamedFramebufferData(GLuint framebuffer,
> + GLsizei numAttachments,
> + const GLenum *attachments)
> +{
> + struct gl_framebuffer *fb;
> + GET_CURRENT_CONTEXT(ctx);
> +
> + /* The OpenGL 4.5 core spec (02.02.2015) says (in Section 17.4 Whole
> +* Framebuffer Operations, PDF page 522): "If framebuffer is zero, the
> +* default draw framebuffer is affected."
> +*/
> + if (framebuffer) {
> + fb = _mesa_lookup_framebuffer_err(ctx, framebuffer,
> +"glInvalidateNamedFramebufferData");
> + if (!fb)
> + return;
> + }
> + else
> + fb = ctx->WinSysDrawBuffer;
> +
> + /* The GL_ARB_invalidate_subdata spec says:
> +*
> +* "The command
> +*
> +*void InvalidateFramebuffer(enum target,
> +* sizei numAttachments,
> +* const enum *attachments);
> +*
> +* is equivalent to the command InvalidateSubFramebuffer with ,
> ,
> +* , equal to 0, 0, ,
> +* respectively."
> +*/
> + invalidate_framebuffer_storage(ctx, fb, numAttachments, attachments,
> + 0, 0,
> + MAX_VIEWPORT_WIDTH, MAX_VIEWPORT_HEIGHT,
> + "glInvalidateNamedFramebufferData");
> +}
> +
>
> void GLAPIENTRY
> _mesa_DiscardFramebufferEXT(GLenum target, GLsizei numAttachments,
> diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
> index fabeed9..f71e885 100644
> --- a/src/mesa/main/fbobject.h
> +++ b/src/mesa/main/fbobject.h
> @@ -245,10 +245,22 @@ _mesa_InvalidateSubFramebuffer(GLenum target, GLsizei
> numAttachments,
> GLsizei width, GLsizei height);
>
> extern void GLAPIENTRY
> +_mesa_InvalidateNamedFramebufferSubData(GLuint framebuffer,
> +GLsizei numAttachments,
> +const GLenum *attachments,
> +GLint x, GLint y,
> +GLsizei width, GLsizei height);
> +
> +extern void GLAPIENTRY
> _mesa_InvalidateFramebuffer(GLenum target, GLsizei numAttachments,
>
Re: [Mesa-dev] [PATCH 27/38] main: Fake entry point for glClearNamedFramebufferiv.
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Mesa's ClearBuffer framework is very complicated and thoroughly married to the
> object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
> complicated. At some point, we should implement buffer clearing for arbitrary
> framebuffer objects, but for now, we will just wrap ClearBuffer.
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
> src/mesa/main/clear.c | 19 +++
> src/mesa/main/clear.h | 4
> src/mesa/main/tests/dispatch_sanity.cpp| 1 +
> 4 files changed, 31 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 0939b8b..0ab0db4 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -156,6 +156,13 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
>
>
>
> diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
> index 8d707bc..40bf0be 100644
> --- a/src/mesa/main/clear.c
> +++ b/src/mesa/main/clear.c
> @@ -34,6 +34,8 @@
> #include "clear.h"
> #include "context.h"
> #include "enums.h"
> +#include "fbobject.h"
> +#include "get.h"
> #include "macros.h"
> #include "mtypes.h"
> #include "state.h"
> @@ -398,6 +400,23 @@ _mesa_ClearBufferiv(GLenum buffer, GLint drawbuffer,
> const GLint *value)
> }
> }
>
> +/**
> + * The ClearBuffer framework is so complicated and so riddled with the
> + * assumption that the framebuffer is bound that, for now, we will just fake
> + * direct state access clearing for the user.
> + */
> +void GLAPIENTRY
> +_mesa_ClearNamedFramebufferiv(GLuint framebuffer, GLenum buffer,
> + GLint drawbuffer, const GLint *value)
> +{
> + GLint oldfb;
> +
> + _mesa_GetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING, &oldfb);
> + _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, framebuffer);
> + _mesa_ClearBufferiv(buffer, drawbuffer, value);
> + _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, (GLuint) oldfb);
> +}
> +
>
> /**
> * New in GL 3.0
> diff --git a/src/mesa/main/clear.h b/src/mesa/main/clear.h
> index 96ce47b..d0b6133 100644
> --- a/src/mesa/main/clear.h
> +++ b/src/mesa/main/clear.h
> @@ -52,6 +52,10 @@ extern void GLAPIENTRY
> _mesa_ClearBufferiv(GLenum buffer, GLint drawbuffer, const GLint *value);
>
> extern void GLAPIENTRY
> +_mesa_ClearNamedFramebufferiv(GLuint framebuffer, GLenum buffer,
> + GLint drawbuffer, const GLint *value);
> +
> +extern void GLAPIENTRY
> _mesa_ClearBufferuiv(GLenum buffer, GLint drawbuffer, const GLuint *value);
>
> extern void GLAPIENTRY
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 312e253..a24f571 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -976,6 +976,7 @@ const struct function gl_core_functions_possible[] = {
> { "glNamedFramebufferTextureLayer", 45, -1 },
> { "glInvalidateNamedFramebufferSubData", 45, -1 },
> { "glInvalidateNamedFramebufferData", 45, -1 },
> + { "glClearNamedFramebufferiv", 45, -1 },
> { "glBlitNamedFramebuffer", 45, -1 },
> { "glCheckNamedFramebufferStatus", 45, -1 },
> { "glGetNamedFramebufferAttachmentParameteriv", 45, -1 },
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 28/38] main: Fake entry point for glClearNamedFramebufferuiv.
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Mesa's ClearBuffer framework is very complicated and thoroughly married to the
> object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
> complicated. At some point, we should implement buffer clearing for arbitrary
> framebuffer objects, but for now, we will just wrap ClearBuffer.
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
> src/mesa/main/clear.c | 17 +
> src/mesa/main/clear.h | 4
> src/mesa/main/tests/dispatch_sanity.cpp| 1 +
> 4 files changed, 29 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 0ab0db4..52b4d34 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -163,6 +163,13 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
>
>
>
> diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
> index 40bf0be..3357d54 100644
> --- a/src/mesa/main/clear.c
> +++ b/src/mesa/main/clear.c
> @@ -489,6 +489,23 @@ _mesa_ClearBufferuiv(GLenum buffer, GLint drawbuffer,
> const GLuint *value)
> }
> }
>
> +/**
> + * The ClearBuffer framework is so complicated and so riddled with the
> + * assumption that the framebuffer is bound that, for now, we will just fake
> + * direct state access clearing for the user.
> + */
> +void GLAPIENTRY
> +_mesa_ClearNamedFramebufferuiv(GLuint framebuffer, GLenum buffer,
> + GLint drawbuffer, const GLuint *value)
> +{
> + GLint oldfb;
> +
> + _mesa_GetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING, &oldfb);
> + _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, framebuffer);
> + _mesa_ClearBufferuiv(buffer, drawbuffer, value);
> + _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, (GLuint) oldfb);
> +}
> +
>
> /**
> * New in GL 3.0
> diff --git a/src/mesa/main/clear.h b/src/mesa/main/clear.h
> index d0b6133..b74c227 100644
> --- a/src/mesa/main/clear.h
> +++ b/src/mesa/main/clear.h
> @@ -59,6 +59,10 @@ extern void GLAPIENTRY
> _mesa_ClearBufferuiv(GLenum buffer, GLint drawbuffer, const GLuint *value);
>
> extern void GLAPIENTRY
> +_mesa_ClearNamedFramebufferuiv(GLuint framebuffer, GLenum buffer,
> + GLint drawbuffer, const GLuint *value);
> +
> +extern void GLAPIENTRY
> _mesa_ClearBufferfv(GLenum buffer, GLint drawbuffer, const GLfloat *value);
>
> extern void GLAPIENTRY
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index a24f571..a1875b9 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -977,6 +977,7 @@ const struct function gl_core_functions_possible[] = {
> { "glInvalidateNamedFramebufferSubData", 45, -1 },
> { "glInvalidateNamedFramebufferData", 45, -1 },
> { "glClearNamedFramebufferiv", 45, -1 },
> + { "glClearNamedFramebufferuiv", 45, -1 },
> { "glBlitNamedFramebuffer", 45, -1 },
> { "glCheckNamedFramebufferStatus", 45, -1 },
> { "glGetNamedFramebufferAttachmentParameteriv", 45, -1 },
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 29/38] main: Fake entry point for glClearNamedFramebufferfv.
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Mesa's ClearBuffer framework is very complicated and thoroughly married to the
> object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
> complicated. At some point, we should implement buffer clearing for arbitrary
> framebuffer objects, but for now, we will just wrap ClearBuffer.
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
> src/mesa/main/clear.c | 17 +
> src/mesa/main/clear.h | 4
> src/mesa/main/tests/dispatch_sanity.cpp| 1 +
> 4 files changed, 29 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 52b4d34..4cdf2f6 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -170,6 +170,13 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
>
>
>
> diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
> index 3357d54..b5e22e3 100644
> --- a/src/mesa/main/clear.c
> +++ b/src/mesa/main/clear.c
> @@ -599,6 +599,23 @@ _mesa_ClearBufferfv(GLenum buffer, GLint drawbuffer,
> const GLfloat *value)
> }
> }
>
> +/**
> + * The ClearBuffer framework is so complicated and so riddled with the
> + * assumption that the framebuffer is bound that, for now, we will just fake
> + * direct state access clearing for the user.
> + */
> +void GLAPIENTRY
> +_mesa_ClearNamedFramebufferfv(GLuint framebuffer, GLenum buffer,
> + GLint drawbuffer, const GLfloat *value)
> +{
> + GLint oldfb;
> +
> + _mesa_GetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING, &oldfb);
> + _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, framebuffer);
> + _mesa_ClearBufferfv(buffer, drawbuffer, value);
> + _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, (GLuint) oldfb);
> +}
> +
>
> /**
> * New in GL 3.0
> diff --git a/src/mesa/main/clear.h b/src/mesa/main/clear.h
> index b74c227..582159f 100644
> --- a/src/mesa/main/clear.h
> +++ b/src/mesa/main/clear.h
> @@ -66,6 +66,10 @@ extern void GLAPIENTRY
> _mesa_ClearBufferfv(GLenum buffer, GLint drawbuffer, const GLfloat *value);
>
> extern void GLAPIENTRY
> +_mesa_ClearNamedFramebufferfv(GLuint framebuffer, GLenum buffer,
> + GLint drawbuffer, const GLfloat *value);
> +
> +extern void GLAPIENTRY
> _mesa_ClearBufferfi(GLenum buffer, GLint drawbuffer,
> GLfloat depth, GLint stencil);
>
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index a1875b9..d5a3773 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -978,6 +978,7 @@ const struct function gl_core_functions_possible[] = {
> { "glInvalidateNamedFramebufferData", 45, -1 },
> { "glClearNamedFramebufferiv", 45, -1 },
> { "glClearNamedFramebufferuiv", 45, -1 },
> + { "glClearNamedFramebufferfv", 45, -1 },
> { "glBlitNamedFramebuffer", 45, -1 },
> { "glCheckNamedFramebufferStatus", 45, -1 },
> { "glGetNamedFramebufferAttachmentParameteriv", 45, -1 },
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 30/38] main: Fake entry point for glClearNamedFramebufferfi.
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Mesa's ClearBuffer framework is very complicated and thoroughly married to the
> object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
> complicated. At some point, we should implement buffer clearing for arbitrary
> framebuffer objects, but for now, we will just wrap ClearBuffer.
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 7 +++
> src/mesa/main/clear.c | 17 +
> src/mesa/main/clear.h | 4
> src/mesa/main/tests/dispatch_sanity.cpp| 1 +
> 4 files changed, 29 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 4cdf2f6..3f8ce50 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -177,6 +177,13 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
>
>
>
> diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
> index b5e22e3..eb283d9 100644
> --- a/src/mesa/main/clear.c
> +++ b/src/mesa/main/clear.c
> @@ -679,3 +679,20 @@ _mesa_ClearBufferfi(GLenum buffer, GLint drawbuffer,
>ctx->Stencil.Clear = clearStencilSave;
> }
> }
> +
> +/**
> + * The ClearBuffer framework is so complicated and so riddled with the
> + * assumption that the framebuffer is bound that, for now, we will just fake
> + * direct state access clearing for the user.
> + */
> +void GLAPIENTRY
> +_mesa_ClearNamedFramebufferfi(GLuint framebuffer, GLenum buffer,
> + GLfloat depth, GLint stencil)
> +{
> + GLint oldfb;
> +
> + _mesa_GetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING, &oldfb);
> + _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, framebuffer);
> + _mesa_ClearBufferfi(buffer, 0, depth, stencil);
> + _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, (GLuint) oldfb);
> +}
> diff --git a/src/mesa/main/clear.h b/src/mesa/main/clear.h
> index 582159f..c298506 100644
> --- a/src/mesa/main/clear.h
> +++ b/src/mesa/main/clear.h
> @@ -73,4 +73,8 @@ extern void GLAPIENTRY
> _mesa_ClearBufferfi(GLenum buffer, GLint drawbuffer,
> GLfloat depth, GLint stencil);
>
> +extern void GLAPIENTRY
> +_mesa_ClearNamedFramebufferfi(GLuint framebuffer, GLenum buffer,
> + GLfloat depth, GLint stencil);
> +
> #endif
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index d5a3773..91989ee 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -979,6 +979,7 @@ const struct function gl_core_functions_possible[] = {
> { "glClearNamedFramebufferiv", 45, -1 },
> { "glClearNamedFramebufferuiv", 45, -1 },
> { "glClearNamedFramebufferfv", 45, -1 },
> + { "glClearNamedFramebufferfi", 45, -1 },
> { "glBlitNamedFramebuffer", 45, -1 },
> { "glCheckNamedFramebufferStatus", 45, -1 },
> { "glGetNamedFramebufferAttachmentParameteriv", 45, -1 },
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 31/38] main: Add stubs for [Get]NamedFramebufferParameteri[v].
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> The ARB_direct_state_access specification says (as of 2015.02.05):
>"Interactions with OpenGL 4.3 or ARB_framebuffer_no_attachments
>
>If neither OpenGL 4.3 nor ARB_framebuffer_no_attachments are supported,
>ignore the support for NamedFramebufferParameteri and
>GetNamedFramebufferParameteriv."
> This commit adds stubs for these entry points.
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 12 +++
> src/mesa/main/fbobject.c | 30
> ++
> src/mesa/main/fbobject.h | 8 +++
> src/mesa/main/tests/dispatch_sanity.cpp| 2 ++
> 4 files changed, 52 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 3f8ce50..025a1a8 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -125,6 +125,12 @@
>
>
>
> +
> +
> +
> +
> +
> +
>
>
>
> @@ -205,6 +211,12 @@
>
>
>
> +
> +
> +
> +
> +
> +
>
>
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 72d87db..fc11017 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -3466,6 +3466,36 @@ _mesa_GetNamedFramebufferAttachmentParameteriv(GLuint
> framebuffer,
>"glGetNamedFramebufferAttachmentParameteriv");
> }
>
> +void GLAPIENTRY
> +_mesa_NamedFramebufferParameteri(GLuint framebuffer, GLenum pname,
> + GLint param)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> +
> + (void) framebuffer;
> + (void) pname;
> + (void) param;
> +
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "glNamedFramebufferParameteri not supported "
> + "(ARB_framebuffer_no_attachments not implemented)");
> +}
> +
> +void GLAPIENTRY
> +_mesa_GetNamedFramebufferParameteriv(GLuint framebuffer, GLenum pname,
> + GLint *param)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> +
> + (void) framebuffer;
> + (void) pname;
> + (void) param;
> +
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "glGetNamedFramebufferParameteriv not supported "
> + "(ARB_framebuffer_no_attachments not implemented)");
> +}
> +
>
> static void
> invalidate_framebuffer_storage(struct gl_context *ctx,
> diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
> index f71e885..fe9e5a8 100644
> --- a/src/mesa/main/fbobject.h
> +++ b/src/mesa/main/fbobject.h
> @@ -240,6 +240,14 @@ _mesa_GetNamedFramebufferAttachmentParameteriv(GLuint
> framebuffer,
> GLenum pname, GLint *params);
>
> extern void GLAPIENTRY
> +_mesa_NamedFramebufferParameteri(GLuint framebuffer, GLenum pname,
> + GLint param);
> +
> +extern void GLAPIENTRY
> +_mesa_GetNamedFramebufferParameteriv(GLuint framebuffer, GLenum pname,
> + GLint *param);
> +
> +extern void GLAPIENTRY
> _mesa_InvalidateSubFramebuffer(GLenum target, GLsizei numAttachments,
> const GLenum *attachments, GLint x, GLint y,
> GLsizei width, GLsizei height);
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 91989ee..01a3d14 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -972,6 +972,7 @@ const struct function gl_core_functions_possible[] = {
> { "glGetNamedBufferSubData", 45, -1 },
> { "glCreateFramebuffers", 45, -1 },
> { "glNamedFramebufferRenderbuffer", 45, -1 },
> + { "glNamedFramebufferParameteri", 45, -1 },
> { "glNamedFramebufferTexture", 45, -1 },
> { "glNamedFramebufferTextureLayer", 45, -1 },
> { "glInvalidateNamedFramebufferSubData", 45, -1 },
> @@ -982,6 +983,7 @@ const struct function gl_core_functions_possible[] = {
> { "glClearNamedFramebufferfi", 45, -1 },
> { "glBlitNamedFramebuffer", 45, -1 },
> { "glCheckNamedFramebufferStatus", 45, -1 },
> + { "glGetNamedFramebufferParameteriv", 45, -1 },
> { "glGetNamedFramebufferAttachmentParameteriv", 45, -1 },
> { "glCreateTextures", 45, -1 },
> { "glTextureStorage1D", 45, -1 },
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 32/38] main: Refactor _mesa_drawbuffers.
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mesa/drivers/common/meta.c | 3 ++-
> src/mesa/main/buffers.c| 25 -
> src/mesa/main/buffers.h| 4 +++-
> src/mesa/main/context.c| 3 ++-
> src/mesa/main/framebuffer.c| 2 +-
> 5 files changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> index fdc4cf1..6bd5ab4 100644
> --- a/src/mesa/drivers/common/meta.c
> +++ b/src/mesa/drivers/common/meta.c
> @@ -1210,7 +1210,8 @@ _mesa_meta_end(struct gl_context *ctx)
>_mesa_BindRenderbuffer(GL_RENDERBUFFER, save->RenderbufferName);
>
> if (state & MESA_META_DRAW_BUFFERS) {
> - _mesa_drawbuffers(ctx, ctx->Const.MaxDrawBuffers,
> save->ColorDrawBuffers, NULL);
> + _mesa_drawbuffers(ctx, ctx->DrawBuffer, ctx->Const.MaxDrawBuffers,
> +save->ColorDrawBuffers, NULL);
> }
>
> ctx->Meta->SaveStackDepth--;
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index 37a9790..4fdd97e 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -277,7 +277,7 @@ _mesa_DrawBuffer(GLenum buffer)
> }
>
> /* if we get here, there's no error so set new state */
> - _mesa_drawbuffers(ctx, 1, &buffer, &destMask);
> + _mesa_drawbuffers(ctx, ctx->DrawBuffer, 1, &buffer, &destMask);
>
> /*
> * Call device driver function.
> @@ -440,7 +440,7 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
> }
>
> /* OK, if we get here, there were no errors so set the new state */
> - _mesa_drawbuffers(ctx, n, buffers, destMask);
> + _mesa_drawbuffers(ctx, ctx->DrawBuffer, n, buffers, destMask);
>
> /*
> * Call device driver function. Note that n can be equal to 0,
> @@ -459,12 +459,11 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
> * actual change.
> */
> static void
> -updated_drawbuffers(struct gl_context *ctx)
> +updated_drawbuffers(struct gl_context *ctx, struct gl_framebuffer *fb)
> {
> FLUSH_VERTICES(ctx, _NEW_BUFFERS);
>
> if (ctx->API == API_OPENGL_COMPAT &&
> !ctx->Extensions.ARB_ES2_compatibility) {
> - struct gl_framebuffer *fb = ctx->DrawBuffer;
>
This blank line should probably also be removed.
With that nitpick fixed:
Reviewed-by: Fredrik Höglund
>/* Flag the FBO as requiring validation. */
>if (_mesa_is_user_fbo(fb)) {
> @@ -482,6 +481,7 @@ updated_drawbuffers(struct gl_context *ctx)
> * so nothing should go wrong at this point.
> *
> * \param ctx current context
> + * \param fb the desired draw buffer
> * \param nnumber of color outputs to set
> * \param buffers array[n] of colorbuffer names, like GL_LEFT.
> * \param destMask array[n] of BUFFER_BIT_* bitmasks which correspond to the
> @@ -489,10 +489,9 @@ updated_drawbuffers(struct gl_context *ctx)
> * BUFFER_BIT_FRONT_LEFT | BUFFER_BIT_BACK_LEFT).
> */
> void
> -_mesa_drawbuffers(struct gl_context *ctx, GLuint n, const GLenum *buffers,
> - const GLbitfield *destMask)
> +_mesa_drawbuffers(struct gl_context *ctx, struct gl_framebuffer *fb,
> + GLuint n, const GLenum *buffers, const GLbitfield
> *destMask)
> {
> - struct gl_framebuffer *fb = ctx->DrawBuffer;
> GLbitfield mask[MAX_DRAW_BUFFERS];
> GLuint buf;
>
> @@ -518,7 +517,7 @@ _mesa_drawbuffers(struct gl_context *ctx, GLuint n, const
> GLenum *buffers,
>while (destMask0) {
> GLint bufIndex = ffs(destMask0) - 1;
> if (fb->_ColorDrawBufferIndexes[count] != bufIndex) {
> -updated_drawbuffers(ctx);
> +updated_drawbuffers(ctx, fb);
> fb->_ColorDrawBufferIndexes[count] = bufIndex;
> }
> count++;
> @@ -535,14 +534,14 @@ _mesa_drawbuffers(struct gl_context *ctx, GLuint n,
> const GLenum *buffers,
> /* only one bit should be set in the destMask[buf] field */
> assert(_mesa_bitcount(destMask[buf]) == 1);
> if (fb->_ColorDrawBufferIndexes[buf] != bufIndex) {
> -updated_drawbuffers(ctx);
> +updated_drawbuffers(ctx, fb);
> fb->_ColorDrawBufferIndexes[buf] = bufIndex;
> }
> count = buf + 1;
> }
> else {
> if (fb->_ColorDrawBufferIndexes[buf] != -1) {
> -updated_drawbuffers(ctx);
> +updated_drawbuffers(ctx, fb);
> fb->_ColorDrawBufferIndexes[buf] = -1;
> }
> }
> @@ -554,7 +553,7 @@ _mesa_drawbuffers(struct gl_context *ctx, GLuint n, const
> GLenum *buffers,
> /* set remaining outputs to -1 (GL_NONE) */
> for (buf = fb->_NumColorDrawBuffers; buf < ctx->Const.MaxDrawBuffers;
> buf++) {
>if (fb->_ColorDrawBufferIndexes[buf] != -1) {
> - updated_drawbuffers(ctx);
> + updated_drawbuffers(ctx, fb);
> fb->_Color
Re: [Mesa-dev] [PATCH 33/38] main: Refactor _mesa_DrawBuffer.
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> This could have added a new DD table entry for DrawBuffer that takes an
> arbitrary draw buffer, but, after looking at the existing DD functions,
> Kenneth Graunke recommended that we just skip calling the DD functions in the
> case of ARB_direct_state_access. The DD implementations for DrawBuffer(s)
> have limited functionality, especially with respect to
> ARB_direct_state_access.
> ---
> src/mesa/main/buffers.c | 39 ---
> src/mesa/main/buffers.h | 4
> 2 files changed, 28 insertions(+), 15 deletions(-)
>
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index 4fdd97e..023d7dd 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -242,16 +242,16 @@ read_buffer_enum_to_index(GLenum buffer)
> *
> * See the GL_EXT_framebuffer_object spec for more info.
> */
> -void GLAPIENTRY
> -_mesa_DrawBuffer(GLenum buffer)
> +void
> +_mesa_draw_buffer(struct gl_context *ctx, struct gl_framebuffer *fb,
> + GLenum buffer, const char *caller)
> {
> GLbitfield destMask;
> - GET_CURRENT_CONTEXT(ctx);
>
> FLUSH_VERTICES(ctx, 0);
>
> if (MESA_VERBOSE & VERBOSE_API) {
> - _mesa_debug(ctx, "glDrawBuffer %s\n", _mesa_lookup_enum_by_nr(buffer));
> + _mesa_debug(ctx, "%s %s\n", caller, _mesa_lookup_enum_by_nr(buffer));
> }
>
> if (buffer == GL_NONE) {
> @@ -259,33 +259,42 @@ _mesa_DrawBuffer(GLenum buffer)
> }
> else {
>const GLbitfield supportedMask
> - = supported_buffer_bitmask(ctx, ctx->DrawBuffer);
> + = supported_buffer_bitmask(ctx, fb);
>destMask = draw_buffer_enum_to_bitmask(ctx, buffer);
>if (destMask == BAD_MASK) {
> /* totally bogus buffer */
> - _mesa_error(ctx, GL_INVALID_ENUM,
> - "glDrawBuffer(buffer=0x%x)", buffer);
> + _mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)", caller,
> + _mesa_lookup_enum_by_nr(buffer));
> return;
>}
>destMask &= supportedMask;
>if (destMask == 0x0) {
> /* none of the named color buffers exist! */
> - _mesa_error(ctx, GL_INVALID_OPERATION,
> - "glDrawBuffer(buffer=0x%x)", buffer);
> + _mesa_error(ctx, GL_INVALID_OPERATION, "%s(invalid buffer %s)",
> + caller, _mesa_lookup_enum_by_nr(buffer));
> return;
>}
> }
>
> /* if we get here, there's no error so set new state */
> - _mesa_drawbuffers(ctx, ctx->DrawBuffer, 1, &buffer, &destMask);
> + _mesa_drawbuffers(ctx, fb, 1, &buffer, &destMask);
>
> /*
> -* Call device driver function.
> +* Call device driver function only if calling the traditional entry
> point.
> */
> - if (ctx->Driver.DrawBuffers)
> - ctx->Driver.DrawBuffers(ctx, 1, &buffer);
> - else if (ctx->Driver.DrawBuffer)
> - ctx->Driver.DrawBuffer(ctx, buffer);
> + if (strcmp(caller, "glDrawBuffer") == 0) {
> + if (ctx->Driver.DrawBuffers)
> + ctx->Driver.DrawBuffers(ctx, 1, &buffer);
> + else if (ctx->Driver.DrawBuffer)
> + ctx->Driver.DrawBuffer(ctx, buffer);
> + }
I think it's better to call the driver hook when fb is the bound
framebuffer. This will always be the case in the traditional entry point, and
it makes NamedFramebufferDrawBuffer behave exactly like the traditional
entry point when it's passed the bound framebuffer. It looks like some
drivers depend on that behavior.
> +}
> +
> +void GLAPIENTRY
> +_mesa_DrawBuffer(GLenum buffer)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> + _mesa_draw_buffer(ctx, ctx->DrawBuffer, buffer, "glDrawBuffer");
> }
>
>
> diff --git a/src/mesa/main/buffers.h b/src/mesa/main/buffers.h
> index bc6d74a..4192afd 100644
> --- a/src/mesa/main/buffers.h
> +++ b/src/mesa/main/buffers.h
> @@ -38,6 +38,10 @@
> struct gl_context;
> struct gl_framebuffer;
>
> +extern void
> +_mesa_draw_buffer(struct gl_context *ctx, struct gl_framebuffer *fb,
> + GLenum buffer, const char *caller);
> +
> extern void GLAPIENTRY
> _mesa_DrawBuffer( GLenum mode );
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 34/38] main: Add entry point for NamedFramebufferDrawBuffer.
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 5 +
> src/mesa/main/buffers.c| 18 ++
> src/mesa/main/buffers.h| 3 +++
> src/mesa/main/tests/dispatch_sanity.cpp| 1 +
> 4 files changed, 27 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 025a1a8..c472163 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -146,6 +146,11 @@
>
>
>
> +
> +
> +
The parameter name should be "buf", not "mode".
With that fixed, this patch is:
Reviewed-by: Fredrik Höglund
> +
> +
>
>
>
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index 023d7dd..8d95c68 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -297,6 +297,24 @@ _mesa_DrawBuffer(GLenum buffer)
> _mesa_draw_buffer(ctx, ctx->DrawBuffer, buffer, "glDrawBuffer");
> }
>
> +void GLAPIENTRY
> +_mesa_NamedFramebufferDrawBuffer(GLuint framebuffer, GLenum buf)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> + struct gl_framebuffer *fb;
> +
> + if (framebuffer) {
> + fb = _mesa_lookup_framebuffer_err(ctx, framebuffer,
> +"glNamedFramebufferDrawBuffer");
> + if (!fb)
> + return;
> + }
> + else
> + fb = ctx->WinSysDrawBuffer;
> +
> + _mesa_draw_buffer(ctx, fb, buf, "glNamedFramebufferDrawBuffer");
> +}
> +
>
> /**
> * Called by glDrawBuffersARB; specifies the destination color renderbuffers
> diff --git a/src/mesa/main/buffers.h b/src/mesa/main/buffers.h
> index 4192afd..12d5743 100644
> --- a/src/mesa/main/buffers.h
> +++ b/src/mesa/main/buffers.h
> @@ -46,6 +46,9 @@ extern void GLAPIENTRY
> _mesa_DrawBuffer( GLenum mode );
>
> extern void GLAPIENTRY
> +_mesa_NamedFramebufferDrawBuffer(GLuint framebuffer, GLenum buf);
> +
> +extern void GLAPIENTRY
> _mesa_DrawBuffers(GLsizei n, const GLenum *buffers);
>
> extern void
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 01a3d14..16caf24 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -975,6 +975,7 @@ const struct function gl_core_functions_possible[] = {
> { "glNamedFramebufferParameteri", 45, -1 },
> { "glNamedFramebufferTexture", 45, -1 },
> { "glNamedFramebufferTextureLayer", 45, -1 },
> + { "glNamedFramebufferDrawBuffer", 45, -1 },
> { "glInvalidateNamedFramebufferSubData", 45, -1 },
> { "glInvalidateNamedFramebufferData", 45, -1 },
> { "glClearNamedFramebufferiv", 45, -1 },
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 35/38] main: Refactor _mesa_ReadBuffer.
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> This could have added a new DD table entry for ReadBuffer that takes an
> arbitrary read buffer, but, after looking at the existing DD functions,
> Kenneth Graunke recommended that we just skip calling the DD functions in the
> case of ARB_direct_state_access. The DD implementations for ReadBuffer
> have limited functionality, especially with respect to
> ARB_direct_state_access.
> ---
> src/mesa/main/buffers.c | 45 +
> src/mesa/main/buffers.h | 7 ++-
> src/mesa/main/context.c | 2 +-
> 3 files changed, 32 insertions(+), 22 deletions(-)
>
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index 8d95c68..e244d1e 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -624,11 +624,10 @@ _mesa_update_draw_buffers(struct gl_context *ctx)
> * \param bufferIndex the numerical index corresponding to 'buffer'
> */
> void
> -_mesa_readbuffer(struct gl_context *ctx, GLenum buffer, GLint bufferIndex)
> +_mesa_readbuffer(struct gl_context *ctx, struct gl_framebuffer *fb,
> + GLenum buffer, GLint bufferIndex)
> {
> - struct gl_framebuffer *fb = ctx->ReadBuffer;
> -
> - if (_mesa_is_winsys_fbo(fb)) {
> + if ((fb == ctx->ReadBuffer) && _mesa_is_winsys_fbo(fb)) {
>/* Only update the per-context READ_BUFFER state if we're bound to
> * a window-system framebuffer.
> */
> @@ -647,23 +646,17 @@ _mesa_readbuffer(struct gl_context *ctx, GLenum buffer,
> GLint bufferIndex)
> * Called by glReadBuffer to set the source renderbuffer for reading pixels.
> * \param mode color buffer such as GL_FRONT, GL_BACK, etc.
> */
> -void GLAPIENTRY
> -_mesa_ReadBuffer(GLenum buffer)
> +void
> +_mesa_read_buffer(struct gl_context *ctx, struct gl_framebuffer *fb,
> + GLenum buffer, const char *caller)
> {
> - struct gl_framebuffer *fb;
> GLbitfield supportedMask;
> GLint srcBuffer;
> - GET_CURRENT_CONTEXT(ctx);
>
> FLUSH_VERTICES(ctx, 0);
>
> if (MESA_VERBOSE & VERBOSE_API)
> - _mesa_debug(ctx, "glReadBuffer %s\n", _mesa_lookup_enum_by_nr(buffer));
> -
> - fb = ctx->ReadBuffer;
> -
> - if (MESA_VERBOSE & VERBOSE_API)
> - _mesa_debug(ctx, "glReadBuffer %s\n", _mesa_lookup_enum_by_nr(buffer));
> + _mesa_debug(ctx, "%s %s\n", caller, _mesa_lookup_enum_by_nr(buffer));
>
> if (buffer == GL_NONE) {
>/* This is legal--it means that no buffer should be bound for reading.
> */
> @@ -674,24 +667,36 @@ _mesa_ReadBuffer(GLenum buffer)
>srcBuffer = read_buffer_enum_to_index(buffer);
>if (srcBuffer == -1) {
> _mesa_error(ctx, GL_INVALID_ENUM,
> - "glReadBuffer(buffer=0x%x)", buffer);
> + "%s(invalid buffer %s)", caller,
> + _mesa_lookup_enum_by_nr(buffer));
> return;
>}
>supportedMask = supported_buffer_bitmask(ctx, fb);
>if (((1 << srcBuffer) & supportedMask) == 0) {
> _mesa_error(ctx, GL_INVALID_OPERATION,
> - "glReadBuffer(buffer=0x%x)", buffer);
> + "%s(invalid buffer %s)", caller,
> + _mesa_lookup_enum_by_nr(buffer));
> return;
>}
> }
>
> /* OK, all error checking has been completed now */
>
> - _mesa_readbuffer(ctx, buffer, srcBuffer);
> + _mesa_readbuffer(ctx, fb, buffer, srcBuffer);
>
> /*
> -* Call device driver function.
> +* Call the device driver function only if caller is the traditional entry
> +* point.
> */
> - if (ctx->Driver.ReadBuffer)
> - (*ctx->Driver.ReadBuffer)(ctx, buffer);
> + if (strcmp(caller, "glReadBuffer") == 0) {
> + if (ctx->Driver.ReadBuffer)
> + (*ctx->Driver.ReadBuffer)(ctx, buffer);
> + }
> +}
As in patch 33, I think the test should be whether fb is the currently
bound framebuffer.
> +
> +void GLAPIENTRY
> +_mesa_ReadBuffer(GLenum buffer)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> + _mesa_read_buffer(ctx, ctx->ReadBuffer, buffer, "glReadBuffer");
> }
> diff --git a/src/mesa/main/buffers.h b/src/mesa/main/buffers.h
> index 12d5743..ca7ad19 100644
> --- a/src/mesa/main/buffers.h
> +++ b/src/mesa/main/buffers.h
> @@ -57,12 +57,17 @@ _mesa_drawbuffers(struct gl_context *ctx, struct
> gl_framebuffer *fb,
>const GLbitfield *destMask);
>
> extern void
> -_mesa_readbuffer(struct gl_context *ctx, GLenum buffer, GLint bufferIndex);
> +_mesa_readbuffer(struct gl_context *ctx, struct gl_framebuffer *fb,
> + GLenum buffer, GLint bufferIndex);
>
> extern void
> _mesa_update_draw_buffers(struct gl_context *ctx);
>
>
> +extern void
> +_mesa_read_buffer(struct gl_context *ctx, struct gl_framebuffer *fb,
> + GLenum buffer, const char *caller);
> +
> extern void GLAPIENTRY
> _mesa_ReadBuffer( GLenum mode );
>
> diff --git a/src/mesa/ma
Re: [Mesa-dev] [PATCH 36/38] main: Add entry point for NamedFramebufferReadBuffer.
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 5 +
> src/mesa/main/buffers.c| 18 ++
> src/mesa/main/buffers.h| 3 +++
> src/mesa/main/tests/dispatch_sanity.cpp| 1 +
> 4 files changed, 27 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index c472163..1bdb29c 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -151,6 +151,11 @@
>
>
>
> +
> +
> +
The parameter name should be "src", not "mode".
With that fixed, this patch is:
Reviewed-by: Fredrik Höglund
> +
> +
>
>
>
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index e244d1e..d0627b5 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -700,3 +700,21 @@ _mesa_ReadBuffer(GLenum buffer)
> GET_CURRENT_CONTEXT(ctx);
> _mesa_read_buffer(ctx, ctx->ReadBuffer, buffer, "glReadBuffer");
> }
> +
> +void GLAPIENTRY
> +_mesa_NamedFramebufferReadBuffer(GLuint framebuffer, GLenum src)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> + struct gl_framebuffer *fb;
> +
> + if (framebuffer) {
> + fb = _mesa_lookup_framebuffer_err(ctx, framebuffer,
> +"glNamedFramebufferReadBuffer");
> + if (!fb)
> + return;
> + }
> + else
> + fb = ctx->WinSysReadBuffer;
> +
> + _mesa_read_buffer(ctx, fb, src, "glNamedFramebufferReadBuffer");
> +}
> diff --git a/src/mesa/main/buffers.h b/src/mesa/main/buffers.h
> index ca7ad19..52a2318 100644
> --- a/src/mesa/main/buffers.h
> +++ b/src/mesa/main/buffers.h
> @@ -71,5 +71,8 @@ _mesa_read_buffer(struct gl_context *ctx, struct
> gl_framebuffer *fb,
> extern void GLAPIENTRY
> _mesa_ReadBuffer( GLenum mode );
>
> +extern void GLAPIENTRY
> +_mesa_NamedFramebufferReadBuffer(GLuint framebuffer, GLenum src);
> +
>
> #endif
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 16caf24..0afb650 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -976,6 +976,7 @@ const struct function gl_core_functions_possible[] = {
> { "glNamedFramebufferTexture", 45, -1 },
> { "glNamedFramebufferTextureLayer", 45, -1 },
> { "glNamedFramebufferDrawBuffer", 45, -1 },
> + { "glNamedFramebufferReadBuffer", 45, -1 },
> { "glInvalidateNamedFramebufferSubData", 45, -1 },
> { "glInvalidateNamedFramebufferData", 45, -1 },
> { "glClearNamedFramebufferiv", 45, -1 },
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 37/38] main: Refactor DrawBuffers.
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> This could have added a new DD table entry for DrawBuffers that takes an
> arbitrary draw buffer, but, after looking at the existing DD functions,
> Kenneth Graunke recommended that we just skip calling the DD functions in the
> case of ARB_direct_state_access. The DD implementations for DrawBuffer(s)
> have limited functionality, especially with respect to
> ARB_direct_state_access.
> ---
> src/mesa/main/buffers.c | 70
> +
> src/mesa/main/buffers.h | 4 +++
> 2 files changed, 51 insertions(+), 23 deletions(-)
>
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index d0627b5..32986f5 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -325,13 +325,13 @@ _mesa_NamedFramebufferDrawBuffer(GLuint framebuffer,
> GLenum buf)
> * names cannot specify more than one buffer. For example,
> * GL_FRONT_AND_BACK is illegal.
> */
> -void GLAPIENTRY
> -_mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
> +void
> +_mesa_draw_buffers(struct gl_context *ctx, struct gl_framebuffer *fb,
> + GLsizei n, const GLenum *buffers, const char *caller)
> {
> GLuint output;
> GLbitfield usedBufferMask, supportedMask;
> GLbitfield destMask[MAX_DRAW_BUFFERS];
> - GET_CURRENT_CONTEXT(ctx);
>
> FLUSH_VERTICES(ctx, 0);
>
> @@ -342,12 +342,18 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
> * "An INVALID_VALUE error is generated if n is greater than
> * MAX_DRAW_BUFFERS."
> */
> - if (n < 0 || n > (GLsizei) ctx->Const.MaxDrawBuffers) {
> - _mesa_error(ctx, GL_INVALID_VALUE, "glDrawBuffersARB(n)");
> + if (n < 0) {
> + _mesa_error(ctx, GL_INVALID_VALUE, "%s(n < 0)", caller);
> + return;
> + }
> +
> + if (n > (GLsizei) ctx->Const.MaxDrawBuffers) {
> + _mesa_error(ctx, GL_INVALID_VALUE,
> + "%s(n > maximum number of draw buffers)", caller);
>return;
> }
>
> - supportedMask = supported_buffer_bitmask(ctx, ctx->DrawBuffer);
> + supportedMask = supported_buffer_bitmask(ctx, fb);
> usedBufferMask = 0x0;
>
> /* From the ES 3.0 specification, page 180:
> @@ -355,9 +361,9 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
> * and the constant must be BACK or NONE."
> * (same restriction applies with GL_EXT_draw_buffers specification)
> */
> - if (ctx->API == API_OPENGLES2 && _mesa_is_winsys_fbo(ctx->DrawBuffer) &&
> + if (ctx->API == API_OPENGLES2 && _mesa_is_winsys_fbo(fb) &&
> (n != 1 || (buffers[0] != GL_NONE && buffers[0] != GL_BACK))) {
> - _mesa_error(ctx, GL_INVALID_OPERATION, "glDrawBuffers(buffer)");
> + _mesa_error(ctx, GL_INVALID_OPERATION, "%s(invalid buffers)", caller);
>return;
> }
>
> @@ -389,9 +395,11 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
>* or equal to the value of MAX_COLOR_ATTACHMENTS, then the
> error
>* INVALID_OPERATION results."
>*/
> - if (_mesa_is_user_fbo(ctx->DrawBuffer) && buffers[output] >=
> + if (_mesa_is_user_fbo(fb) && buffers[output] >=
> GL_COLOR_ATTACHMENT0 + ctx->Const.MaxDrawBuffers) {
> -_mesa_error(ctx, GL_INVALID_OPERATION,
> "glDrawBuffersARB(buffer)");
> +_mesa_error(ctx, GL_INVALID_OPERATION,
> +"%s(buffers[%d] >= maximum number of draw buffers)",
> +caller, output);
> return;
> }
>
> @@ -402,9 +410,10 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
>* 4.5 or 4.6. Otherwise, an INVALID_ENUM error is generated.
>*/
> if (destMask[output] == BAD_MASK) {
> -_mesa_error(ctx, GL_INVALID_ENUM, "glDrawBuffersARB(buffer)");
> +_mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)",
> +caller, _mesa_lookup_enum_by_nr(buffers[output]));
> return;
> - }
> + }
>
> /* From the OpenGL 4.0 specification, page 256:
>* "For both the default framebuffer and framebuffer objects, the
> @@ -417,7 +426,8 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
>* but the Khronos conformance tests expect INVALID_ENUM.
>*/
> if (_mesa_bitcount(destMask[output]) > 1) {
> -_mesa_error(ctx, GL_INVALID_ENUM, "glDrawBuffersARB(buffer)");
> +_mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)",
> +caller, _mesa_lookup_enum_by_nr(buffers[output]));
> return;
> }
>
> @@ -434,7 +444,8 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
> destMask[output] &= supportedMask;
> if (destMask[output] == 0) {
> _mesa_error(ctx, GL_INVALID_OPERATION,
> -"glDrawBuffer
Re: [Mesa-dev] [PATCH 38/38] main: Add entry point for NamedFramebufferDrawBuffers.
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 6 ++
> src/mesa/main/buffers.c| 19 +++
> src/mesa/main/buffers.h| 4
> src/mesa/main/tests/dispatch_sanity.cpp| 1 +
> 4 files changed, 30 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 1bdb29c..87483a0 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -151,6 +151,12 @@
>
>
>
> +
> +
> +
> +
> +
> +
>
>
>
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index 32986f5..6305cdf 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -504,6 +504,25 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
> _mesa_draw_buffers(ctx, ctx->DrawBuffer, n, buffers, "glDrawBuffers");
> }
>
> +void GLAPIENTRY
> +_mesa_NamedFramebufferDrawBuffers(GLuint framebuffer, GLsizei n,
> + const GLenum *bufs)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> + struct gl_framebuffer *fb;
> +
> + if (framebuffer) {
> + fb = _mesa_lookup_framebuffer_err(ctx, framebuffer,
> +"glNamedFramebufferDrawBuffers");
> + if (!fb)
> + return;
> + }
> + else
> + fb = ctx->WinSysDrawBuffer;
> +
> + _mesa_draw_buffers(ctx, fb, n, bufs, "glNamedFramebufferDrawBuffers");
> +}
> +
>
> /**
> * Performs necessary state updates when _mesa_drawbuffers makes an
> diff --git a/src/mesa/main/buffers.h b/src/mesa/main/buffers.h
> index 66871d7..5aa79fd 100644
> --- a/src/mesa/main/buffers.h
> +++ b/src/mesa/main/buffers.h
> @@ -55,6 +55,10 @@ _mesa_draw_buffers(struct gl_context *ctx, struct
> gl_framebuffer *fb,
> extern void GLAPIENTRY
> _mesa_DrawBuffers(GLsizei n, const GLenum *buffers);
>
> +extern void GLAPIENTRY
> +_mesa_NamedFramebufferDrawBuffers(GLuint framebuffer, GLsizei n,
> + const GLenum *bufs);
> +
> extern void
> _mesa_drawbuffers(struct gl_context *ctx, struct gl_framebuffer *fb,
>GLuint n, const GLenum *buffers,
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 0afb650..e9a26ca 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -976,6 +976,7 @@ const struct function gl_core_functions_possible[] = {
> { "glNamedFramebufferTexture", 45, -1 },
> { "glNamedFramebufferTextureLayer", 45, -1 },
> { "glNamedFramebufferDrawBuffer", 45, -1 },
> + { "glNamedFramebufferDrawBuffers", 45, -1 },
> { "glNamedFramebufferReadBuffer", 45, -1 },
> { "glInvalidateNamedFramebufferSubData", 45, -1 },
> { "glInvalidateNamedFramebufferData", 45, -1 },
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Add marketing names for CHV
From: Ville Syrjälä All CHV devices will be branded as "Intel(r) HD Graphics". Signed-off-by: Ville Syrjälä --- include/pci_ids/i965_pci_ids.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h index 3e3e8fe..8d757aa 100644 --- a/include/pci_ids/i965_pci_ids.h +++ b/include/pci_ids/i965_pci_ids.h @@ -124,7 +124,7 @@ CHIPSET(0x1921, skl_gt2, "Intel(R) Skylake ULT GT2F") CHIPSET(0x1926, skl_gt3, "Intel(R) Skylake ULT GT3") CHIPSET(0x192A, skl_gt3, "Intel(R) Skylake SRV GT3") CHIPSET(0x192B, skl_gt3, "Intel(R) Skylake Halo GT3") -CHIPSET(0x22B0, chv, "Intel(R) Cherryview") -CHIPSET(0x22B1, chv, "Intel(R) Cherryview") -CHIPSET(0x22B2, chv, "Intel(R) Cherryview") -CHIPSET(0x22B3, chv, "Intel(R) Cherryview") +CHIPSET(0x22B0, chv, "Intel(R) HD Graphics (Cherryview)") +CHIPSET(0x22B1, chv, "Intel(R) HD Graphics (Cherryview)") +CHIPSET(0x22B2, chv, "Intel(R) HD Graphics (Cherryview)") +CHIPSET(0x22B3, chv, "Intel(R) HD Graphics (Cherryview)") -- 2.0.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Add marketing names for CHV
On Thursday, April 16, 2015 09:00:46 PM ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > All CHV devices will be branded as "Intel(r) HD Graphics". > > Signed-off-by: Ville Syrjälä > --- > include/pci_ids/i965_pci_ids.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h > index 3e3e8fe..8d757aa 100644 > --- a/include/pci_ids/i965_pci_ids.h > +++ b/include/pci_ids/i965_pci_ids.h > @@ -124,7 +124,7 @@ CHIPSET(0x1921, skl_gt2, "Intel(R) Skylake ULT GT2F") > CHIPSET(0x1926, skl_gt3, "Intel(R) Skylake ULT GT3") > CHIPSET(0x192A, skl_gt3, "Intel(R) Skylake SRV GT3") > CHIPSET(0x192B, skl_gt3, "Intel(R) Skylake Halo GT3") > -CHIPSET(0x22B0, chv, "Intel(R) Cherryview") > -CHIPSET(0x22B1, chv, "Intel(R) Cherryview") > -CHIPSET(0x22B2, chv, "Intel(R) Cherryview") > -CHIPSET(0x22B3, chv, "Intel(R) Cherryview") > +CHIPSET(0x22B0, chv, "Intel(R) HD Graphics (Cherryview)") > +CHIPSET(0x22B1, chv, "Intel(R) HD Graphics (Cherryview)") > +CHIPSET(0x22B2, chv, "Intel(R) HD Graphics (Cherryview)") > +CHIPSET(0x22B3, chv, "Intel(R) HD Graphics (Cherryview)") > Thank you for leaving Cherryview here - I like to have that there so it's unique and identifiable. Reviewed-by: Kenneth Graunke signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Add marketing names for CHV
On Thu, Apr 16, 2015 at 11:20:01AM -0700, Kenneth Graunke wrote: > On Thursday, April 16, 2015 09:00:46 PM ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > All CHV devices will be branded as "Intel(r) HD Graphics". > > > > Signed-off-by: Ville Syrjälä > > --- > > include/pci_ids/i965_pci_ids.h | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h > > index 3e3e8fe..8d757aa 100644 > > --- a/include/pci_ids/i965_pci_ids.h > > +++ b/include/pci_ids/i965_pci_ids.h > > @@ -124,7 +124,7 @@ CHIPSET(0x1921, skl_gt2, "Intel(R) Skylake ULT GT2F") > > CHIPSET(0x1926, skl_gt3, "Intel(R) Skylake ULT GT3") > > CHIPSET(0x192A, skl_gt3, "Intel(R) Skylake SRV GT3") > > CHIPSET(0x192B, skl_gt3, "Intel(R) Skylake Halo GT3") > > -CHIPSET(0x22B0, chv, "Intel(R) Cherryview") > > -CHIPSET(0x22B1, chv, "Intel(R) Cherryview") > > -CHIPSET(0x22B2, chv, "Intel(R) Cherryview") > > -CHIPSET(0x22B3, chv, "Intel(R) Cherryview") > > +CHIPSET(0x22B0, chv, "Intel(R) HD Graphics (Cherryview)") > > +CHIPSET(0x22B1, chv, "Intel(R) HD Graphics (Cherryview)") > > +CHIPSET(0x22B2, chv, "Intel(R) HD Graphics (Cherryview)") > > +CHIPSET(0x22B3, chv, "Intel(R) HD Graphics (Cherryview)") > > > > Thank you for leaving Cherryview here - I like to have that there so > it's unique and identifiable. Yep, that was my thinking as well. Otherwise we'd have just a bazillion "HD Graphics" entries and everyone would be even more confused. > > Reviewed-by: Kenneth Graunke Thanks. -- Ville Syrjälä Intel OTC ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] Hash-table and hash-set, V4
Eric Anholt writes: > Jason Ekstrand writes: > >> On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland >> wrote: >>> The performance numbers (shader-db runtime) are: >>> >>> Difference at 95.0% confidence >>> -14.7608 +/- 3.36786 >>> -9.05064% +/- 2.06501% >>> (Original runtime was 160 seconds) >> >> Good Work! >> >> I had one comment on the hash set patch. With that fixed, the series is >> >> Reviewed-by: Jason Ekstrand >> >> Probably want to give Eric a a couple of days to look at it too. > > Yeah, I'm splitting the series up into each individual change (resizing > cutoff, linear probing, power-of-two, then quadratic probing) so that we > can make sure that they're all good for both the compiler and GL object > lookup. OK, I've got a split out series on hash-quadratic of my tree. Here's be bad news from the last commit: However, over the course of this series, INTEL_NO_HW=1 minecraft is still down by -0.615582% +/- 0.514508% (n=55). If we drop 2 low outliers each from before/after of that dataset, the image is more clear: -0.538901% +/- 0.381768% (n=53). It looks like the collision reprobe changes are hurting too much. The fact that collision is that big of a deal is bad -- I thought we should be having basically no collision in Mesa's GL hash tables, but I guess a lot of objects have been deleted before new ones are genned (and this probably also means that our benchmarking, which tends to execute a timedemo once instead of doing level loads multiple times, is underestimating the problems we have in our GL name hash tables). This probably means we should be looking into making GL gen its handles from the lowest unused number when possible, and using an array for most of the hash table. Until we do, I don't think we want to change our hash table to improve compiler performance at the expense of runtime performance. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/ttn: fix TXF
From: Rob Clark
There is an level param stashed away in the .w component of the first
src.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 6c8d3fc..59aaf67 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -1053,7 +1053,7 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
break;
case TGSI_OPCODE_TXF:
op = nir_texop_txf;
- num_srcs = 1;
+ num_srcs = 2;
break;
case TGSI_OPCODE_TXD:
op = nir_texop_txd;
@@ -1138,6 +1138,12 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
src_number++;
}
+ if (tgsi_inst->Instruction.Opcode == TGSI_OPCODE_TXF) {
+ instr->src[src_number].src = nir_src_for_ssa(ttn_channel(b, src[0], W));
+ instr->src[src_number].src_type = nir_tex_src_lod;
+ src_number++;
+ }
+
if (tgsi_inst->Instruction.Opcode == TGSI_OPCODE_TXD) {
instr->src[src_number].src =
nir_src_for_ssa(nir_swizzle(b, src[1], SWIZ(X, Y, Z, W),
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] i965: Add XRGB8888 format to intel_screen_make_configs
Hi,
On 9 April 2015 at 17:20, Kristian Høgsberg wrote:
> On Wed, Apr 8, 2015 at 11:37 AM, Emil Velikov
> wrote:
>> Hi all,
>>
>> Can we get a pair of eyes on this patch please ?
>
> Reviewed-by: Kristian Høgsberg
>
> Thanks for the reminder.
Mind you, this does break 75b7e1df13, which explicitly removes them in
order to 'fix' (scare quotes in original) a conformance test. That
commit also made our lives harder with
https://bugs.freedesktop.org/show_bug.cgi?id=67676 for which the
suggested fix was a separate EGL_XXX_transparent_alpha extension, but
between the two of these, it does seem like a more nuanced fix might
be in order.
Not being able to choose between XRGB and ARGB formats in the GBM
backend does actually impair our ability to hoist ARGB content to
planes, so at the very least, we'd need to duplicate ARGB
driver_configs in the EGLConfig list: one for an ARGB native visual
ID, and one for XRGB.
Any thoughts?
Cheers,
Daniel
> Kristian
>
>>
>> Boyan
>> For the future can you please include the CC mesa-stable line in the
>> commit message. It will make things a bit more obvious as I'm pursing
>> through the list :-)
>>
>> Thanks
>> Emil
>>
>> On 25 March 2015 at 11:36, Boyan Ding wrote:
>>> Some application, such as drm backend of weston, uses XRGB config as
>>> default. i965 doesn't provide this format, but before commit 65c8965d,
>>> the drm platform of EGL takes ARGB as XRGB. Now that commit
>>> 65c8965d makes EGL recognize format correctly so weston won't start
>>> because it can't find XRGB. Add XRGB format to i965 just as
>>> other drivers do.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
>>> Signed-off-by: Boyan Ding
>>> ---
>>> src/mesa/drivers/dri/i965/intel_screen.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>>> b/src/mesa/drivers/dri/i965/intel_screen.c
>>> index 3640b67..2b82c33 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>>> @@ -1126,7 +1126,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
>>> {
>>> static const mesa_format formats[] = {
>>>MESA_FORMAT_B5G6R5_UNORM,
>>> - MESA_FORMAT_B8G8R8A8_UNORM
>>> + MESA_FORMAT_B8G8R8A8_UNORM,
>>> + MESA_FORMAT_B8G8R8X8_UNORM
>>> };
>>>
>>> /* GLX_SWAP_COPY_OML is not supported due to page flipping. */
>>> --
>>> 2.3.3
>>>
>>> ___
>>> mesa-stable mailing list
>>> mesa-sta...@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-stable
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] mesa: add check for NV_texture_barrier in _mesa_TextureBarrierNV()
If an app called glTextureBarrierNV() without checking if the
extension was available, we'd crash with some gallium drivers
in st_TextureBarrier() because the pipe_context::texture_barrier()
pointer was NULL.
Generate GL_INVALID_OPERATION instead.
---
src/mesa/main/texturebarrier.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/main/texturebarrier.c b/src/mesa/main/texturebarrier.c
index 08ff561..4b2dda5 100644
--- a/src/mesa/main/texturebarrier.c
+++ b/src/mesa/main/texturebarrier.c
@@ -49,5 +49,11 @@ _mesa_TextureBarrierNV(void)
{
GET_CURRENT_CONTEXT(ctx);
+ if (!ctx->Extensions.NV_texture_barrier) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glTextureBarrierNV(not supported)");
+ return;
+ }
+
ctx->Driver.TextureBarrier(ctx);
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glsl: rewrite glsl_type::record_key_hash() to avoid buffer overflow
This should be more efficient than the previous snprintf() solution.
But more importantly, it avoids a buffer overflow bug that could result
in crashes or unpredictable results when processing very large interface
blocks.
For the app in question, key->length = 103 for some interfaces. The check
if size >= sizeof(hash_key) was insufficient to prevent overflows of the
hash_key[128] array because it didn't account for the terminating zero.
In this case, this caused the call to hash_table_string_hash() to return
different results for identical inputs, and then shader linking failed.
This new solution also takes all structure fields into account instead
of just the first 15 when sizeof(pointer)==8.
Cc: mesa-sta...@lists.freedesktop.org
---
src/glsl/glsl_types.cpp | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 4aa36a7..9c9b7ef 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -738,24 +738,27 @@ glsl_type::record_key_compare(const void *a, const void
*b)
}
+/**
+ * Generate an integer hash value for a glsl_type structure type.
+ */
unsigned
glsl_type::record_key_hash(const void *a)
{
const glsl_type *const key = (glsl_type *) a;
- char hash_key[128];
- unsigned size = 0;
-
- size = snprintf(hash_key, sizeof(hash_key), "%08x", key->length);
+ uintptr_t hash = key->length;
+ unsigned retval;
for (unsigned i = 0; i < key->length; i++) {
- if (size >= sizeof(hash_key))
-break;
-
- size += snprintf(& hash_key[size], sizeof(hash_key) - size,
- "%p", (void *) key->fields.structure[i].type);
+ /* casting pointer to uintptr_t */
+ hash = (hash * 13 ) + (uintptr_t) key->fields.structure[i].type;
}
- return hash_table_string_hash(& hash_key);
+ if (sizeof(hash) == 8)
+ retval = (hash & 0x) ^ ((uint64_t) hash >> 32);
+ else
+ retval = hash;
+
+ return retval;
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] main: silence missing return value warning in array_index_of_resource()
--- src/mesa/main/shader_query.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp index b5f1d08..ad936e5 100644 --- a/src/mesa/main/shader_query.cpp +++ b/src/mesa/main/shader_query.cpp @@ -537,6 +537,7 @@ array_index_of_resource(struct gl_program_resource *res, return get_matching_index(RESOURCE_VAR(res), name); default: assert(!"support for resource type not implemented"); + return 0; } } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] mesa: add check for NV_texture_barrier in _mesa_TextureBarrierNV()
Reviewed-by: Ilia Mirkin
Consider dropping the NV from the message as the same callback is used
for ARB_texture_barrier.
On Thu, Apr 16, 2015 at 5:52 PM, Brian Paul wrote:
> If an app called glTextureBarrierNV() without checking if the
> extension was available, we'd crash with some gallium drivers
> in st_TextureBarrier() because the pipe_context::texture_barrier()
> pointer was NULL.
>
> Generate GL_INVALID_OPERATION instead.
> ---
> src/mesa/main/texturebarrier.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/mesa/main/texturebarrier.c b/src/mesa/main/texturebarrier.c
> index 08ff561..4b2dda5 100644
> --- a/src/mesa/main/texturebarrier.c
> +++ b/src/mesa/main/texturebarrier.c
> @@ -49,5 +49,11 @@ _mesa_TextureBarrierNV(void)
> {
> GET_CURRENT_CONTEXT(ctx);
>
> + if (!ctx->Extensions.NV_texture_barrier) {
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "glTextureBarrierNV(not supported)");
> + return;
> + }
> +
> ctx->Driver.TextureBarrier(ctx);
> }
> --
> 1.9.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
[Mesa-dev] [PATCH 0/3] Hash-table and hash-set, V4
2015-04-16 21:16 GMT+02:00 Eric Anholt : > Eric Anholt writes: > >> Jason Ekstrand writes: >> >>> On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland >>> wrote: The performance numbers (shader-db runtime) are: Difference at 95.0% confidence -14.7608 +/- 3.36786 -9.05064% +/- 2.06501% (Original runtime was 160 seconds) >>> >>> Good Work! >>> >>> I had one comment on the hash set patch. With that fixed, the series is >>> >>> Reviewed-by: Jason Ekstrand >>> >>> Probably want to give Eric a a couple of days to look at it too. >> >> Yeah, I'm splitting the series up into each individual change (resizing >> cutoff, linear probing, power-of-two, then quadratic probing) so that we >> can make sure that they're all good for both the compiler and GL object >> lookup. > > OK, I've got a split out series on hash-quadratic of my tree. Here's be > bad news from the last commit: > > However, over the course of this series, INTEL_NO_HW=1 minecraft is still > down by -0.615582% +/- 0.514508% (n=55). If we drop 2 low outliers each > from before/after of that dataset, the image is more clear: -0.538901% +/- > 0.381768% (n=53). > > It looks like the collision reprobe changes are hurting too much. The > fact that collision is that big of a deal is bad -- I thought we should > be having basically no collision in Mesa's GL hash tables, but I guess a > lot of objects have been deleted before new ones are genned (and this > probably also means that our benchmarking, which tends to execute a > timedemo once instead of doing level loads multiple times, is > underestimating the problems we have in our GL name hash tables). This > probably means we should be looking into making GL gen its handles from > the lowest unused number when possible, and using an array for most of > the hash table. Until we do, I don't think we want to change our hash > table to improve compiler performance at the expense of runtime > performance. Well, that's rather unfortunate. Thanks for giving this a thorough review. Decreasing the load factor of the table should decrease lookup cost, and while that did not do much for the run-time of shader-db, it might improve your test case. Robin-Hood hashing is also a possibility. It apparently works well for hash tables with a load factor up to 0.9. The average reprobe length is then approximately 6 reprobes. Reducing the load factor should lower it even more. Robin-Hood because you "steal" from the entries with a short reprobe length and "give" to those with a long one by swapping entries when inserting in the table. I've only seen it used with linear probing, but I don't see why it couldn't be done with a quadratic probing implementation. It's a bit more complicated, as one also needs to handle deletion smarter by "back-shifting", or else performance will degrade as a lot deletes are performed. However, lookup-speed is very good since clusters of entries will be sorted by hash, and therefore we can exit early when doing a lookup if the hash we are searching for is less than the hash we are now checking against. If there's interest I can take a shot at that too. -Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/ttn: fix TXF
Rob Clark writes: > From: Rob Clark > > There is an level param stashed away in the .w component of the first > src. "a" level param, but other than that: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] i965: Make shader_time store names/ids instead of referencing shaders.
On Wed, Apr 15, 2015 at 2:24 AM, Kenneth Graunke
wrote:
> Jason noticed that shader_time was bumping the reference count on the
> gl_shader_program and gl_program structures, in code called during
> compilation.
>
> Not only were these never unreferenced, but it meant fragment shaders
> might be referenced twice (SIMD8 and SIMD16)...or only once.
>
> We don't actually need the programs. We just need their numeric ID and
> their language (GLSL/ARB/FF) or KHR_debug label. If there's a label, we
> have to strdup it since the underlying program could be deleted.
>
> To be fair, we're not exactly cleaning that up either, but we at least
> ralloc it out of the shader_time arrays, so if we ever bother cleaning
> those up, they'll go away properly.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 4 +--
> src/mesa/drivers/dri/i965/brw_program.c | 52
> +++--
> 2 files changed, 19 insertions(+), 37 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 0bd0ed1..a6d6787 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1454,8 +1454,8 @@ struct brw_context
>
> struct {
>drm_intel_bo *bo;
> - struct gl_shader_program **shader_programs;
> - struct gl_program **programs;
> + const char **names;
> + int *ids;
>enum shader_time_shader_type *types;
>uint64_t *cumulative;
>int num_entries;
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c
> b/src/mesa/drivers/dri/i965/brw_program.c
> index 7ea08e6..81a0c19 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -294,10 +294,8 @@ brw_init_shader_time(struct brw_context *brw)
> brw->shader_time.bo = drm_intel_bo_alloc(brw->bufmgr, "shader time",
> max_entries *
> SHADER_TIME_STRIDE,
> 4096);
> - brw->shader_time.shader_programs = rzalloc_array(brw, struct
> gl_shader_program *,
> -max_entries);
> - brw->shader_time.programs = rzalloc_array(brw, struct gl_program *,
> - max_entries);
> + brw->shader_time.names = rzalloc_array(brw, const char *, max_entries);
> + brw->shader_time.ids = rzalloc_array(brw, int, max_entries);
> brw->shader_time.types = rzalloc_array(brw, enum
> shader_time_shader_type,
>max_entries);
> brw->shader_time.cumulative = rzalloc_array(brw, uint64_t,
> @@ -434,36 +432,15 @@ brw_report_shader_time(struct brw_context *brw)
> fprintf(stderr, "\n");
> fprintf(stderr, "type ID cycles spent
>%% of total\n");
> for (int s = 0; s < brw->shader_time.num_entries; s++) {
> - const char *shader_name;
>const char *stage;
>/* Work back from the sorted pointers times to a time to print. */
>int i = sorted[s] - scaled;
> - struct gl_shader_program *prog =
> brw->shader_time.shader_programs[i];
>
>if (scaled[i] == 0)
> continue;
>
> - int shader_num = 0;
> - if (prog) {
> - shader_num = prog->Name;
> -
> - if (prog->Label) {
> -shader_name = prog->Label;
> - } else if (shader_num == 0) {
> -shader_name = "ff";
> - } else {
> -shader_name = "glsl";
> - }
> - } else if (brw->shader_time.programs[i]) {
> - shader_num = brw->shader_time.programs[i]->Id;
> - if (shader_num == 0) {
> -shader_name = "ff";
> - } else {
> -shader_name = "prog";
> - }
> - } else {
> - shader_name = "other";
> - }
> + int shader_num = brw->shader_time.ids[i];
> + const char *shader_name = brw->shader_time.names[i];
>
>switch (brw->shader_time.types[i]) {
>case ST_VS:
> @@ -543,19 +520,24 @@ brw_get_shader_time_index(struct brw_context *brw,
>struct gl_program *prog,
>enum shader_time_shader_type type)
> {
> - struct gl_context *ctx = &brw->ctx;
> -
> int shader_time_index = brw->shader_time.num_entries++;
> assert(shader_time_index < brw->shader_time.max_entries);
> brw->shader_time.types[shader_time_index] = type;
>
> - _mesa_reference_shader_program(ctx,
> -
> &brw->shader_time.shader_programs[shader_time_index],
> - shader_prog);
> + int id = shader_prog ? shader_prog->Name : prog->Id;
> + const char *name;
> + if (id == 0) {
> + name = "ff";
> + } else if (!shader_prog) {
> + name = "prog";
> + } else if (shader_prog->Label) {
> + name = ralloc_strdup(brw->shader_time.names, shader_prog->Label);
> + } else {
> + name = "gl
Re: [Mesa-dev] [PATCH 1/3] i965: Make shader_time use 0 instead of -1 for "no meaningful ID".
On Wed, Apr 15, 2015 at 2:24 AM, Kenneth Graunke wrote:
>
> 0 is not a valid GLSL shader or ARB program ID. For some reason,
> shader_time used -1 instead...so we had code to detect 0, then override
> it to -1.
>
> We can just delete that.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_program.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c
> b/src/mesa/drivers/dri/i965/brw_program.c
> index 9e27c2a..0ca63de 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -346,7 +346,7 @@ print_shader_time_line(const char *stage, const char
> *name,
> {
> fprintf(stderr, "%-6s%-18s", stage, name);
>
> - if (shader_num != -1)
> + if (shader_num != 0)
>fprintf(stderr, "%4d: ", shader_num);
> else
>fprintf(stderr, ": ");
> @@ -443,7 +443,7 @@ brw_report_shader_time(struct brw_context *brw)
>if (scaled[i] == 0)
> continue;
>
> - int shader_num = -1;
> + int shader_num = 0;
>if (prog) {
> shader_num = prog->Name;
>
> @@ -456,7 +456,6 @@ brw_report_shader_time(struct brw_context *brw)
> (brw->shader_time.types[i] == ST_FS8 ||
>brw->shader_time.types[i] == ST_FS16)) {
> shader_name = "ff";
> -shader_num = -1;
> } else {
> shader_name = "glsl";
> }
> @@ -464,7 +463,6 @@ brw_report_shader_time(struct brw_context *brw)
> shader_num = brw->shader_time.programs[i]->Id;
> if (shader_num == 0) {
> shader_name = "ff";
> -shader_num = -1;
> } else {
> shader_name = "prog";
> }
> @@ -495,10 +493,10 @@ brw_report_shader_time(struct brw_context *brw)
> }
>
> fprintf(stderr, "\n");
> - print_shader_time_line("total", "vs", -1, total_by_type[ST_VS], total);
> - print_shader_time_line("total", "gs", -1, total_by_type[ST_GS], total);
> - print_shader_time_line("total", "fs8", -1, total_by_type[ST_FS8], total);
> - print_shader_time_line("total", "fs16", -1, total_by_type[ST_FS16],
> total);
> + print_shader_time_line("total", "vs", 0, total_by_type[ST_VS], total);
> + print_shader_time_line("total", "gs", 0, total_by_type[ST_GS], total);
> + print_shader_time_line("total", "fs8", 0, total_by_type[ST_FS8], total);
> + print_shader_time_line("total", "fs16", 0, total_by_type[ST_FS16], total);
> }
>
> static void
> --
> 2.3.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
1-2 are Reviewed-by: Anuj Phogat
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon: replace __FUNCTION__ with __func__
On 16.04.2015 19:35, Marius Predut wrote: > Consistently just use C99's __func__ everywhere. > No functional changes. > > Signed-off-by: Marius Predut Acked-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
