Am Dienstag, 20. November 2012, 06:41:22 schrieb Dave Airlie:
$ llvm-config --cxxflags
-I/usr/include -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fPIC
-fvisibility-inlines-hidden -O2 -g -D_GNU_SOURCE -Wall -W
Until we have proper 'make dist' this is an improvement of the current
situation, because each time some old Makefiles got converted to automake
we had to update the tarballs target.
NOTE: This is a candidate for the 9.0 branch.
Cc: Eric Anholt e...@anholt.net
Cc: Matt Turner matts...@gmail.com
Override the cross_compiling and ac_tool_prefix variables by reassigning
to them instead of redefining the macros. Redefining them will actually
cause the variable names to be replaced instead of their content.
Furthermore push the definition of CPPFLAGS before running the checks
for the build
Kenneth Graunke kenn...@whitecape.org writes:
Fixes es3conform's explicit_attrib_location_integer_constants.
Reviewed-by: Eric Anholt e...@anholt.net
pgpc21sF3cuEL.pgp
Description: PGP signature
___
mesa-dev mailing list
On Tue, Nov 20, 2012 at 4:36 AM, Andreas Boll
andreas.boll@gmail.com wrote:
Until we have proper 'make dist' this is an improvement of the current
situation, because each time some old Makefiles got converted to automake
we had to update the tarballs target.
NOTE: This is a candidate for
https://bugs.freedesktop.org/show_bug.cgi?id=57241
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Hardware|Other |All
The series is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 11/19/2012 10:21 PM, Kenneth Graunke wrote:
---
src/mesa/drivers/common/meta.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
These should probably go to the gles3 branch, not master.
On 11/19/2012 10:37 PM, Kenneth Graunke wrote:
Fixes es3conform's explicit_attrib_location_integer_constants.
From the look of things, this is how it should work on desktop as well.
The grammar says:
layout-qualifier-id
location = integer-constant
and
integer-constant :
On 11/09/2012 02:06 PM, Chad Versace wrote:
For GLES1 and GLES2, brwCreateContext neglected to validate the requested
context version received from the DRI layer. If DRI requested an OpenGL
ES2 context with version 3.9, we provided it one.
Before this fix, the switch statement that validated
List,
I was told to send this to freedesktop.org admins, but as I fully expect
that this will be controversial among some Mesa developers, I thought
that I would write to this list first and check that there is enough
agreement here.
WebGL-enabled browsers have faced security bugs in all drivers
On 14 November 2012 15:38, Dan Nicholson dbn.li...@gmail.com wrote:
This looks pretty good except that I think you need to temporarily add
GLUT_CFLAGS to CFLAGS and GLUT_LIBS to LIBS so that the user specified
prefix works for AC_CHECK*. On the other hand, at least mesa glut has a
pkg-config
The argument --without-glut is transformed to --with-glut=no, which the logic
wasn't handling at all so --without-glut didn't work. Rewrite the logic to
handle the case where the value passed to --with-glut is no.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
configure.ac | 32
On Mon, Nov 19, 2012 at 8:14 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On 11/19/2012 05:01 PM, Jordan Justen wrote:
GLES3 support requires that the version be computed before the
exec table is initialized.
For main exec table initialization (api_exec.c):
* Rename
On 11/20/12 09:29 AM, Benoit Jacob wrote:
Both solutions are poor, and a better solution would be for Mesa's
bugzilla to allow hidden security bugs so we could work there. Given
that security bug discussion can't be open, that is the least bad
solution possible.
For what it's worth, Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=43871
Andreas Boll andreas.boll@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, Nov 20, 2012 at 7:50 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
Override the cross_compiling and ac_tool_prefix variables by reassigning
to them instead of redefining the macros. Redefining them will actually
cause the variable names to be replaced instead of their
Andreas Boll andreas.boll@gmail.com writes:
Until we have proper 'make dist' this is an improvement of the current
situation, because each time some old Makefiles got converted to automake
we had to update the tarballs target.
These probably make more sense in the manifest.txt rule, since
On Mon, Nov 19, 2012 at 10:37 PM, Kenneth Graunke kenn...@whitecape.org wrote:
Fixes es3conform's explicit_attrib_location_integer_constants.
---
src/glsl/glsl_parser.yy | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/glsl/glsl_parser.yy
On Mon, Nov 19, 2012 at 10:21 PM, Kenneth Graunke kenn...@whitecape.org wrote:
---
src/mesa/drivers/common/meta.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
These should probably go to the gles3 branch, not master.
This one's not observed to fix any
On Tue, Nov 20, 2012 at 11:07:03AM -0800, Matt Turner wrote:
On Tue, Nov 20, 2012 at 7:50 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
Override the cross_compiling and ac_tool_prefix variables by reassigning
to them instead of redefining the macros. Redefining them will
Fixes the remaining 4 texture_lod_bias failures in es3conform.
---
src/mesa/main/get.c | 17 +
src/mesa/main/get_hash_params.py |8 +---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index
https://bugs.freedesktop.org/show_bug.cgi?id=56685
--- Comment #13 from Thierry Reding thierry.red...@avionic-design.de ---
(In reply to comment #12)
How could glsl_parser.h exist in both src and build directories?
There could be any number of reasons. The most likely would be if somebody's
We can't support IF statements in 16-wide on these. To get back to 16-wide
for these shaders, we need to support predicate on discard instructions in the
backend IR, which is something we've sort of got on the list to do anyway.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55828
---
---
src/mesa/main/get.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index a4dc972..077cf2d 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -1696,7 +1696,7 @@ _mesa_GetBooleani_v( GLenum pname, GLuint index,
The function was named badly and wasn't in the dispatch table,
making it hard to find.
Fixes transform_feedback2_states and gets a few other transform
feedback tests closer to working in es3conform.
---
src/mapi/glapi/gen/GL3x.xml |2 +-
src/mesa/main/get.c |
On Tue 20 Nov 2012 11:47:52 AM PST, Matt Turner wrote:
Fixes the remaining 4 texture_lod_bias failures in es3conform.
---
src/mesa/main/get.c | 17 +
src/mesa/main/get_hash_params.py |8 +---
2 files changed, 22 insertions(+), 3 deletions(-)
diff
---
src/gallium/drivers/r600/r600_state.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index ab658da..87fe4e7 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++
On 11/20/2012 12:46 PM, Eric Anholt wrote:
We can't support IF statements in 16-wide on these. To get back to 16-wide
for these shaders, we need to support predicate on discard instructions in the
backend IR, which is something we've sort of got on the list to do anyway.
Bugzilla:
On 11/20/2012 01:09 PM, Matt Turner wrote:
---
src/mesa/main/get.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
For both patches:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
On 11/20/2012 11:47 AM, Matt Turner wrote:
Fixes the remaining 4 texture_lod_bias failures in es3conform.
---
src/mesa/main/get.c | 17 +
src/mesa/main/get_hash_params.py |8 +---
2 files changed, 22 insertions(+), 3 deletions(-)
Reviewed-by: Kenneth
On Tue, Nov 20, 2012 at 1:09 PM, Matt Turner matts...@gmail.com wrote:
The function was named badly and wasn't in the dispatch table,
making it hard to find.
Fixes transform_feedback2_states and gets a few other transform
feedback tests closer to working in es3conform.
---
Hi,
http://cgit.freedesktop.org/mesa/mesa/commit/?id=eb44c36df842af010269eda1be77c4aea8ebe736 introduces
a bug with tgsi-to-llvm on R700 cards.
Apparently there is an issue with flushing : a lot of piglit shaders are
reported to fail (I got something like 3000 regressions) however running them
On 11/20/2012 08:57 AM, Burton, Ross wrote:
On 14 November 2012 15:38, Dan Nicholson dbn.li...@gmail.com wrote:
This looks pretty good except that I think you need to temporarily add
GLUT_CFLAGS to CFLAGS and GLUT_LIBS to LIBS so that the user specified
prefix works for AC_CHECK*. On the other
On Tue, Nov 20, 2012 at 3:34 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On 11/20/2012 08:57 AM, Burton, Ross wrote:
On 14 November 2012 15:38, Dan Nicholson dbn.li...@gmail.com wrote:
This looks pretty good except that I think you need to temporarily add
GLUT_CFLAGS to CFLAGS and
https://bugs.freedesktop.org/show_bug.cgi?id=57121
--- Comment #5 from Tomasz Kaźmierczak tome...@wp.eu ---
Hi, I'll try to create a small test program for that if I find some time, but
for now I'm sending an apitrace file.
The meshes get loaded in frame 137 and the bug is visible then (they get
https://bugs.freedesktop.org/show_bug.cgi?id=57121
--- Comment #6 from Tomasz Kaźmierczak tome...@wp.eu ---
Created attachment 70334
-- https://bugs.freedesktop.org/attachment.cgi?id=70334action=edit
apitrace file
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=57121
Tomasz Kaźmierczak tome...@wp.eu changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
You are
---
src/gallium/drivers/r600/r600_llvm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index b3d4e6b..170dac7 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++
On 11/20/2012 12:46 PM, Eric Anholt wrote:
We can't support IF statements in 16-wide on these. To get back to 16-wide
for these shaders, we need to support predicate on discard instructions in the
backend IR, which is something we've sort of got on the list to do anyway.
Bugzilla:
It's not really a flush fix, you're just fixing wrong RESOURCE_ID in shaders.
The best solution would be not to add 2 in LLVM and not to subtract 2
here. Other than that, it looks good.
Marek
On Tue, Nov 20, 2012 at 11:26 PM, Vincent Lejeune v...@ovi.com wrote:
---
Commit 243cf7a applied a similar fix to i965.
For GLES1 and GLES2, i915CreateContext neglected to validate the requested
context version received from the DRI layer. If DRI requested an OpenGL
ES2 context with version 3.9, we provided it one.
Signed-off-by: Chad Versace
Commit 243cf7a applied a similar fix to i965.
For GLES1 and GLES2, i915CreateContext neglected to validate the requested
context version received from the DRI layer. If DRI requested an OpenGL
ES2 context with version 3.9, we provided it one.
v2: Allow GLES2 only if GL_ARB_fragment_shader is
For glGetIntegerv, add support for the following in an OpenGL ES 3.0
context:
GL_MAJOR_VERSION
GL_MINOR_VERSION
GL_NUM_EXTENSIONS
See Table 6.29 of the OpenGL ES 3.0 spec.
Fixes error GL_INVALID_ENUM in piglit egl-create-context-verify-gl-flavor,
testcase for OpenGL ES 3.0.
Fixes error EGL_BAD_ATTRIBUTE in the tests below on Intel Sandybridge:
* piglit egl-create-context-verify-gl-flavor, testcase OpenGL ES 3.0
* gles3conform, revision 19700
The series lives on my es3-bit branch. It adds a new enum, __DRI_API_GLES3,
and does the needed plumbing in the EGL and
Set the GLES3 bit in intel_screen's bitmask of supported DRI API's.
Neither the EGL nor GLX layer uses the bit yet.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 1 +
1 file changed, 1 insertion(+)
diff --git
This enum corresponds to EGL_OPENGL_ES3_BIT_KHR.
Neither the GLX nor EGL layer use the enum yet.
I don't like the GLES bits. I'd prefer that all GLES APIs be exposed
through a single API bit, as is done in GLX_EXT_create_context_es_profile.
But, we need this GLES3 enum in order to do the plumbing
Fixes error EGL_BAD_ATTRIBUTE in the tests below on Intel Sandybridge:
* piglit egl-create-context-verify-gl-flavor, testcase OpenGL ES 3.0
* gles3conform, revision 19700
This plumbing is added in order to comply with the EGL_KHR_create_context
spec. According to the
On Tue, Nov 20, 2012 at 5:13 PM, Chad Versace
chad.vers...@linux.intel.com wrote:
For glGetIntegerv, add support for the following in an OpenGL ES 3.0
context:
GL_MAJOR_VERSION
GL_MINOR_VERSION
GL_NUM_EXTENSIONS
See Table 6.29 of the OpenGL ES 3.0 spec.
Fixes error
On Tue, Nov 20, 2012 at 5:31 PM, Chad Versace
chad.vers...@linux.intel.com wrote:
Fixes error EGL_BAD_ATTRIBUTE in the tests below on Intel Sandybridge:
* piglit egl-create-context-verify-gl-flavor, testcase OpenGL ES 3.0
* gles3conform, revision 19700
This plumbing is added in order
On 11/20/2012 05:31 PM, Chad Versace wrote:
Set the GLES3 bit in intel_screen's bitmask of supported DRI API's.
Neither the EGL nor GLX layer uses the bit yet.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 1 +
1 file changed, 1
On 11/20/2012 05:45 PM, Ian Romanick wrote:
On 11/20/2012 05:31 PM, Chad Versace wrote:
Set the GLES3 bit in intel_screen's bitmask of supported DRI API's.
Neither the EGL nor GLX layer uses the bit yet.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
@@ -737,8 +742,10 @@ dri2_create_context(_EGLDriver *drv, _EGLDisplay *disp,
_EGLConfig *conf,
api = __DRI_API_GLES;
break;
case 2:
+ api = __DRI_API_GLES3;
+ break;
case 3:
- api = __DRI_API_GLES2;
+ api =
Everybody determines this by checking if fp's OutputsWritten field
contains the FRAG_RESULT_DEPTH bit. Rather than having payload setup
check this and set the computes_depth flag, we can just do the check in
the only place that actually used it: emit_fb_writes().
---
Hey all,
Here's a bunch of preliminary refactoring which should help me
implement the Gen8 code generator.
A bit of background: Gen8 uses a different instruction encoding than
Gen4-7 (essentially, a lot of bits got moved around), which means that
I can't use struct brw_instruction. This
Now that we only have the one backend, there's no real point in keeping
this separate. Moving it should allow some future simplifications.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 63 +-
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
This necessitates compiling brw_wm_iz.c as C++.
---
src/mesa/drivers/dri/i965/Makefile.sources | 2 +-
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/brw_wm.h | 3 -
Also, rather than having brw_wm_fs_emit poke at it directly, make it a
parameter to the fs_visitor constructor.
All other changes generated by search and replace (with occasional
whitespace fixup).
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 39 ++
Also change it from a brw_fragment_program to a gl_fragment_program,
since that seems to be what everything wants anyway.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 9 +
src/mesa/drivers/dri/i965/brw_fs.h | 4 +++-
src/mesa/drivers/dri/i965/brw_fs_emit.cpp| 2 +-
We can easily recover it from prog, and this makes it clear that we
aren't passing additional information in.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 5 +++--
3 files changed, 6
All we really need is a memory context and the instruction list; passing
a backend_visitor is just convenient at times.
This will be necessary two patches from now.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 17 ++---
src/mesa/drivers/dri/i965/brw_cfg.h | 4
2 files changed,
We used to steal it out of the brw_compile struct...but fs_visitor
isn't going to have one of those in the future.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_fs.h | 3 ++-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 5 +++--
3 files
The brw_compile structure is closely tied to the Gen4-7 hardware
encoding. However, do_wm_prog is very generic: it just calls out to
get a compiled program and then uploads it.
This isn't ultimately where we want it, but it's a step in the right
direction: it's now closer to the code generator.
Final code generation should never fail. This is a bug, and there
should be no user-triggerable cases where this could occur.
Also, we're not going to have a fail() method in a moment.
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Compiling shaders requires several main steps:
1. Generating FS IR from either GLSL IR or Mesa IR
2. Optimizing the IR
3. Register allocation
4. Generating assembly code
This patch splits out step 4 into a separate class named fs_generator.
There are several reasons for doing so:
The brw_compile structure contains the brw_instruction store and the
brw_eu_emit.c state tracking fields. These are only useful for the
final assembly generation pass; the earlier compilation stages doesn't
need them.
This also means that the code generator for future hardware won't have
access
On 11/20/2012 03:31 PM, Chad Versace wrote:
brwCreateContext unconditionally set the maximum supported OpenGL ES2
context version to 3.0. Instead, we need to predicate it on hardware
capabilities. Set it to 3.0 only if and only if OpenGL 3.0 is supported.
Signed-off-by: Chad Versace
On 11/20/2012 05:13 PM, Chad Versace wrote:
For glGetIntegerv, add support for the following in an OpenGL ES 3.0
context:
GL_MAJOR_VERSION
GL_MINOR_VERSION
GL_NUM_EXTENSIONS
See Table 6.29 of the OpenGL ES 3.0 spec.
Fixes error GL_INVALID_ENUM in piglit
The bug was found by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/mesa/drivers/dri/i915/i915_texstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i915/i915_texstate.c
b/src/mesa/drivers/dri/i915/i915_texstate.c
index
68 matches
Mail list logo
