On Fri, May 18, 2012 at 08:55:39AM -0600, Brian Paul wrote:
> In any case, I think this function could be moved into u_math.c so it
> could be used elsewhere.
[...]
> I was looking at the GLSL round() and roundEven() functions. The GLSL
> spec says round() can use whatever method is fastest. Bu
https://bugs.freedesktop.org/show_bug.cgi?id=51366
Olivier Galibert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
That capability requires integer handling and that's not yet active,
ending with a failure in draw-non-instanced unless you force it on.
See bug 51366.
Frankly, I'd rather have that patch rejected and integer/glsl 130
capability activated instead. There still are things missing, but
they most
https://bugs.freedesktop.org/show_bug.cgi?id=51366
--- Comment #1 from Olivier Galibert 2012-06-24 23:29:14
PDT ---
Argh. That's fixed with a MESA_GLSL_VERSION_OVERRIDE=130. So that's going to
go away as soon as we dare switching that in lp_screen.c.
Since ARB_draw_instanced requires integer
Tom Stellard wrote:
This is an error caused by parallel build.
Ok, thanks for the confirmation.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sun, Jun 24, 2012 at 08:56:31PM +0100, Andy Furniss wrote:
> Andy Furniss wrote:
>
> > Anyway this is the random, probably parallel build related fail I saw -
> > I don't know yet if it's just your tree + last change or not, but I
> > built several times OK when finding a working commit earlier
Andy Furniss wrote:
Anyway this is the random, probably parallel build related fail I saw -
I don't know yet if it's just your tree + last change or not, but I
built several times OK when finding a working commit earlier.
I posted the wrong error - this one is from current head, the last one
Vadim Girlin wrote:
Thanks for testing. I've updated the branch with possible fix, could you
try it again?
It seems OK now.
I say seems because I had a bit of a build issue with llvm and make -j5,
but just make alone seemed to get past it.
Previously I tested with and without building with
On Sun, Jun 24, 2012 at 6:38 PM, Vadim Girlin wrote:
> On Sun, 2012-06-24 at 17:43 +0200, Marek Olšák wrote:
>> Hi Vadim,
>>
>> This is:
>>
>> Reviewed-by: Marek Olšák
>>
>> I'd like to point out an issue here, which has nothing to do with your
>> patch, just so you know.
>>
>> Flushing in create
On Sun, 2012-06-24 at 15:45 +0100, Andy Furniss wrote:
> Andy Furniss wrote:
> > Andy Furniss wrote:
> >> Vadim Girlin wrote:
> >>
> >>> git://github.com/VadimGirlin/mesa.git
> >>>
> >>> www: https://github.com/VadimGirlin/mesa/compare/r600-perf
> >>>
> >>> Could anybody test them for regressions o
On Sun, 2012-06-24 at 17:43 +0200, Marek Olšák wrote:
> Hi Vadim,
>
> This is:
>
> Reviewed-by: Marek Olšák
>
> I'd like to point out an issue here, which has nothing to do with your
> patch, just so you know.
>
> Flushing in create_sampler_view is wrong. Some people have been
> wondering why
Andy Furniss wrote:
Andy Furniss wrote:
Vadim Girlin wrote:
git://github.com/VadimGirlin/mesa.git
www: https://github.com/VadimGirlin/mesa/compare/r600-perf
Could anybody test them for regressions on non-evergreen cards
(R6xx/7xx/CAYMAN)?
nexuiz failed for me on rv790 (only thing I tested)
Hi Vadim,
This is:
Reviewed-by: Marek Olšák
I'd like to point out an issue here, which has nothing to do with your
patch, just so you know.
Flushing in create_sampler_view is wrong. Some people have been
wondering why depth flushes are not realiable while there is such
an obvious mistake right
Andy Furniss wrote:
Vadim Girlin wrote:
git://github.com/VadimGirlin/mesa.git
www: https://github.com/VadimGirlin/mesa/compare/r600-perf
Could anybody test them for regressions on non-evergreen cards
(R6xx/7xx/CAYMAN)?
nexuiz failed for me on rv790 (only thing I tested).
Brief screen full
Vadim Girlin wrote:
git://github.com/VadimGirlin/mesa.git
www: https://github.com/VadimGirlin/mesa/compare/r600-perf
Could anybody test them for regressions on non-evergreen cards
(R6xx/7xx/CAYMAN)?
nexuiz failed for me on rv790 (only thing I tested).
Brief screen full of black&white noise
On Sun, 2012-06-24 at 17:43 +0400, Vadim Girlin wrote:
> Allocate flushed depth texture in the VRAM if we aren't going to access it by
> CPU. If we need CPU access later, then it'll be reallocated in the GTT.
> Currently it's not reallocated in the opposite direction (GTT->VRAM), though
> probably
Allocate flushed depth texture in the VRAM if we aren't going to access it by
CPU. If we need CPU access later, then it'll be reallocated in the GTT.
Currently it's not reallocated in the opposite direction (GTT->VRAM), though
probably we might want to do it too. Anyway, it helps the apps that don
That old bug was hidden but the clipper always interpolating in 3d
space no matter what it should have been doing. Now that the
interpolation has been fixed, the bug shows up.
Fixes bugzilla 51364.
Signed-off-by: Olivier Galibert
diff --git a/src/mesa/state_tracker/st_program.c
b/src/
https://bugs.freedesktop.org/show_bug.cgi?id=51364
Olivier Galibert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=51364
--- Comment #2 from Olivier Galibert 2012-06-24 02:15:00
PDT ---
Created attachment 63395
--> https://bugs.freedesktop.org/attachment.cgi?id=63395
clipdistance interpolation type correction
--
Configure bugmail: https://bugs.freedesktop.org/
This also currently fix the installation of libOSmesa.
v2: Remove old Makefile, libOSmesa is now versioned, fix typos
v3: Keep config substitution alphabetized
---
configure.ac| 5
src/mesa/drivers/osmesa/Makefile| 51 -
src/me
21 matches
Mail list logo