On 13/05/13 21:02, Ian Romanick wrote:
I've just picked over a bunch of commits to the 9.1 branch. There are a
few commits (some fairly old) that wouldn't pick cleanly. Hopefully
someone that knows that code can either resolve the conflicts or add the
commit IDs to bin/.cherry-ignore.
I'd
Tom Stellard t...@stellard.net writes:
From: Tom Stellard thomas.stell...@amd.com
Hi Tom. This should probably leave out any devices that don't match the
type argument. To avoid duplicating the type-matching logic I think the
best would be to keep it implemented in terms of clGetDeviceIDs,
On 05/15/2013 10:47 AM, EoD wrote:
On 13/05/13 21:02, Ian Romanick wrote:
I've just picked over a bunch of commits to the 9.1 branch. There are a
few commits (some fairly old) that wouldn't pick cleanly. Hopefully
someone that knows that code can either resolve the conflicts or add the
commit
Unless the application is using PBOs, any call to glReadPixels will hit
this message. Hitting this does mean mapping the buffer and accessing
it via the CPU, but that isn't necessarily the worst thing in the world.
apitrace's image dumping code hits this path, causing it to spam
hundreds of
I think it would be better to change PIPE_MAX_CONSTANT_BUFFERS to 16,
because no API has more than 16 constant buffers to my knowledge.
Marek
On Wed, May 15, 2013 at 12:50 AM, Dave Airlie airl...@gmail.com wrote:
On Wed, May 15, 2013 at 2:03 AM, Marek Olšák mar...@gmail.com wrote:
Some Gallium
On 05/14/2013 03:50 PM, Dave Airlie wrote:
On Wed, May 15, 2013 at 2:03 AM, Marek Olšák mar...@gmail.com wrote:
Some Gallium drivers were crashing, because the array was not large enough.
NOTE: This is a candidate for the stable branches.
---
src/mesa/main/bufferobj.c | 10
On 05/14/2013 11:51 AM, Paul Berry wrote:
On 13 May 2013 12:02, Ian Romanick i...@freedesktop.org
mailto:i...@freedesktop.org wrote:
I've just picked over a bunch of commits to the 9.1 branch. There
are a few commits (some fairly old) that wouldn't pick cleanly.
Hopefully someone
Kenneth Graunke kenn...@whitecape.org writes:
Unless the application is using PBOs, any call to glReadPixels will hit
this message. Hitting this does mean mapping the buffer and accessing
it via the CPU, but that isn't necessarily the worst thing in the world.
apitrace's image dumping code
Change default waffle platform from GLX to XEGL for GLES tests.
The default platform was GLX for all GL tests (GL and GLES). But not all
GLX implementations support creation of ES1 and ES2 contexts. Unless the
user explicitly set PIGLIT_PLATFORM to some EGL platform, this problem
caused GLES
Hi,
The attached patches add some new patterns and instructions for SI and
are a prerequisite for more invasive compute shader changes that I'm
working on.
Please Review.
-Tom
From 5b87402d1290df5ec8bdbe1333cadb5739a8c8bd Mon Sep 17 00:00:00 2001
From: Tom Stellard thomas.stell...@amd.com
Date:
This was intended for the Piglit list.
Please ignore, (or better yet, go review it on the proper list).
On 05/15/2013 01:27 PM, Chad Versace wrote:
Change default waffle platform from GLX to XEGL for GLES tests.
The default platform was GLX for all GL tests (GL and GLES). But not all
GLX
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
---
src/gallium/drivers/r600/r600_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 4e5af70..4d74db0 100644
---
When an application is using PBOs, we attempt to use the BLT engine to
perform ReadPixels. If that fails due to some restrictions, it's useful
to raise a performance warning.
In the non-PBO case, we always use a CPU mapping since getting the data
into client memory requires a CPU-side copy.
https://bugs.freedesktop.org/show_bug.cgi?id=64649
romula...@gmail.com changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
14 matches
Mail list logo
