On Die, 2012-02-28 at 09:08 -0800, Benoit Jacob wrote:
>
> At Mozilla we've been wondering if we could get a good software
> fallback for users who can't get hardware-accelerated WebGL. Mesa
> llvmpipe seems like the best open source OpenGL renderer, right? At
> least, it performed superbly in ou
According to 3DSTATE_MAP_STATE at page of 104 in Bspec
vol3d 3D Instructions:
[DevGDG and DevAlv]: Must be a power of 2 for cube maps
Well, it turned out to be that we need do this for other
platforms as well, like pineview.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=4
NOTE: Th
Signed-off-by: Yuanhan Liu
---
src/mesa/drivers/dri/i915/i915_texstate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_texstate.c
b/src/mesa/drivers/dri/i915/i915_texstate.c
index 9022548..0e500e2 100644
--- a/src/mesa/drivers/dri/i915/i
ping..
comments?
Thanks,
Yuanhan Liu
On Thu, Feb 23, 2012 at 02:19:19PM +0800, Yuanhan Liu wrote:
> The current code would ignore the point size specified by gl_PointSize
> builtin variable in vertex shader on Pineview. This patch servers as
> fixing that.
>
> This patch fixes the followin
Hi Brian,
comments?
Thanks,
Yuanhan Liu
On Thu, Feb 23, 2012 at 02:19:18PM +0800, Yuanhan Liu wrote:
> We may specify the point size in a glsl vertex shader.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46311
> piglit: glsl-vs-point-size
>
> NOTE: This is a candidate for stable re
Ping..
Comments?
Thanks,
Yuanhan Liu
On Mon, Feb 27, 2012 at 03:46:32PM +0800, Yuanhan Liu wrote:
> This patch add the support of gl_PointCoord gl builtin variable for
> platform gen4 and gen5(ILK).
>
> Unlike gen6+, we don't have a hardware support of gl_PointCoord, means
> hardware will n
On 02/28/2012 01:20 PM, Eric Anholt wrote:
Before, we were only counting top-level instructions. But if we have
an assignment of a giant expression tree (such as the ones eventually
generated by glsl-fs-unroll), we were counting the same as an
assignment of a variable deref.
glsl-fs-unroll-expl
After biasing we need to clamp to be sure we don't exceed the number of
levels in the mipmap. This fixes an assertion at svga_sampler_view.c:70
---
src/gallium/drivers/svga/svga_state_tss.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_stat
On 02/28/2012 01:33 PM, Eric Anholt wrote:
---
src/mesa/main/vtxfmt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/vtxfmt.c b/src/mesa/main/vtxfmt.c
index f3cca93..6fb016b 100644
--- a/src/mesa/main/vtxfmt.c
+++ b/src/mesa/main/vtxfmt.c
@@ -41,7 +41,7
On 02/28/2012 02:33 PM, Eric Anholt wrote:
---
src/mesa/main/vtxfmt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/vtxfmt.c b/src/mesa/main/vtxfmt.c
index f3cca93..6fb016b 100644
--- a/src/mesa/main/vtxfmt.c
+++ b/src/mesa/main/vtxfmt.c
@@ -41,7 +41,7
On 02/28/2012 02:39 PM, Eric Anholt wrote:
On Tue, 28 Feb 2012 09:08:39 -0800 (PST), Benoit Jacob
wrote:
Hi List,
At Mozilla we've been wondering if we could get a good software fallback for
users who can't get hardware-accelerated WebGL. Mesa llvmpipe seems like the
best open source OpenGL
On Tue, 28 Feb 2012 09:08:39 -0800 (PST), Benoit Jacob
wrote:
> Hi List,
>
> At Mozilla we've been wondering if we could get a good software fallback for
> users who can't get hardware-accelerated WebGL. Mesa llvmpipe seems like the
> best open source OpenGL renderer, right? At least, it perfo
Fixes piglit GL_ARB_draw_instanced/negative-arrays-first-negative.
---
src/mesa/main/api_validate.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index b10d8cd..4e94f47 100644
--- a/src/mesa/main/api_valida
Fixes piglit GL_ARB_draw_elements_base_vertex/dlist-arb_draw_instanced
---
src/mesa/main/dlist.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 0eefd40..3db7beb 100644
--- a/src/mesa/main/dlist.c
+++ b/
---
src/mesa/main/vtxfmt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/vtxfmt.c b/src/mesa/main/vtxfmt.c
index f3cca93..6fb016b 100644
--- a/src/mesa/main/vtxfmt.c
+++ b/src/mesa/main/vtxfmt.c
@@ -41,7 +41,7 @@
#if FEATURE_beginend
/**
- * Use the pe
When you called them in a display list compile before, you would just
end up calling through NULL.
Fixes piglit GL_ARB_draw_instanced/dlist.
---
src/mesa/main/api_validate.c |6 --
src/mesa/main/dlist.c| 28
2 files changed, 28 insertions(+), 6 delet
Before, we were only counting top-level instructions. But if we have
an assignment of a giant expression tree (such as the ones eventually
generated by glsl-fs-unroll), we were counting the same as an
assignment of a variable deref.
glsl-fs-unroll-explosion now fails in a reasonable amount of tim
https://bugs.freedesktop.org/show_bug.cgi?id=40059
Kenneth Graunke changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
- Original Message -
> From: Dave Airlie
>
> This adds support for all the opcodes needed for native integer
> support with GLSL 1.20 enabled, and some of the ones for GLSL1.30
> support.
>
> I've split them between non-cpu and cpu along the same lines
> Tom's code did for the other ones
- Original Message -
> Hi guys,
>
> So I've gotten llvmpipe GLSL 1.20 support with native integers
> enabled
> to be 0 regressions from non-integers enabled.
>
> The one big problem I've hit is non-native integer llvmpipe uses
> system_values, it takes them in as integers and converts t
https://bugs.freedesktop.org/show_bug.cgi?id=46631
--- Comment #15 from drag...@gmail.com 2012-02-28 09:48:12 PST ---
(In reply to comment #14)
> OK, committed. d9c42097770f173804c7c7c40bf8bc6c4400673b
Would it be possible to get this into the 7.11 branch as well? For
gnome-shell's screen record
- Original Message -
> Hi List,
>
> At Mozilla we've been wondering if we could get a good software
> fallback for users who can't get hardware-accelerated WebGL. Mesa
> llvmpipe seems like the best open source OpenGL renderer, right? At
> least, it performed superbly in our quick tests.
Hi List,
At Mozilla we've been wondering if we could get a good software fallback for
users who can't get hardware-accelerated WebGL. Mesa llvmpipe seems like the
best open source OpenGL renderer, right? At least, it performed superbly in our
quick tests.
Questions:
1. Is it possible for th
On 28.02.2012 00:53, Andy Furniss wrote:
Christian König wrote:
Hi everyone,
the following patchset adds most of the still missing functionality
to the VDPAU state tracker, including the support for bitmap surfaces
so Alpha Substation Subtitles in mplayer now seems to work fine.
It also imp
From: Dave Airlie
This adds support for all the opcodes needed for native integer
support with GLSL 1.20 enabled, and some of the ones for GLSL1.30
support.
I've split them between non-cpu and cpu along the same lines
Tom's code did for the other ones I think, but I'm open to review
on which one
From: Dave Airlie
These are integer opcodes not deprecated ones.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
b/src/gallium/auxiliary/galli
From: Dave Airlie
rcp asserts on type.floating so don't go passing non-floating
things into it.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
b/s
Good idea.
Jose
- Original Message -
> This lets us use the resource_copy_region() path when blitting from
> R8G8B8A8 to R8G8B8x8, for example.
>
> v2: be smarter when src_format==dst_format
> ---
> src/gallium/auxiliary/util/u_blit.c | 22 +-
> 1 files changed, 21
I can at least fix formats_compatible() to be smarter when
src_format==dst_format. I'll post a v2.
-Brian
On 02/28/2012 08:11 AM, Jose Fonseca wrote:
Looks good. Thanks for using util_format_description.
If cpu usage in u_format becomes an issue in the future I'd suggest obtaining
util_form
On Tue, Feb 28, 2012 at 10:42 AM, Brian Paul wrote:
> This lets us use the resource_copy_region() path when blitting from
> R8G8B8A8 to R8G8B8x8, for example.
>
> v2: be smarter when src_format==dst_format
Reviewed-by: Alex Deucher
> ---
> src/gallium/auxiliary/util/u_blit.c | 22 +++
This lets us use the resource_copy_region() path when blitting from
R8G8B8A8 to R8G8B8x8, for example.
v2: be smarter when src_format==dst_format
---
src/gallium/auxiliary/util/u_blit.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxi
Hi guys,
So I've gotten llvmpipe GLSL 1.20 support with native integers enabled
to be 0 regressions from non-integers enabled.
The one big problem I've hit is non-native integer llvmpipe uses
system_values, it takes them in as integers and converts them to
floats and stores that value, however th
Looks good. Thanks for using util_format_description.
If cpu usage in u_format becomes an issue in the future I'd suggest obtaining
util_format_description only once per format, as currently
util_format_description() ends up being called a few times per format.
At any rate, I think that cpu sho
https://bugs.freedesktop.org/show_bug.cgi?id=46631
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
This lets us use the resource_copy_region() path when blitting from
R8G8B8A8 to R8G8B8x8, for example.
---
src/gallium/auxiliary/util/u_blit.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blit.c
b/src/gallium/auxiliary/util
https://bugs.freedesktop.org/show_bug.cgi?id=46631
--- Comment #13 from Neil Roberts 2012-02-28 03:49:59
PST ---
(In reply to comment #11)
> Can you commit it?
I don't have commit access on Mesa unfortunately. I've just asked for access
(bug 46683) so we can wait for that or if someone wants to
Looks good to me.
Jose
- Original Message -
> From: Brian Paul
>
> ---
> src/mesa/main/varray.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
> index 39d3a27..a402c7b 100644
> --- a/src/mesa/main/
On Tue, Feb 28, 2012 at 1:55 AM, Ian Romanick wrote:
> On 02/23/2012 11:52 AM, Chad Versace wrote:
>>
>> On 02/23/2012 12:52 AM, Ian Romanick wrote:
>>>
>>> On 02/22/2012 04:06 PM, Chad Versace wrote:
On 02/22/2012 02:22 PM, Ian Romanick wrote:
>
> On 02/22/2012 02:17 PM, Paul Be
- Original Message -
> Am 27.02.2012 21:26, schrieb Jose Fonseca:
> >
> >
> > - Original Message -
> >> On Mon, Feb 20, 2012 at 01:50:43PM -0800, Jose Fonseca wrote:
> >>>
> >>>
> >>> - Original Message -
>
>
> - Original Message -
> > On Sat, Fe
On 02/27/2012 01:04 PM, Eric Anholt wrote:
We need to allocate a new buffer every batch to avoid blocking on the
last HiZ op completing. There are two easy ways to do this:
brw_state_batch() and intel_upload_data(). brw_state_batch() is
simpler and avoids another buffer allocation.
Improves Un
This looks good to me.
Marek
On Tue, Feb 28, 2012 at 4:29 AM, Brian Paul wrote:
> From: Brian Paul
>
> Assertions of the form assert(a && b) should be written as separate assertions
> so that you can actually tell which part is false when there's a failure.
> ---
> src/gallium/auxiliary/util/u
41 matches
Mail list logo
