Re: [Mesa-dev] llvmpipe support for ARM?
On Wed, 15 Apr 2015 19:02:50 +0300 Marko Moberg marko.s.mob...@gmail.com wrote: Thanks for the replies. I tried to upgrade LLVM from 3.3 to 3.4 after I sent the e-mail but ended up having an internal compiler error from gcc linaro toolchain compiler. Nice. I could try a more up-to-date version of Mesa to see if it helps. Although I have learned that I can not take the most up-to-date version since something has gotten broken related to SW rendering/wayland/egl. Hi, for the record, I've been talking with Marko, and he cannot really upgrade Mesa to the very latest because of https://bugs.freedesktop.org/show_bug.cgi?id=86701 which means you cannot have Mesa software rendering on Wayland. IIRC, his target system is without X11. Thanks, pq ___ 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 lem...@gmail.com ---
(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 tapani.pa...@intel.com
--
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 José Fonseca jfons...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from José Fonseca jfons...@vmware.com --- 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
[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 v...@freedesktop.org --- (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 Vinson Lee v...@freedesktop.org changed: What|Removed |Added Keywords||bisected CC||lem...@gmail.com, ||martin.pe...@free.fr --- Comment #1 from Vinson Lee v...@freedesktop.org --- 161f57f6103802de55d792bcc6a4370afa5c5173 is the first bad commit commit 161f57f6103802de55d792bcc6a4370afa5c5173 Author: Tapani Pälli tapani.pa...@intel.com 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 tapani.pa...@intel.com Reviewed-by: Martin Peres martin.pe...@linux.intel.org :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 lem...@gmail.com --- 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 lem...@gmail.com --- Created attachment 115113 -- https://bugs.freedesktop.org/attachment.cgi?id=115113action=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
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.htmld=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3Ms=xQYf3XSyViAxeZGMVr3QiQgsl228e0lTG7L_Kli3ctMe= Extension specification: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opengl.org_registry_specs_ARB_program-5Finterface-5Fquery.txtd=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3Ms=exUys8YSrdaLlgkKQs9pcqsRLY7AtjRRk7FyGW4kvnoe= Git branch with all the patches: https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Etpalli_mesa_log_-3Fh-3Dpiqd=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3Ms=GdA-NzXKst7bl3fFT5Lbj622qrZoNeQs4dLu41WJ7zwe= 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(-) create mode 100644
[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
--- Comment #5 from Vinson Lee v...@freedesktop.org ---
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
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.htmld=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3Ms=xQYf3XSyViAxeZGMVr3QiQgsl228e0lTG7L_Kli3ctMe= Extension specification: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opengl.org_registry_specs_ARB_program-5Finterface-5Fquery.txtd=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3Ms=exUys8YSrdaLlgkKQs9pcqsRLY7AtjRRk7FyGW4kvnoe= Git branch with all the patches: https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Etpalli_mesa_log_-3Fh-3Dpiqd=AwIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=3w0-sDFs-LVaBLQqNorjQ5rE4obDOogdaHYG8Iosa3Ms=GdA-NzXKst7bl3fFT5Lbj622qrZoNeQs4dLu41WJ7zwe= 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
Re: [Mesa-dev] [PATCH] main: remove __FUNCTION__ defined because it is obsolete
Hi Marius, On 16 April 2015 at 11:36, Marius Predut marius.pre...@intel.com 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 marius.pre...@intel.com Reviewed-by: Emil Velikov emil.l.veli...@gmail.com Thanks Emil ___ 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 imir...@alum.mit.edu wrote: On Wed, Mar 25, 2015 at 8:31 PM, Matt Turner matts...@gmail.com wrote: On Wed, Mar 25, 2015 at 4:15 PM, Jan Vesely jan.ves...@rutgers.edu wrote: On Wed, 2015-03-25 at 18:55 -0400, Ilia Mirkin wrote: On Wed, Mar 25, 2015 at 6:51 PM, Jan Vesely jan.ves...@rutgers.edu 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 imir...@alum.mit.edu Signed-off-by: Vinson Lee v...@freedesktop.org --- 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
[Mesa-dev] [PATCH] radeon: replace __FUNCTION__ with __func__
Consistently just use C99's __func__ everywhere.
No functional changes.
Signed-off-by: Marius Predut marius.pre...@intel.com
---
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
[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 marius.pre...@intel.com
---
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 chad.vers...@intel.com wrote:
On Wed 15 Apr 2015, Emil Velikov wrote:
On 14 April 2015 at 17:22, Ian Romanick i...@freedesktop.org wrote:
On 04/14/2015 08:36 AM, Emil Velikov wrote:
On 14 April 2015 at 13:52, Jose Fonseca jfons...@vmware.com wrote:
On 13/04/15 22:59, Ian Romanick wrote:
On 04/10/2015 03:36 PM, Jose Fonseca wrote:
From: José Fonseca jfons...@vmware.com
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 i...@freedesktop.org wrote: On 04/15/2015 10:56 AM, Emil Velikov wrote: On 15 April 2015 at 18:33, Matt Turner matts...@gmail.com wrote: On Wed, Apr 15, 2015 at 7:08 AM, Emil Velikov emil.l.veli...@gmail.com 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 robcl...@freedesktop.org Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- 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] 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 i...@freedesktop.org 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 ian.d.roman...@intel.com
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 mesa-sta...@lists.freedesktop.org
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
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 k...@bitplanet.net
---
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 fred...@kde.org
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 26/38] main: Add entry points for InvalidateNamedFramebuffer[Sub]Data.
This patch is:
Reviewed-by: Fredrik Höglund fred...@kde.org
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 @@
param name=layer type=GLint /
/function
+ function name=InvalidateNamedFramebufferData offset=assign
+ param name=framebuffer type=GLuint /
+ param name=numAttachments type=GLsizei /
+ param name=attachments type=const GLenum * /
+ /function
+
+ function name=InvalidateNamedFramebufferSubData offset=assign
+ param name=framebuffer type=GLuint /
+ param name=numAttachments type=GLsizei /
+ param name=attachments type=const GLenum * /
+ param name=x type=GLint /
+ param name=y type=GLint /
+ param name=width type=GLsizei /
+ param name=height type=GLsizei /
+ /function
+
function name=BlitNamedFramebuffer offset=assign
param name=readFramebuffer type=GLuint /
param name=drawFramebuffer type=GLuint /
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 x,
y,
+* width, height equal to 0, 0, MAX_VIEWPORT_DIMS[0],
+* MAX_VIEWPORT_DIMS[1] 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
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 @@
param name=layer type=GLint /
/function
+ function name=NamedFramebufferDrawBuffer offset=assign
+ param name=framebuffer type=GLuint /
+ param name=mode type=GLenum /
The parameter name should be buf, not mode.
With that fixed, this patch is:
Reviewed-by: Fredrik Höglund fred...@kde.org
+ /function
+
function name=InvalidateNamedFramebufferData offset=assign
param name=framebuffer type=GLuint /
param name=numAttachments type=GLsizei /
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/main/context.c b/src/mesa/main/context.c
index b285d51..8ea9e33 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1581,7 +1581,7 @@
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 @@
param name=mode type=GLenum /
/function
+ function name=NamedFramebufferReadBuffer offset=assign
+ param name=framebuffer type=GLuint /
+ param name=mode type=GLenum /
The parameter name should be src, not mode.
With that fixed, this patch is:
Reviewed-by: Fredrik Höglund fred...@kde.org
+ /function
+
function name=InvalidateNamedFramebufferData offset=assign
param name=framebuffer type=GLuint /
param name=numAttachments type=GLsizei /
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 24/38] main: Refactor invalidate_framebuffer_storage.
This patch is:
Reviewed-by: Fredrik Höglund fred...@kde.org
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,
* width, height equal to 0, 0, MAX_VIEWPORT_DIMS[0],
* MAX_VIEWPORT_DIMS[1] 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 fred...@kde.org
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 29/38] main: Fake entry point for glClearNamedFramebufferfv.
This patch is:
Reviewed-by: Fredrik Höglund fred...@kde.org
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 @@
param name=value type=const GLuint * /
/function
+ function name=ClearNamedFramebufferfv offset=assign
+ param name=framebuffer type=GLuint /
+ param name=buffer type=GLenum /
+ param name=drawbuffer type=GLint /
+ param name=value type=const GLfloat * /
+ /function
+
function name=BlitNamedFramebuffer offset=assign
param name=readFramebuffer type=GLuint /
param name=drawFramebuffer type=GLuint /
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 31/38] main: Add stubs for [Get]NamedFramebufferParameteri[v].
This patch is:
Reviewed-by: Fredrik Höglund fred...@kde.org
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 @@
param name=renderbuffer type=GLuint /
/function
+ function name=NamedFramebufferParameteri offset=assign
+ param name=framebuffer type=GLuint /
+ param name=pname type=GLenum /
+ param name=param type=GLint /
+ /function
+
function name=NamedFramebufferTexture offset=assign
param name=framebuffer type=GLuint /
param name=attachment type=GLenum /
@@ -205,6 +211,12 @@
param name=target type=GLenum /
/function
+ function name=GetNamedFramebufferParameteriv offset=assign
+ param name=framebuffer type=GLuint /
+ param name=pname type=GLenum /
+ param name=param type=GLint * /
+ /function
+
function name=GetNamedFramebufferAttachmentParameteriv offset=assign
param name=framebuffer type=GLuint /
param name=attachment type=GLenum /
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,
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 fred...@kde.org
/* 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-_ColorDrawBufferIndexes[buf] = -1;
}
}
@@ -566,7 +565,7 @@ _mesa_drawbuffers(struct gl_context *ctx, GLuint n, const
GLenum
Re: [Mesa-dev] [PATCH 27/38] main: Fake entry point for glClearNamedFramebufferiv.
This patch is:
Reviewed-by: Fredrik Höglund fred...@kde.org
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 @@
param name=height type=GLsizei /
/function
+ function name=ClearNamedFramebufferiv offset=assign
+ param name=framebuffer type=GLuint /
+ param name=buffer type=GLenum /
+ param name=drawbuffer type=GLint /
+ param name=value type=const GLint * /
+ /function
+
function name=BlitNamedFramebuffer offset=assign
param name=readFramebuffer type=GLuint /
param name=drawFramebuffer type=GLuint /
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 fred...@kde.org
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 @@
param name=value type=const GLint * /
/function
+ function name=ClearNamedFramebufferuiv offset=assign
+ param name=framebuffer type=GLuint /
+ param name=buffer type=GLenum /
+ param name=drawbuffer type=GLint /
+ param name=value type=const GLuint * /
+ /function
+
function name=BlitNamedFramebuffer offset=assign
param name=readFramebuffer type=GLuint /
param name=drawFramebuffer type=GLuint /
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 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 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,
-glDrawBuffersARB(unsupported buffer));
+%s(unsupported buffer %s),
+caller, _mesa_lookup_enum_by_nr(buffers[output]));
[Mesa-dev] [PATCH] i965: Add marketing names for CHV
From: Ville Syrjälä ville.syrj...@linux.intel.com All CHV devices will be branded as Intel(r) HD Graphics. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- 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 38/38] main: Add entry point for NamedFramebufferDrawBuffers.
This patch is:
Reviewed-by: Fredrik Höglund fred...@kde.org
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 @@
param name=mode type=GLenum /
/function
+ function name=NamedFramebufferDrawBuffers offset=assign
+ param name=framebuffer type=GLuint /
+ param name=n type=GLsizei /
+ param name=bufs type=const GLenum * /
+ /function
+
function name=NamedFramebufferReadBuffer offset=assign
param name=framebuffer type=GLuint /
param name=mode type=GLenum /
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] gallium/ttn: fix TXF
From: Rob Clark robcl...@freedesktop.org
There is an level param stashed away in the .w component of the first
src.
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
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] [PATCH 0/3] Hash-table and hash-set, V4
Eric Anholt e...@anholt.net writes: Jason Ekstrand ja...@jlekstrand.net writes: On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland thomashellan...@gmail.com 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 jason.ekstr...@intel.com 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
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 k...@bitplanet.net wrote:
On Wed, Apr 8, 2015 at 11:37 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hi all,
Can we get a pair of eyes on this patch please ?
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
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 boyan.j.d...@gmail.com 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 boyan.j.d...@gmail.com
---
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 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
[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
Re: [Mesa-dev] [PATCH 2/3] mesa: add check for NV_texture_barrier in _mesa_TextureBarrierNV()
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
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 bri...@vmware.com 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 e...@anholt.net: Eric Anholt e...@anholt.net writes: Jason Ekstrand ja...@jlekstrand.net writes: On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland thomashellan...@gmail.com 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 jason.ekstr...@intel.com 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 3/3] i965: Make shader_time store names/ids instead of referencing shaders.
On Wed, Apr 15, 2015 at 2:24 AM, Kenneth Graunke kenn...@whitecape.org
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 kenn...@whitecape.org
---
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 = glsl;
+ }
- _mesa_reference_program(ctx,
- brw-shader_time.programs[shader_time_index],
-
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 kenn...@whitecape.org 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 kenn...@whitecape.org
---
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 anuj.pho...@gmail.com
___
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 robdcl...@gmail.com writes: From: Rob Clark robcl...@freedesktop.org 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 e...@anholt.net 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] 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ä ville.syrj...@linux.intel.com All CHV devices will be branded as Intel(r) HD Graphics. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- 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 kenn...@whitecape.org 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ä ville.syrj...@linux.intel.com All CHV devices will be branded as Intel(r) HD Graphics. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- 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 kenn...@whitecape.org Thanks. -- Ville Syrjälä Intel OTC ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
