For the series:
Reviewed-by: Chris Forbes
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Carl Worth writes:
> Thanks. I'm happy to help here. So I'll plan to release 9.1.5 on July
> 15, (just 1.5 weeks away now).
Well, I was hoping to have my first release be on time, but I didn't
quite make it.
I have assembled a candidate branch for release, and I've pushed it to
the "9.1" branch
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
The change is to correctly handle the value of renderType in GLX context.
In case of the value being incorrect, context creation fails.
---
src/glx/dri2_glx.c | 11 +++
src/glx/dri_glx.c |6 ++
src/glx/drisw_
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
The change is to correctly handle the value of renderType and
drawableType in fbconfig. This part modifies glXInitializeVisualConfigFromTags
to read the parameter value, or detect it if it's not there.
---
src/glx/glxext.c | 35 +
Ben Widawsky writes:
> FWD'd from our internal list now that we have more insight.
> - Forwarded message from Ben Widawsky -
>
> Date: Thu, 11 Jul 2013 10:32:03 -0700
> From: Ben Widawsky
> To: linux-...@linux.intel.com
> Subject: intel_gpu_top broken for HSW. Ideas needed
> Message-ID:
On 07/15/2013 01:41 PM, Ian Romanick wrote:
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
The change is to correctly handle the value of renderType in both
fbconfig and context. Uses of renderType are commented, where needed,
to avoid confusion between the two types. The fact that float configs
can
These were already semi-relaxed, since the storage qualifier rule
already skipped when 420pack was enabled.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index e6b
The GL_ARB_shading_language_420pack extension/GLSL 4.20 split centroid
off into a new category, "auxiliary storage qualifiers," and allow these
to be placed anywhere in the series. So we have to stop recognizing
"centroid in"/"centroid out"/"centroid varying" in the grammar and get
more creative.
Most of ast_type_qualifier is simply a bitfield (represented as a
structure of unsigned:1 bits in a union with an unsigned). However, it
also contains ARB_explicit_attrib_location's location/index fields.
In the past, this has worked by simply returning the layout qualifier's
ast_type_qualifier a
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index e2edacf..f0299fc 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -908,7 +908,7 @@ parame
This is necessary for the parser to be able to accept precision
qualifiers not immediately adjacent to the type, such as "const highp
inout float foo".
Signed-off-by: Kenneth Graunke
---
src/glsl/ast.h | 11 ++-
src/glsl/ast_to_hir.cpp | 34 ++
sr
Currently, we store precision in ast_type_specifier, rather than
ast_type_qualifier. This works because precision is the last qualifier,
and immediately adjacent to the type.
Default precision statements (such as "precision highp float") are
represented as ast_type_specifier objects, with a boole
This makes the complier accept both "const in" and "in const".
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index a4ab5a4..97ed6b1 100644
--- a/src/glsl/glsl_parser
This will make it easy to support both "const in" and "in const", as
required by GLSL 4.20/ARB_shading_language_420pack.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 43 ++-
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/sr
This makes the compiler accept invariant, storage, layout, and
interpolation qualifiers in any order when ARB_shading_language_420pack
is enabled.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_par
"Parameter direction qualifier" is a new term I invented just now; it's
not part of any GLSL specification.
This paves the way handling multiple parameter qualifiers, in any order,
as required by GLSL 4.20/ARB_shading_language_420pack.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser.yy
The GL_ARB_shading_language_420pack extension/GLSL 4.20 allow qualifiers
to be specified in (basically) any order. In order to support this, we
can't hardcode the ordering restrictions in the grammar.
This patch alters the grammar to accept invariant, storage, layout, and
interpolation qualifiers
This makes it easy to check if any storage qualifiers are set.
XXX: I'm not sure if centroid should be in this or not
Signed-off-by: Kenneth Graunke
---
src/glsl/ast.h| 5 +
src/glsl/ast_type.cpp | 12
2 files changed, 17 insertions(+)
diff --git a/src/glsl/ast.h b/sr
"Auxiliary storage qualifiers" is the new term given to "centroid",
"patch", and "sample" by GLSL 4.20/GL_ARB_shading_language_420pack.
Even though we only support "centroid", it's useful to add this now
so that all auxiliary storage qualifiers get handled in the right places
once they're eventual
This makes it easy to check if any layout qualifiers are set.
Signed-off-by: Kenneth Graunke
---
src/glsl/ast.h| 5 +
src/glsl/ast_type.cpp | 18 ++
2 files changed, 23 insertions(+)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index c0350e7..441b389 100644
--- a/sr
Hello!
The GL_ARB_shading_language_420pack allows qualifiers to be specified in
a flexible order, which is nice now that there are so many different
qualifiers. Yet, we still need to support the old language semantics
which enforce a particular ordering as well.
Previously, we handled the orderi
https://bugs.freedesktop.org/show_bug.cgi?id=66931
--- Comment #2 from Tom Stellard ---
(In reply to comment #1)
> Created attachment 82462 [details]
> Addess spaces support for kernel arguments
>
> Use the data from getAddressSpaceMap to determine the correct type of the
> kernel arguments.
Th
We now also need to stop setting the FORCE_ZERO_RTAINDEX bit
in the clip date so render target array values other than zero
can be used.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_clip_state.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_extensions.c |4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 1e762ef..2db7cb4 100644
--- a/src/mesa/drivers/dri/i965/intel
Previously we would always find the 2D sub-surface of interest,
and then program the surface to this location. Now we always
program the 3DSTATE_DEPTH_BUFFER at the start of the surface.
To select the lod/slice, we utilize the lod & minimum array
element fields.
As part of this change, we must rev
This restriction was related to programming the offset fields
of the depth buffer packet. We are now setting these offsets
to 0 now, so this restriction should no longer be required.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 24
1
When performing hiz ops, we must ensure that the region sizes
have an 8 aligned width and 4 aligned height. We can tweak the
size for blorp hiz operations at LOD 0, but for the others we
can't. Therefore, we disable hiz for these miplevels if they
don't meet the size alignment requirements.
Signed
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 3d
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_misc_state.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 14257cc..404d7d2 100644
--- a/src/mesa/drivers/dri/i965/
In layered rendering this will be 0. Otherwise it will be the
selected slice.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp|6 ++
src/mesa/drivers/dri/i965/gen7_misc_state.c |9 +
2 files changed, 15 insertions(+)
diff --git a/src/mesa/drivers
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp|3 +++
src/mesa/drivers/dri/i965/gen7_misc_state.c |3 +++
2 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp|2 ++
src/mesa/drivers/dri/i965/gen7_misc_
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp| 11 +++
src/mesa/drivers/dri/i965/g
In a future pass this will allow us to exit-early from this
routine to disable it for gen >= 7.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_mis
git://people.freedesktop.org/~jljusten/mesa ivb-full-depth-buffer-v1
This series converts DEPTH_BUFFER to use the LOD and
minimum array element fields and always points the
depth, hiz and stencil buffers at the top of the
miptree surface.
This should allows us to support layered rendering,
althou
Hi Brian,
Thank you so much for your time and help along, up to this point, the code make
much more sense to me.However, I have a few more questions here, hope that you
will be able to help me out.
I am wondering
Where the aa_general_rgba_line() and aa_rgba_line() functions defined?When and
whe
On 07/12/2013 06:25 PM, Paul Berry wrote:
When the core profile is active, there is no fixed function fragment
shader functionality. However, we still need to generate a dummy
fragment shader program in case the back-end expects it (e.g. to cover
the case where GL_RASTERIZER_DISCARD is active an
On 07/15/2013 02:14 PM, Chad Versace wrote:
On 07/15/2013 02:05 PM, Ian Romanick wrote:
On 07/15/2013 06:26 AM, Fredrik Höglund wrote:
On Friday 12 July 2013, Chad Versace wrote:
On 07/12/2013 12:25 PM, Fredrik Höglund wrote:
On Friday 12 July 2013, Chad Versace wrote:
On 07/11/2013 10:18 PM
https://bugs.freedesktop.org/show_bug.cgi?id=66558
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Bryan,
I have just pushed a fix for a lockup in MSAA resolve:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=7969b567bd4361b44ead6ed5eb86218769a025be
Feel free to try MSAA again.
Marek
On Fri, Jan 25, 2013 at 9:30 PM, Bryan Quigley wrote:
> When trying glxgears the screen locks up, and S
https://bugs.freedesktop.org/show_bug.cgi?id=59322
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_cb_fbo.c | 8
src/mesa/state_tracker/st_format.c | 7 +++
2 files changed, 15 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracke
On Mon, Jul 15, 2013 at 2:08 PM, Chad Versace
wrote:
> If the user creates a context with
> EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR set,
> must Mesa return a context of *exactly* that version. For example, if the
> user requests
> a 3.0 context with the forward-compatible bit set, is Mesa re
On 07/15/2013 02:05 PM, Ian Romanick wrote:
On 07/15/2013 06:26 AM, Fredrik Höglund wrote:
On Friday 12 July 2013, Chad Versace wrote:
On 07/12/2013 12:25 PM, Fredrik Höglund wrote:
On Friday 12 July 2013, Chad Versace wrote:
On 07/11/2013 10:18 PM, Paul Berry wrote:
There are currently no
If the user creates a context with
EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR set,
must Mesa return a context of *exactly* that version. For example, if the user
requests
a 3.0 context with the forward-compatible bit set, is Mesa required to return a
3.0
context but not allowed to return a 3
On 07/15/2013 06:26 AM, Fredrik Höglund wrote:
On Friday 12 July 2013, Chad Versace wrote:
On 07/12/2013 12:25 PM, Fredrik Höglund wrote:
On Friday 12 July 2013, Chad Versace wrote:
On 07/11/2013 10:18 PM, Paul Berry wrote:
Another possibility that Chad suggested when I was talking to him thi
Paul Berry writes:
> NOTE: This is a candidate for the stable branches.
>
> Cc: mesa-sta...@lists.freedesktop.org
Thanks, Paul.
This is merged on the stable branch now.
-Carl
pgperrTaouzDR.pgp
Description: PGP signature
___
mesa-dev mailing list
mes
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
The change allows to store RENDER_TYPE value in GLX context
when indirect rendering is in use.
---
src/glx/create_context.c |4 +++-
src/glx/glxclient.h |7 +++
src/glx/glxcmds.c|1 -
src/glx/indirect_glx.c | 23 +
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
This patch sets the correct values of renderType and drawableType
in glXCreateContext and init_fbconfig_for_chooser routines.
---
src/glx/glxcmds.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
The change is to correctly handle the value of renderType in both
fbconfig and context. Uses of renderType are commented, where needed,
to avoid confusion between the two types. The fact that float configs
can be only used for pbuffers is correctly addres
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
From: Tomasz Lis
The patch marks __DRI_ATTRIB_FLOAT_MODE as deprecated and introduces
nrw flags to __DRI_ATTRIB_RENDER_TYPE which are to define float modes.
Both signed float (fbconfig_float) and unsigned (packed_float) is
introduced as a flag. The old
On 07/15/2013 07:28 AM, Tomasz Lis wrote:
From: Tomasz Lis
The patch defines fbconfig_float in tables of extensions and enables
reporting the extension availability.
Since this patch enables the functionality, it should come after the
patch that implements the functionality.
Signed-off-by
https://bugs.freedesktop.org/show_bug.cgi?id=66931
--- Comment #1 from Jonathan Charest ---
Created attachment 82462
--> https://bugs.freedesktop.org/attachment.cgi?id=82462&action=edit
Addess spaces support for kernel arguments
Use the data from getAddressSpaceMap to determine the correct typ
https://bugs.freedesktop.org/show_bug.cgi?id=66558
--- Comment #9 from Björn Beutel ---
Marek, your patch solves the problem for me. Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@l
https://bugs.freedesktop.org/show_bug.cgi?id=66833
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Brian Paul writes:
>> Meanwhile, what's the correct process for updating the website itself?
>
> I upload the files to the mesa directory via my SF account.
...
>> Do I have permission to do those steps? (I'm quite certain I don't'
>> even have a sourceforge account.)
>
> You'd need a SF account a
Kenneth Graunke writes:
> There are two kinds of bug fixes:
> 1. Patches that make valid programs work
> 2. Patches that disallow invalid programs
>
> This is in category 2 - it won't fix any applications, but runs a risk
> of breaking working programs. We often avoid backporting these.
Excelle
https://bugs.freedesktop.org/show_bug.cgi?id=66931
Priority: medium
Bug ID: 66931
Assignee: mesa-dev@lists.freedesktop.org
Summary: Can't specify local buffer size using clSetKernelArg
Severity: normal
Classification: Unclassified
From: Kyle McMartin
MCJIT is the only supported LLVM JIT on AArch64 and ARM (the regular
JIT has bit-rotted badly on ARM and doesn't exist on AArch64.)
Signed-off-by: Kyle McMartin
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -49,7 +49,
On 07/12/2013 06:19 PM, Carl Worth wrote:
Brian Paul writes:
Carl, it would be good if you could put all the above info in Mesa
docs/. The devinfo.html page mentions the "This is a candidate for the
stable branches" convention, etc. The docs/lists.html file describes
all the mailing lists. A
From: Tomasz Lis
The patch marks __DRI_ATTRIB_FLOAT_MODE as deprecated and introduces
nrw flags to __DRI_ATTRIB_RENDER_TYPE which are to define float modes.
Both signed float (fbconfig_float) and unsigned (packed_float) is
introduced as a flag. The old attribute should be set for both float
modes
From: Tomasz Lis
The patch defines fbconfig_float in tables of extensions and enables
reporting the extension availability.
Signed-off-by: Tomasz Lis
---
src/glx/glxextensions.c |4
src/glx/glxextensions.h |6 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/sr
The change is to correctly handle the value of renderType in GLX context.
In case of the value being incorrect, context creation fails.
---
src/glx/dri2_glx.c | 11 +++
src/glx/dri_glx.c |6 ++
src/glx/drisw_glx.c| 12
src/glx/g
This patch sets the correct values of renderType and drawableType
in glXCreateContext and init_fbconfig_for_chooser routines.
---
src/glx/glxcmds.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 5
The change allows to store RENDER_TYPE value in GLX context
when indirect rendering is in use.
---
src/glx/create_context.c |4 +++-
src/glx/glxclient.h |7 +++
src/glx/glxcmds.c|1 -
src/glx/indirect_glx.c | 23 ++-
4 files changed, 28 insertio
This change makes sure that context creation routines are provided
with the value of RENDER_TYPE retrieved from GLX attribs.
---
src/glx/dri2_glx.c |3 ++-
src/glx/dri_common.c |8
src/glx/dri_common.h |2 +-
src/glx/drisw_glx.c |2 +-
4 files changed, 8 insertions(+),
The change is to correctly handle the value of renderType and
drawableType in fbconfig. This part modifies glXInitializeVisualConfigFromTags
to read the parameter value, or detect it if it's not there.
---
src/glx/glxext.c | 35 +++
src/mesa/drivers/
The change is to correctly handle the value of renderType in both
fbconfig and context. Uses of renderType are commented, where needed,
to avoid confusion between the two types. The fact that float configs
can be only used for pbuffers is correctly addressed.
---
src/glx/dri2_glx.c |7 +++
On 07/14/2013 09:34 PM, Andy Li wrote:
> Hi,
>
> I have some questions on the OSMesa code.
> As you suggested, I have continue looking into the swrast code.
> However, I have trouble figuring out how the code works exactly.
> Now I am now only focusing on the functions which draw lines.
> As I loo
On 07/14/2013 11:46 PM, Zhigang Gong wrote:
Hi Kristian,
The OpenCL spec has one extension to support interoperation between OpenGL and
OpenCL.
The key requirement for this extension is to export an OpenGL resource
(texture/buffer object/render buffer)'s internal attributes to the OpenCL's
dri
https://bugs.freedesktop.org/show_bug.cgi?id=66558
--- Comment #8 from Marek Olšák ---
Created attachment 82446
--> https://bugs.freedesktop.org/attachment.cgi?id=82446&action=edit
possible fix
Please try this patch.
--
You are receiving this mail because:
You are the assignee for the bug.
_
On Monday 15 July 2013, Kenneth Graunke wrote:
> Fixes Piglit's ARB_vertex_attrib_bgra/api-errors test.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/main/varray.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
> index
On Friday 12 July 2013, Chad Versace wrote:
> On 07/12/2013 12:25 PM, Fredrik Höglund wrote:
> > On Friday 12 July 2013, Chad Versace wrote:
> >> On 07/11/2013 10:18 PM, Paul Berry wrote:
> >>> Another possibility that Chad suggested when I was talking to him this
> >>> afternoon is to just just re
On 10/07/2013 3:20 PM, Andy Li wrote:
Hello everyone,
I have some questions regarding to OSMesa.
I am currently working on a project which I have to use Mesa on an
embedded system.
My current goal is to port the base functions over to the embedded
system, so that I can draw a line on a pr
+ for (i=0; i < c->vue_map.num_slots; i++) {
+ if (c->key.interpolation_mode[i] == INTERP_QUALIFIER_FLAT) {
+ printf("flatshaded: %d @ %d\n", i,
+ brw_vue_slot_to_offset(i));
Oops, that wasn't supposed to still be in there!
_
Does indeed fix 65236 -- will put the bugzilla reference in the commit.
-- Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
75 matches
Mail list logo
