https://bugs.freedesktop.org/show_bug.cgi?id=45571
--- Comment #7 from Alexandre Demers 2012-02-04
21:07:34 PST ---
I tried using "git clean -dfx" as suggested, which means I run both git clean
-dfx and make realclean. The build ends up with an error anyway. However, the
error is not the same:
https://bugs.freedesktop.org/show_bug.cgi?id=45571
--- Comment #6 from Matt Turner 2012-02-04 21:00:38 UTC ---
(In reply to comment #4)
> If it is necessary to run "git clean -dfx" after every change
> to mesa that means nothing but that the build system is broken
> and should be fixed.
How do y
https://bugs.freedesktop.org/show_bug.cgi?id=45571
--- Comment #5 from Jos van Wolput 2012-02-04
20:31:24 UTC ---
(In reply to comment #2)
> You should run `git clean -dfx` and rerun autogen.sh after changes to Mesa.
I run into this error too.
Running git clean -dfx doesn't solve this issue.
In
On 02/04/2012 09:48 AM, Chad Versace wrote:
Anyway, that's all moot since that I've killed the shaders. I now just
call gen6_hiz_init() from inside gen6_hiz_exec().
Awesome.
Just put the VS in passthrough mode by removing the GEN6_VS_ENABLE bit from
your 3DSTATE_VS packet. Then, it will do
On Sat, Feb 4, 2012 at 12:40 PM, Kenneth Graunke wrote:
> I'm leaning toward dropping this code that clamps "end" altogether. It's
> awfully dodgy already, and trying to correctly compensate for basevertex is
> pretty much destroying any faith I had left in it working properly.
>
> After all, glDr
On Fri, Feb 3, 2012 at 23:14, Carl Worth wrote:
> Something has gone wrong if we have to revert to software rendering.
> The user really should be made aware of this, (and instructed to set
> LIBGL_DEBUG for more details).
> ---
> src/glx/dri_glx.c |2 +-
> 1 files changed, 1 insertions(+),
On Sat, Feb 4, 2012 at 5:34 AM, Eric Anholt wrote:
> On Tue, 13 Dec 2011 12:01:56 -0800, Anuj Phogat
> wrote:
> > Enabling display list support for glClearBuffer functions with minor
> fixes
>
> Is this ready to get pushed?
>
Eric, this patch was pushed by following commit:
commit 36a484bc9853
From: Dave Airlie
this fixes the fogcoord related piglit tests, like I fixed them in softpipe.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/draw/draw_llvm.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llv
Comments to your comments, and the new patch is at hiz-kill-meta-op-v12.
I'm still working on gen7.
On 02/03/2012 06:16 PM, Kenneth Graunke wrote:
> On 02/03/2012 03:58 PM, Chad Versace wrote:
>> /**
>> - * Initialize static data needed for HiZ operations.
>> + * \return true on success
>
> No
On Fri, 03 Feb 2012 11:25:06 +, Jon TURNEY
wrote:
> On 03/02/2012 09:28, Eric Anholt wrote:
> > On Thu, 02 Feb 2012 10:54:22 +, Jon TURNEY wrote:
> >> On 27/01/2012 20:20, Matt Turner wrote:
> >>> On Fri, Jan 27, 2012 at 8:11 PM, Jon TURNEY wrote:
> On 27/01/2012 08:03, Eric Anholt w
https://bugs.freedesktop.org/show_bug.cgi?id=45622
Bug #: 45622
Summary: incorrect constant used with pipe_resource field?
Classification: Unclassified
Product: Mesa
Version: 7.11
Platform: Other
OS/Version: All
Status
https://bugs.freedesktop.org/show_bug.cgi?id=45571
Knut Petersen changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
On Tue, 13 Dec 2011 12:01:56 -0800, Anuj Phogat wrote:
> Enabling display list support for glClearBuffer functions with minor fixes
Is this ready to get pushed?
pgpuRQS4myg8x.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.free
We were doing saturate-based clamping on the [0,width] or [0,height]
coordinate, which meant only the first pixel was addressable.
Fixes piglit ARB_texture_rectangle/texwrap-RECT-bordercolor
---
I feel dirty.
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 54 +++--
1 files
- Original Message -
> On 01/27/2012 06:00 PM, Roland Scheidegger wrote:
> > in check_index_bounds the comparison needs to be "greater equal"
> > since
> > contrary to the name _MaxElement is the count of the array.
> > In vbo_exec_DrawRangeElementsBaseVertex, take into account the
> > ba
Hi Kenneth,
I agree with the behavior change for compatability sake, but I think there's a
distinction to be made here in the warnings passed to the user.
The spec says the app supplied [start, end] range are supposed to be
conservative hints of the ranges of index value in the index buffer, i
On 01/27/2012 06:00 PM, Roland Scheidegger wrote:
in check_index_bounds the comparison needs to be "greater equal" since
contrary to the name _MaxElement is the count of the array.
In vbo_exec_DrawRangeElementsBaseVertex, take into account the basevertex.
As far as I can tell it is completely ok
On 04/02/2012 01:14, Carl Worth wrote:
> I recently had a problem with a dri driver failing to load, (it turned
> out to be a case of the driver being built for 64-bit, but running a
> 32-bit application).
>
> At the time, mesa switched over to indirect rendering without me
> realizing it at all.
Certain applications, such as Regnum Online, appear to pass invalid
start/end values to glDrawRangeElements. In particular, the 'end' index
sometimes exceeds the maximum array element.
In this case, we issued a warning and attempted to "fix" the end value
by clamping it to the last array element.
https://bugs.freedesktop.org/show_bug.cgi?id=45578
--- Comment #4 from Vinson Lee 2012-02-04 00:12:29 PST
---
(In reply to comment #2)
> Created attachment 56575 [details] [review]
> don't use _mesa_format_to_type_and_comps() to choose color type
>
> Can you give this patch a try?
Tested patch
20 matches
Mail list logo
