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.
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. This
Signed-off-by: Niels Ole Salscheider
---
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
--- a/src/gallium/drivers/r600/r600_sh
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 impl
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
Date: Mon, 13 May 2013 21:50
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 test
Kenneth Graunke 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 hits this path, c
On 05/14/2013 11:51 AM, Paul Berry wrote:
On 13 May 2013 12:02, Ian Romanick 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 that knows that cod
On 05/14/2013 03:50 PM, Dave Airlie wrote:
On Wed, May 15, 2013 at 2:03 AM, Marek Olšák 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 ++
src/mes
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 wrote:
> On Wed, May 15, 2013 at 2:03 AM, Marek Olšák wrote:
>> Some Gallium drivers were crashing, because
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 thous
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
Tom Stellard writes:
> From: Tom Stellard
>
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, just
call it twice to get the number of v
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.
>
14 matches
Mail list logo
