From: Dave Airlie
The triangle_32_ rast functions never made it into the debug output,
confused me for a few seconds.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/llvmpipe/lp_rast_debug.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_ras
Fredrik's implementation of ARB_vertex_attrib_binding introduced new
gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and
converted Mesa's older gl_client_array to be derived state. Ultimately,
we'd like to drop gl_client_array and use those structures directly.
One hitch is that g
Sorry for the delay, I've been away for work and with not much free time
lately.
I'll have a look at it as soon as possible.
Alexandre Demers
On 10/09/14 06:16 AM, Glenn Kennard wrote:
On Sat, 06 Sep 2014 04:00:01 +0200, Alexandre Demers
wrote:
Thanks Marek, you were right.
So, on cayman,
https://bugs.freedesktop.org/show_bug.cgi?id=79706
Bug 79706 depends on bug 83574, which changed state.
Bug 83574 Summary: [llvmpipe] [softpipe] piglit
arb_explicit_uniform_location-use-of-unused-loc regression
https://bugs.freedesktop.org/show_bug.cgi?id=83574
What|Removed
On Fri, Sep 12, 2014 at 1:02 AM, Marc Dietrich wrote:
> Am Donnerstag, 11. September 2014, 08:52:39 schrieb Matt Turner:
>> On Thu, Sep 11, 2014 at 6:58 AM, Marc Dietrich wrote:
>> > File specific optimization as used for
>> > src/mesa/main/streaming-load-memcpy.c currently will cause problems wi
Am 13.09.2014 15:16, schrieb Brian Paul:
On 09/12/2014 03:58 PM, Jason Ekstrand wrote:
Ok, so I actually applied the patch and benchmarked it. It seems to
have improved performance in a lot of cases that were mysteriously
slow! It looks like breaking it up freed up GCC to optimize the
inside
https://bugs.freedesktop.org/show_bug.cgi?id=70402
Fabrice Bellet changed:
What|Removed |Added
CC||fabr...@bellet.info
--
You are receivi
Hi, Jose,
On Sunday, August 31, 2014 10:06:22 mathias.froehl...@gmx.net wrote:
> This makes llvmpipe thread safe as mandated by the OpenGL standard.
> The changes replace the use of two global data structures with
> non global ones.
> The changes pass piglit as of today without regressions.
> The
Hi,
On Monday, September 08, 2014 21:14:12 Marek Olšák wrote:
> Do we have a piglit to confirm unclamped Z values really work with
> current hardware drivers?
I have just sent out an updated patch set as well as a piglit test.
The first attempt was obviously too short fetched as the vital intern
From: Mathias Fröhlich
In preparation of NV_depth_buffer_float. Let the
driver decide if it could support writing depth values
beyond the [0, 1] range.
Signed-off-by: Mathias Froehlich http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Mathias Fröhlich
Will be used in the implementation of NV_depth_buffer_float.
Signed-off-by: Mathias Froehlich http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Mathias Fröhlich
This is mostly support for the unclamped versions of
glDepthRangedNV, glClearDepthdNV and glDepthBoundsdNV.
Note that OpenGL 4.2 introduced that the traditonal
glDepthRange functions may no longer clamp to [0, 1],
but OpenGL 4.3 already revoked this behavior to clamp
the ar
From: Mathias Froehlich
Factor out some functions that will get additional callers
with the implementation of NV_depth_buffer_float.
Signed-off-by: Mathias Froehlich
---
src/mesa/main/attrib.c | 2 +-
src/mesa/main/depth.c| 66 ++--
src/mesa/m
From: Mathias Fröhlich
This adds support for NV_depth_buffer_float.
Mostly the unclamped depth buffer handling which can be exploited
to get logarithmic depth buffer like behavior in a simple way.
v2
Readd clamping to the traditional gl entry points.
v3
Split the patch into preparational c
14 matches
Mail list logo
