On 15 June 2012 14:44, Chad Versace wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/15/2012 11:12 AM, Paul Berry wrote:
> > Due to hardware limitations, MSAA is unsupported on Gen6 for formats
> > containing >64 bits of data per pixel. From the Sandy Bridge PRM,
> > vol4 part1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I want to cherry-pick a short series of 3 to 8.0, but want to check others if
they suspect any problems with the series. If no one responds by Monday morning,
I'll cherry-pick it then.
You can view the series at
http://cgit.freedesktop.org/~chadve
---
src/gallium/docs/source/screen.rst |3 ++-
src/gallium/drivers/i915/i915_screen.c |1 +
src/gallium/drivers/nv30/nv30_screen.c |1 +
src/gallium/drivers/nv50/nv50_screen.c |1 +
src/gallium/drivers/nvc0/nvc0_screen.c |1 +
src/gallium/drive
---
docs/GL3.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 17136de..89b46c0 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -119,7 +119,7 @@ GL_ARB_compressed_texture_pixel_storage not
started
GL_ARB_shader_atomic_cou
---
src/mapi/glapi/gen/ARB_base_instance.xml | 40 +++
src/mapi/glapi/gen/Makefile |1 +
src/mapi/glapi/gen/gl_API.xml|3 +-
src/mesa/main/dd.h | 10 +++
src/mesa/main/dlist.c| 45
src/mesa/main/e
---
src/mesa/state_tracker/st_draw.c |1 +
src/mesa/state_tracker/st_extensions.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index db8caa5..5084912 100644
--- a/src/mesa/state_tracker/st_dra
This patch series adds support for ARB_base_instance in core mesa
and the mesa state tracker.
According to the ARB_draw_instanced spec it's not legal to call
the DrawInstanced entry points during display list compilation,
but the ARB_base_instance spec doesn't say anything about this.
I made the n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/15/2012 11:12 AM, Paul Berry wrote:
> Due to hardware limitations, MSAA is unsupported on Gen6 for formats
> containing >64 bits of data per pixel. From the Sandy Bridge PRM,
> vol4 part1, p72 ("Surface Format"):
>
> If Number of Multisampl
From: Jerome Glisse
z or stencil texture should not be created with the z/stencil
flags for surface creation as they are intended to be bound
as texture.
v2: remove broken code
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/r600_texture.c | 32 --
1 fi
On 06/15/2012 10:07 AM, Marek Olšák wrote:
This allows drivers not to do any allocation in AllocStorage if the storage
cannot be allocated because of an unsupported internalformat + samples combo.
The little ugliness is that AllocStorage is expected to return TRUE in this
case.
Looks good to m
On 06/15/2012 12:44 PM, Kristian Høgsberg wrote:
This lets us select the front buffer for reading under GLES2.
For the series:
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman
On Fri, Jun 15, 2012 at 2:43 PM, Kristian Høgsberg wrote:
> On Fri, Jun 15, 2012 at 4:31 PM, Brian Paul wrote:
>> On Fri, Jun 15, 2012 at 1:44 PM, Kristian Høgsberg
>> wrote:
>>> This lets us select the front buffer for reading under GLES2.
>>> ---
>>> src/mapi/glapi/gen/es_EXT.xml | 7 +++
$CLANG_RESOURCE_DIR is the directory that contains all resources
needed by clang to compile programs. When clover uses clang to
compile kernels it needs to specify a resource dir, so that clang
can find its internal headers (e.g. stddef.h).
clang defines $CLANG_RESOURCE_DIR as $CLANG_LIBDIR/clang
On Fri, Jun 15, 2012 at 4:31 PM, Brian Paul wrote:
> On Fri, Jun 15, 2012 at 1:44 PM, Kristian Høgsberg wrote:
>> This lets us select the front buffer for reading under GLES2.
>> ---
>> src/mapi/glapi/gen/es_EXT.xml | 7 +++
>> src/mapi/glapi/gen/gles_api.py | 2 ++
>> src/mesa/main/A
On Fri, Jun 15, 2012 at 1:44 PM, Kristian Høgsberg wrote:
> This extra condition checks the API not the version of the API, so rename
> to reflect that.
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.free
On Fri, Jun 15, 2012 at 1:44 PM, Kristian Høgsberg wrote:
> This lets us select the front buffer for reading under GLES2.
> ---
> src/mapi/glapi/gen/es_EXT.xml | 7 +++
> src/mapi/glapi/gen/gles_api.py | 2 ++
> src/mesa/main/APIspec.xml | 13 +
> src/mesa/main/exten
On Fri, Jun 15, 2012 at 11:07 AM, Marek Olšák wrote:
> This allows drivers not to do any allocation in AllocStorage if the storage
> cannot be allocated because of an unsupported internalformat + samples combo.
>
> The little ugliness is that AllocStorage is expected to return TRUE in this
> case.
This lets us select the front buffer for reading under GLES2.
---
src/mapi/glapi/gen/es_EXT.xml |7 +++
src/mapi/glapi/gen/gles_api.py |2 ++
src/mesa/main/APIspec.xml | 13 +
src/mesa/main/extensions.c |1 +
src/mesa/main/get.c| 20 +++
This extra condition checks the API not the version of the API, so rename
to reflect that.
---
src/mesa/main/get.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 55dc205..a8e1d86 100644
--- a/src/mesa/main/get.c
+++
On Fri, Jun 15, 2012 at 8:40 PM, Brian Paul wrote:
> On Fri, Jun 15, 2012 at 12:29 PM, Marek Olšák wrote:
>> Hi Jerome,
>>
>> Your patch somehow fixes all regressions, but it's not correct. Please
>> see below.
>>
>> On Fri, Jun 15, 2012 at 5:25 PM, wrote:
>>> From: Jerome Glisse
>>>
>>> z or
On Thu, May 3, 2012 at 11:38 PM, Ian Romanick wrote:
> To keep in the habit of doing regular releases, I'd like to propose the
> following set of release dates. We had previously discussed doing stable
> releases monthly and feature releases every six months. This set of dates
> basically reflec
On Fri, Jun 15, 2012 at 12:29 PM, Marek Olšák wrote:
> Hi Jerome,
>
> Your patch somehow fixes all regressions, but it's not correct. Please
> see below.
>
> On Fri, Jun 15, 2012 at 5:25 PM, wrote:
>> From: Jerome Glisse
>>
>> z or stencil texture should not be created with the z/stencil
>> fla
Hi Jerome,
Your patch somehow fixes all regressions, but it's not correct. Please
see below.
On Fri, Jun 15, 2012 at 5:25 PM, wrote:
> From: Jerome Glisse
>
> z or stencil texture should not be created with the z/stencil
> flags for surface creation as they are intended to be bound
> as textur
Due to hardware limitations, MSAA is unsupported on Gen6 for formats
containing >64 bits of data per pixel. From the Sandy Bridge PRM,
vol4 part1, p72 ("Surface Format"):
If Number of Multisamples is set to a value other than
MULTISAMPLECOUNT_1, this field cannot be set to the following
Fixes gles2conform GL.equal.equal_bvec2_frag.
This fixes brw_fs_visitor's translation of ir_unop_f2b. It used CMP to
convert the float to one of 0 or ~0. However, the convention in the
compiler is that true is represented by 1, not ~0. This patch adds an AND
to convert ~0 to 1.
By inspection, a
https://bugs.freedesktop.org/show_bug.cgi?id=50604
--- Comment #5 from nobled 2012-06-15 10:25:12 PDT ---
(In reply to comment #4)
> Sadly, the naive solution of changing those references to be relative to
> $(top_builddir) rather than $(srcdir) runs into problems in src/mesa/Makefile;
> possibly
---
src/mesa/state_tracker/st_cb_fbo.c | 168
1 file changed, 93 insertions(+), 75 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 953295c..0126999 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/
---
src/mesa/state_tracker/st_cb_fbo.c | 34 +++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 88c6fa2..3d77718 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src
instead of failing to allocate a renderbuffer.
This also fixes piglit/get-renderbuffer-internalformat with non-renderable
formats.
---
src/mesa/state_tracker/st_cb_fbo.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src
This allows drivers not to do any allocation in AllocStorage if the storage
cannot be allocated because of an unsupported internalformat + samples combo.
The little ugliness is that AllocStorage is expected to return TRUE in this
case.
---
src/mesa/main/fbobject.c | 11 ++-
1 file chang
From: Jerome Glisse
z or stencil texture should not be created with the z/stencil
flags for surface creation as they are intended to be bound
as texture.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/r600_texture.c | 34 +-
1 files changed, 19 insertio
On Fri, Jun 15, 2012 at 02:15:34PM +0100, Miguel Lopes Santos Ramos wrote:
> Hi all,
>
> I'm trying to learn to program radeons in assembly in Linux and
> already got help once in this mailing list.
>
> I'm programming in C++ using the kernel DRM ioctls directly because
> libdrm appears to be a t
On Fri, Jun 15, 2012 at 8:23 AM, Marek Olšák wrote:
> On Fri, Jun 15, 2012 at 4:07 PM, Brian Paul wrote:
>>
>> I don't think this last bit of code will be reached for non-texture
>> attachments (which are allocated with RenderbufferStorage()). At the
>> beginning of st_validate_attachment() we c
On Fri, Jun 15, 2012 at 4:07 PM, Brian Paul wrote:
>
> I don't think this last bit of code will be reached for non-texture
> attachments (which are allocated with RenderbufferStorage()). At the
> beginning of st_validate_attachment() we check if the attachment type
> is not a texture and return.
On Thu, Jun 14, 2012 at 7:11 PM, Marek Olšák wrote:
> instead of failing to allocate a renderbuffer. This also improves allocation
> of MSAA renderbuffers (untested).
>
> This also fixes piglit/get-renderbuffer-internalformat with non-renderable
> formats.
> ---
> src/mesa/state_tracker/st_cb_fbo
On Thu, Jun 14, 2012 at 9:16 PM, Marek Olšák wrote:
> This fixes piglit/getteximage-formats on r600g.
>
> NOTE: This is a candidate for stable branches.
> ---
> src/mesa/state_tracker/st_cb_texture.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.
On Fri, Jun 15, 2012 at 3:15 PM, Miguel Lopes Santos Ramos
wrote:
> Hi all,
>
> I'm trying to learn to program radeons in assembly in Linux and
> already got help once in this mailing list.
>
> I'm programming in C++ using the kernel DRM ioctls directly because
> libdrm appears to be a thin wrappe
Hi all,
I'm trying to learn to program radeons in assembly in Linux and
already got help once in this mailing list.
I'm programming in C++ using the kernel DRM ioctls directly because
libdrm appears to be a thin wrapper around these (for my purpose,
which is using the GPU for computing), but in d
38 matches
Mail list logo
