On 01/10/2012 11:47 PM, Vadim Girlin wrote:
On Tue, 2012-01-10 at 23:36 -0800, Kenneth Graunke wrote:
Both dri2_create_context_attribs and drisw_create_context_attribs call
dri2_convert_glx_attribs, expecting it to fill in *api on success.
However, when num_attribs == 0, it was returning true w
On Tue, 2012-01-10 at 23:36 -0800, Kenneth Graunke wrote:
> Both dri2_create_context_attribs and drisw_create_context_attribs call
> dri2_convert_glx_attribs, expecting it to fill in *api on success.
>
> However, when num_attribs == 0, it was returning true without setting
> *api, causing the call
Both dri2_create_context_attribs and drisw_create_context_attribs call
dri2_convert_glx_attribs, expecting it to fill in *api on success.
However, when num_attribs == 0, it was returning true without setting
*api, causing the caller to use an uninitialized value.
Cc: Vadim Girlin
Signed-off-by:
On 01/10/2012 09:32 PM, Vadim Girlin wrote:
Signed-off-by: Vadim Girlin
---
Fixes unigine heaven startup problem for me.
src/glx/dri2_glx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 10b6f52..b4efa40 100644
--- a/sr
What about initializing "api" earlier in dri2_convert_glx_attribs
instead? i.e. before the first return. That should fix it also and is
cleaner.
Stéphane
On Tue, Jan 10, 2012 at 21:32, Vadim Girlin wrote:
> Signed-off-by: Vadim Girlin
> ---
>
> Fixes unigine heaven startup problem for me.
>
>
On 01/10/2012 10:16 PM, Matt Turner wrote:
AC_PROG_PATH was used in the original configure.ac (dca1b796b) and I
can't see any reason AC_PROG_SED wasn't used.
It looks like AC_PROG_SED was added in 2.59b, and wasn't in the original
2.59. Presumably that's why, though it could've been an oversi
On 01/10/2012 10:16 PM, Matt Turner wrote:
Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
easier while still specifically requiring bison and flex.
Based on bison.m4 and flex.m4 found in LLVM's tree.
Signed-off-by: Matt Turner
---
configure.ac |9 -
m4/bi
On 01/10/2012 10:16 PM, Kurt Roeckx wrote:
Hi,
I've send a few patches to the bug tracker, but get no reaction to
them. They're very simple and fix problems found by piglit on
i830/i915. I wonder why they don't get applied. Should I send
them to the list instead?
Ah! This is the first time
On Wed, Jan 11, 2012 at 1:16 AM, Matt Turner wrote:
> Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
> easier while still specifically requiring bison and flex.
>
> Based on bison.m4 and flex.m4 found in LLVM's tree.
>
> Signed-off-by: Matt Turner
> ---
> configure.ac |
Hi,
I've send a few patches to the bug tracker, but get no reaction to
them. They're very simple and fix problems found by piglit on
i830/i915. I wonder why they don't get applied. Should I send
them to the list instead?
Anyway, you can find them here:
https://bugs.freedesktop.org/show_bug.cgi
Signed-off-by: Matt Turner
---
configure.ac |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 08a0209..d36901b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -69,7 +69,6 @@ AC_PATH_PROG([GTESTCONFIG], [gtest-config])
if test "x$GTESTCONFI
AC_PROG_PATH was used in the original configure.ac (dca1b796b) and I
can't see any reason AC_PROG_SED wasn't used.
Signed-off-by: Matt Turner
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index c0abeb9..08a0209 100644
--- a
Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
easier while still specifically requiring bison and flex.
Based on bison.m4 and flex.m4 found in LLVM's tree.
Signed-off-by: Matt Turner
---
configure.ac |9 -
m4/bison.m4 | 16
m4/flex.m4
Signed-off-by: Vadim Girlin
---
Fixes unigine heaven startup problem for me.
src/glx/dri2_glx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 10b6f52..b4efa40 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -2
- Ensure mesa code uses the _mesa_ffs(l) functions
consistantly instead of jumping around between ffs
and _mesa_ffs
- This makes ffs/ffsl behave more like the popcount code
- Better detects and handles edge cases of missing ffs/ffsl
- Use builtin ffs/ffsl more often as it may provide
perfor
On 10.01.2012 21:53, Brian Paul wrote:
On Mon, Jan 9, 2012 at 2:39 PM, Alexander von Gluck
wrote:
---
src/mesa/main/imports.h | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index b7e8743..522ffeb 10064
On Mon, Jan 9, 2012 at 2:39 PM, Alexander von Gluck
wrote:
>
> ---
> src/mesa/main/imports.h | 16
> 1 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> index b7e8743..522ffeb 100644
> --- a/src/mesa/main/import
On Tue, Jan 3, 2012 at 8:59 PM, Yuanhan Liu wrote:
> On Wed, Jan 04, 2012 at 11:20:07AM +0800, Yuanhan Liu wrote:
>> On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
>> > Ah index scanning...
>> > I don't like that this will map/unmap the ib once for each prim,
>> Me either :)
>
In the following scenario:
- CreateContext C1
- MakeCurrent C1
- DestroyContext C1 (does not actually destroy the first context, postponed
until the next MakeCurrent)
- CreateContext C2
- MakeCurrent C2
MakeCurrent will call flush on a context which might not even have had a front
buffer, leadin
On Wed, Jan 04, 2012 at 07:23:24PM +0100, Roland Scheidegger wrote:
> Am 04.01.2012 04:59, schrieb Yuanhan Liu:
> > On Wed, Jan 04, 2012 at 11:20:07AM +0800, Yuanhan Liu wrote:
> >> On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
> >>> Ah index scanning...
> >>> I don't like tha
From: Brian Paul
This is a follow-on to the previous commits. It seems that
XShmQueryVersion() can trigger an X error after the first X
connection is closed and we start using a new connection.
Fixes a bug found by Wayne E. Robertz.
NOTE: This is a candidate for the 7.11 branch.
---
src/mesa/
From: Brian Paul
This is the same fix as the previous commit, except it's for the gallium
glx/xlib state tracker.
NOTE: This is a candidate for the 7.11 branch.
---
src/gallium/state_trackers/glx/xlib/glx_api.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/galli
From: Brian Paul
as we do in Fake_glXChooseVisual(). This registers the MesaGLX
extension on the display so we can clean up buffers, etc. when
the display connection is closed.
Fixes a bug reported by Wayne E. Robertz.
NOTE: This is a candidate for the 7.11 branch.
---
src/mesa/drivers/x11/fa
On 01/10/2012 10:09 PM, Dave Airlie wrote:
> On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt wrote:
>> On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie wrote:
>>> From: Dave Airlie
>>>
>>> Things can get confused if you expose one without the other which can happen
>>> if you are missing one or two
On Tue, Jan 10, 2012 at 7:27 PM, Marek Olšák wrote:
> On Tue, Jan 10, 2012 at 7:48 PM, Jakob Bornecrantz wrote:
>> - Original Message -
>>> These initialization functions weren't initializing all the fields so
>>> some had undefined values. The callers of these functions sometimes
>>> us
On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt wrote:
> On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> Things can get confused if you expose one without the other which can happen
>> if you are missing one or two of the extensions (like say float textures).
>
> C
On Mon, 9 Jan 2012 14:30:55 -0800, Chad Versace
wrote:
> Chad Versace (3):
> i965: Fix misnamed GEN7_WM_DEPTH_RESOLVE
> i965: Replace references to stencil region size with buffer size
> i965/gen7: Enable HiZ
Reviewed-by: Eric Anholt
pgpvhv76geS4j.pgp
Description: PGP signature
___
On Tue, 10 Jan 2012 16:14:05 +, Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes the test to allow cube/depth combinations on GL3
> or EXT_gpu_shader4.
Reviewed-by: Eric Anholt
pgpPxPvQlbXtC.pgp
Description: PGP signature
___
mesa-dev mail
On 01/10/2012 11:36 AM, Eirik Byrkjeflot Anonsen wrote:
Brian Paul writes:
---
src/mesa/main/format_unpack.c | 499 +
src/mesa/main/format_unpack.h |3 +
2 files changed, 502 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/format_unpac
On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie wrote:
> From: Dave Airlie
>
> Things can get confused if you expose one without the other which can happen
> if you are missing one or two of the extensions (like say float textures).
Can you clarify what "things can get confused" means?
pgpptt
On Tue, Jan 10, 2012 at 7:48 PM, Jakob Bornecrantz wrote:
> - Original Message -
>> These initialization functions weren't initializing all the fields so
>> some had undefined values. The callers of these functions sometimes
>> use a structure assignment to initialize new objects from the
Brian Paul writes:
> ---
> src/mesa/main/format_unpack.c | 499
> +
> src/mesa/main/format_unpack.h |3 +
> 2 files changed, 502 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
> index c723
Fixes a regression in codegen quality from the old VS backend to the
new one, where matrix multiplies were more expensive in instruction
count.
shader-db results:
Total instructions: 58540 -> 55984
815/870 programs affected (93.7%)
57412 -> 54856 instructions in affected programs (4.5% reduction)
On 01/10/2012 11:48 AM, Jakob Bornecrantz wrote:
- Original Message -
These initialization functions weren't initializing all the fields so
some had undefined values. The callers of these functions sometimes
use a structure assignment to initialize new objects from these
templates so we
These initialization functions weren't initializing all the fields so
some had undefined values. The callers of these functions sometimes use
a structure assignment to initialize new objects from these templates
so we'd just propagate the undefined values. That made for some confusing
info when d
- Original Message -
> These initialization functions weren't initializing all the fields so
> some had undefined values. The callers of these functions sometimes
> use a structure assignment to initialize new objects from these
> templates so we'd just propagate the undefined values. Tha
The u_surface_default_template() function does the memset()/zero now.
---
src/mesa/state_tracker/st_manager.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index c0af3ce..b83cb23 100644
--- a/src/
These initialization functions weren't initializing all the fields so
some had undefined values. The callers of these functions sometimes use
a structure assignment to initialize new objects from these templates
so we'd just propagate the undefined values. That made for some confusing
info when d
https://bugs.freedesktop.org/show_bug.cgi?id=44561
--- Comment #5 from Stephane Marchesin 2012-01-10
10:33:00 PST ---
I don't think it's a bug in i915g proper, since we don't handle vertex shaders
in there, or any vertex stuff for that matter, but instead rely on draw. I'll
try Dave'd draw patch
https://bugs.freedesktop.org/show_bug.cgi?id=44561
Christoph Bumiller changed:
What|Removed |Added
Keywords|regression |
--- Comment #4 from Christoph Bumi
- Original Message -
> On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca
> wrote:
> > - Original Message -
> >> The flag is optional, it doesn't have to implemented by everybody.
> >> If
> >> we do the uploads in the state tracker, we will also do any
> >> required
> >> data transfor
https://bugs.freedesktop.org/show_bug.cgi?id=44561
--- Comment #3 from Kai 2012-01-10 09:11:19 PST
---
(In reply to comment #2)
So do I understand you correctly, that this bug is then no regression for r600g
and i915g (I'm seeing this on r600g)? If so, the "regression" keyword should
probably be
On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca wrote:
> - Original Message -
>> The flag is optional, it doesn't have to implemented by everybody. If
>> we do the uploads in the state tracker, we will also do any required
>> data transformation so that drivers don't have to do it at all.
>
https://bugs.freedesktop.org/show_bug.cgi?id=44564
--- Comment #3 from Vinson Lee 2012-01-10 08:56:58 PST
---
(In reply to comment #2)
> Anyway, Mesa doesn't need LLVM libraries except in `$LLVM_CONFIG --libs
> engine`
> to build/run?
I tried the SCons build using 'llvm-config --libs engine' a
- Original Message -
> On 01/10/2012 01:13 PM, Jose Fonseca wrote:
> > - Original Message -
> >> On 10.01.2012 12:29, Jose Fonseca wrote:
> >>> Still catching up on email traffic during holidays...
> >>>
> >>> I agree that user buffer uploads should be moved out of drivers,
> >>>
https://bugs.freedesktop.org/show_bug.cgi?id=44561
--- Comment #2 from Christoph Bumiller
2012-01-10 08:26:03 PST ---
Like I already mentioned on ML, i915g isn't using the ClipVertex for the
clipping calculation, but Position (ClipVertex didn't exist before, thus
whenever it was not equal to gl_
On Tue, Jan 10, 2012 at 12:49 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This just fixes up the enables for native integers and EXT_texture_integer
> support in st/mesa.
>
> It also set the MaxClipPlanes to 8.
>
> We should consider exposing caps for MCP vs MCD, but since core
> mesa doesn't
From: Dave Airlie
This fixes the test to allow cube/depth combinations on GL3
or EXT_gpu_shader4.
Signed-off-by: Dave Airlie
---
src/mesa/main/texobj.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 7ee2005.
On 01/10/2012 01:13 PM, Jose Fonseca wrote:
> - Original Message -
>> On 10.01.2012 12:29, Jose Fonseca wrote:
>>> Still catching up on email traffic during holidays...
>>>
>>> I agree that user buffer uploads should be moved out of drivers,
>>> but I don't think this is the way to go.
>>
>
- Original Message -
> On Tue, Jan 10, 2012 at 12:29 PM, Jose Fonseca
> wrote:
> > Still catching up on email traffic during holidays...
> >
> > I agree that user buffer uploads should be moved out of drivers,
> > but I don't think this is the way to go.
> >
> > This "PIPE_TRANSFER_MAP_PER
On 01/10/2012 09:06 AM, Dave Airlie wrote:
Something in Gallium is probably deciding that GL_DEPTH_COMPONENT is
invalid for a cubemap and marking it as incomplete.
Hmmm, I'm not sure what would be preventing cube textures in gallium or the
state tracker.
Something in Mesa is doing it,
texo
>>
>> Something in Gallium is probably deciding that GL_DEPTH_COMPONENT is
>> invalid for a cubemap and marking it as incomplete.
>
>
> Hmmm, I'm not sure what would be preventing cube textures in gallium or the
> state tracker.
Something in Mesa is doing it,
texobj.c:_mesa_test_texobj_completene
Hi Maarten,
On 08.01.2012 14:09, Maarten Lankhorst wrote:
Ok. I wont block it any more then. Do you have a followup patch to get
rid of quant matrix and separate reference pictures too? Or should I
resend it, I kind of lost my rebased git tree, so if you already have
the followup patches it wo
We actually implemented YV21 instead of YV12, so fix the plane ordering.
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 13 +---
src/gallium/auxiliary/vl/vl_video_buffer.c | 37 +++--
src/gallium/auxiliary/vl/vl_video_buffer.h |
Recreate the video buffer if the decoder can't handle it.
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/decode.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_tra
Recreate the video buffer in PutBitsYCbCr if the format doesn't match.
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/surface.c | 54 ++---
src/gallium/state_trackers/vdpau/vdpau_private.h |2 +-
2 files changed, 37 insertions(+), 19 deletions(-)
Create the video buffers in the format the driver preffers.
This temporary creates problems with decoder less VDPAU video playback.
Signed-off-by: Christian König
---
src/gallium/drivers/nouveau/nouveau_video.c|2 ++
src/gallium/drivers/nvfx/nvfx_screen.c |2 ++
src/gallium/d
No implementation so far, just the defines for
VDPAUs picture info structure.
Signed-off-by: Christian König
---
src/gallium/include/pipe/p_video_state.h | 40 +++
src/gallium/state_trackers/vdpau/decode.c | 61 +
2 files changed, 101 insertions(+
Add a second extened constructor that takes plane
textures for the video buffer. Also provide a
function for texture templates.
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 112 +---
src/gallium/auxiliary/vl/vl_video_buffer.h | 17 +++
Just like in the rest of gallium, this reduces the
number of parameters significantly.
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 27 ++
src/gallium/auxiliary/vl/vl_video_buffer.c | 47 ++--
src/gallium/auxiliary/vl
Add the infrastructure, but not the decode implementation.
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 35 ++-
src/gallium/auxiliary/vl/vl_video_buffer.h |2 +-
src/gallium/include/pipe/p_video_decoder.h |1 +
3 files changed,
On Tue, Jan 10, 2012 at 2:40 AM, Jakob Bornecrantz wrote:
> On Tue, Jan 10, 2012 at 12:01 AM, Alan Coopersmith
> wrote:
>> On 01/ 9/12 02:53 PM, Jakob Bornecrantz wrote:
>>>
>>> - struct pipe_shader_state pss = { 0 };
>>> + struct pipe_shader_state pss;
>>> + memset(&pss, 0, sizeof(pss));
>
The check-in message should probably be "draw: clipdistance support
(v1)", not "softpipe".
On 01/10/2012 06:55 AM, Dave Airlie wrote:
From: Dave Airlie
Add support for using the clipdistance instead of clip plane.
Passes all piglit clipdistance tests.
Signed-off-by: Dave Airlie
---
src/ga
2012/1/10 Michel Dänzer :
> On Mon, 2012-01-09 at 23:53 +0100, Jakob Bornecrantz wrote:
>> Signed-off-by: Jakob Bornecrantz
>> ---
>> src/mesa/.gitignore | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/mesa/.gitignore b/src/mesa/.gitignore
>> index ce83eaf..0c
On Tue, Jan 10, 2012 at 12:29 PM, Jose Fonseca wrote:
> Still catching up on email traffic during holidays...
>
> I agree that user buffer uploads should be moved out of drivers, but I don't
> think this is the way to go.
>
> This "PIPE_TRANSFER_MAP_PERMANENTLY" means the driver relinquishes the
From: Jerome Glisse
Virtual address space put the userspace in charge of their GPU
address space. It's up to userspace to bind bo into the virtual
address space. Command stream can them be executed using the
IB_VM chunck.
This patch add support for this configuration. It doesn't remove
the 64K i
On 01/10/2012 08:34 AM, Brian Paul wrote:
On 01/10/2012 04:56 AM, Dave Airlie wrote:
Module: Mesa
Branch: master
Commit: 67e3cbf1632e361220234013147331e4618b70cb
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=67e3cbf1632e361220234013147331e4618b70cb
Author: Dave Airlie
Date: Mon Jan 9 1
On 01/10/2012 04:56 AM, Dave Airlie wrote:
Module: Mesa
Branch: master
Commit: 67e3cbf1632e361220234013147331e4618b70cb
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=67e3cbf1632e361220234013147331e4618b70cb
Author: Dave Airlie
Date: Mon Jan 9 15:57:02 2012 +
gallium: introduc
Dave,
- Original Message -
> From: Dave Airlie
>
> Just add support to the scanner to count the number of clip
> distances.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/auxiliary/tgsi/tgsi_scan.c |4
> src/gallium/auxiliary/tgsi/tgsi_scan.h |1 +
> 2 files changed,
- Original Message -
> From: Dave Airlie
>
> Mesa shouldn't call into the drivers if there are no renderbuffers
> bound to the attachments for the buffers to be cleared.
>
> Fixes a number of the clearbuffer-* tests on softpipe.
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/main/c
From: Dave Airlie
Add support for using the clipdistance instead of clip plane.
Passes all piglit clipdistance tests.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/draw/draw_cliptest_tmp.h | 25 ++--
src/gallium/auxiliary/draw/draw_context.c |6
src/gallium/
From: Dave Airlie
Just add support to the scanner to count the number of clip distances.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_scan.c |4
src/gallium/auxiliary/tgsi/tgsi_scan.h |1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/galliu
From: Dave Airlie
softpipe always clipped using the position vector, however for unclipped
vertices it stored the position in window coordinates, however when position
and clipping are separated, we need to store the clip-space position and
the clip-space vertex clip, so we can interpolate both s
From: Dave Airlie
This required changing the system value semantics, so we stored
a system value per vertex, instance id is the only other system
value we currently support, so I span it across the channels.
This passes the 3 vertexid-* piglit tests + lots of instanceid tests.
Signed-off-by: Da
From: Dave Airlie
If draw isn't using llvm we can support vertex texture and integers,
These will be fixed up later, but for now allow this check to happen
at run-time.
v2: since 3e22c7a25321554a32fa6254485912fd53deff3a we can ask draw for a
non-llvm
context. Just track if ask and set the vars
On Tue, Jan 10, 2012 at 1:08 PM, Jakob Bornecrantz wrote:
> On Tue, Jan 10, 2012 at 12:49 PM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> If draw isn't using llvm we can support vertex texture and integers,
>> These will be fixed up later, but for now allow this check to happen
>> at run-time.
On Tue, Jan 10, 2012 at 12:49 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> If draw isn't using llvm we can support vertex texture and integers,
> These will be fixed up later, but for now allow this check to happen
> at run-time.
With my draw_create_no_llvm change this logic no longer holds tr
From: Dave Airlie
Mesa shouldn't call into the drivers if there are no renderbuffers
bound to the attachments for the buffers to be cleared.
Fixes a number of the clearbuffer-* tests on softpipe.
Signed-off-by: Dave Airlie
---
src/mesa/main/clear.c | 15 +++
1 files changed, 11
Dear Stéphane,
Stéphane Marchesin schrieb am 10.01.2012 04:52:
> This regresses interpolation-none-gl_FrontColor-flat-vertex.shader_test
> piglit test on i915g.
this looks like bz#44561 [0] to me. If so we should take the discussion there to
have it in one place.
Kind regards,
Kai Wasserbäch
[0
- Original Message -
> On 10.01.2012 12:29, Jose Fonseca wrote:
> > Still catching up on email traffic during holidays...
> >
> > I agree that user buffer uploads should be moved out of drivers,
> > but I don't think this is the way to go.
>
> I don't. If the state tracker uploads user buf
From: Dave Airlie
Things can get confused if you expose one without the other which can happen
if you are missing one or two of the extensions (like say float textures).
Signed-off-by: Dave Airlie
---
src/mesa/main/version.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --
From: Dave Airlie
This just fixes up the enables for native integers and EXT_texture_integer
support in st/mesa.
It also set the MaxClipPlanes to 8.
We should consider exposing caps for MCP vs MCD, but since core
mesa doesn't care yet maybe we can wait for now.
Signed-off-by: Dave Airlie
---
From: Dave Airlie
If draw isn't using llvm we can support vertex texture and integers,
These will be fixed up later, but for now allow this check to happen
at run-time.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/draw/draw_context.c | 10 ++
src/gallium/auxiliary/draw/draw_c
This code is unneeded now, we don't use render temps any more.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/nvfx/nvfx_fragtex.c |4 -
src/gallium/drivers/nvfx/nvfx_miptree.c | 18 +---
src/gallium/drivers/nvfx/nvfx_resource.h | 30 +--
src/gallium/drivers/nvfx/nvfx_surface.c
This commit rewrites a lot of the state_fb code to support
rendering to targets not aligned to 64 byte.
This allows us to drop the render temporaries as unaligned
targets are the only use-case where they are really needed. The
temporaries code was used for a lot of things more, but apparently
thos
Signed-off-by: Lucas Stach
---
src/gallium/drivers/nvfx/nvfx_state_emit.c | 49 ---
1 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_state_emit.c
b/src/gallium/drivers/nvfx/nvfx_state_emit.c
index e2cfb76..a959015 100644
---
nvfx doesn't support any kind of stream out, so silence the
unused cap warnings.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/nvfx/nvfx_screen.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c
b/src/gallium/drivers/nvfx/
This patch series silences some unknown cap warnings and fixes up
coding style (patch 1+4).
The most important part of this series are the two patches in the
middle. They rework the state_fb code, so that we are able to
render to not 64 byte aligned targets, as this is the only re
On 10.01.2012 12:29, Jose Fonseca wrote:
> Still catching up on email traffic during holidays...
>
> I agree that user buffer uploads should be moved out of drivers, but I don't
> think this is the way to go.
I don't. If the state tracker uploads user buffers and presents them to
the driver as n
Still catching up on email traffic during holidays...
I agree that user buffer uploads should be moved out of drivers, but I don't
think this is the way to go.
This "PIPE_TRANSFER_MAP_PERMANENTLY" means the driver relinquishes the ability
to transform this data in any way before reashing the G
On 10.01.2012 04:52, Stéphane Marchesin wrote:
> Hi Dave,
>
> This regresses interpolation-none-gl_FrontColor-flat-vertex.shader_test
> piglit test on i915g.
That's likely. You're probably not using the ClipVertex but instead
gl_Position for clipping since the prior was not identifiable before.
T
https://bugs.freedesktop.org/show_bug.cgi?id=44564
--- Comment #2 from ojab 2012-01-10 02:44:58 PST ---
Anyway, Mesa doesn't need LLVM libraries except in `$LLVM_CONFIG --libs engine`
to build/run?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiv
https://bugs.freedesktop.org/show_bug.cgi?id=44618
Bug #: 44618
Summary: Cross-compilation broken by glsl builtin_compiler
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status:
On 01/06/2012 04:49 PM, Ian Romanick wrote:
Patches 01/14 through 03/14 was previously sent to the list. It
tickled a pre-existing bug (fixed by patch recently posted to the list
by Eric) on some Intel chipsets.
Patches 04/14 through 07/14 make the linker do some sampler tracking
that was previ
On 01/09/2012 05:26 PM, Eric Anholt wrote:
On Fri, 6 Jan 2012 16:50:00 -0800, "Ian Romanick" wrote:
From: Ian Romanick
There are several things that could cause the fragment shader
precompile to fail. Looking for calls to 'fail' in brw_fs_visitor.cpp
finds three classes of things:
* Tryi
95 matches
Mail list logo
