d = xcb_screen_allowed_depths_iterator(s.data);
+ while (d.rem > 0) {
EGLBoolean class_added[6] = { 0, };
visuals = xcb_depth_visuals(d.data);
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
signature.asc
Description: This is a digitally signed message part
busywaiting if the user provided a timeout.
Signed-off-by: Simon Farnsworth
---
This is now ready to apply. We might also want to backport it to the 8.0
branch, as without this or an equivalent, a GPU reset can result in
applications busywaiting forever.
v4: Rebase against master - cleanups to r600g
On Thursday 9 February 2012 20:31:18 Marek Olšák wrote:
> 2012/2/9 Simon Farnsworth :
> > On Wednesday 8 February 2012 18:28:05 Michel Dänzer wrote:
> >> On Fre, 2012-02-03 at 17:32 +, Simon Farnsworth wrote:
> >> > --- a/src/gallium/drivers/r600/r600_hw_cont
On Wednesday 8 February 2012 18:28:05 Michel Dänzer wrote:
> On Fre, 2012-02-03 at 17:32 +0000, Simon Farnsworth wrote:
> > r300g is able to sleep until a fence completes rather than busywait
> > because it creates a special buffer object and relocation that stays
> > busy un
busywaiting if the user provided a timeout.
Signed-off-by: Simon Farnsworth
---
v3: At Dave Airlie's suggestion on dri-devel, make use of the BO to give us
a fighting chance of recovering after a GPU reset.
We know that the fence will never be signalled by hardware if the dummy BO
has gone idle
busywaiting if the user provided a timeout.
Signed-off-by: Simon Farnsworth
---
v2: Address Michel's review comments.
The fake bo is now unconditional, and is unreferenced when the fence is
moved to the fence pool by fence_reference. This entailed shifting to
r600_resource, which cleaned the code
On Wednesday 1 February 2012, Michel Dänzer wrote:
> On Mit, 2012-02-01 at 15:01 +0000, Simon Farnsworth wrote:
> > + if (sleep_bo) {
> > + unsigned reloc_index;
> > + /* Create a dummy BO so that fence_finish without a timeout can
> > s
On Wednesday 1 February 2012, Simon Farnsworth
wrote:
> This is a userspace only fix for my problem, as suggested by Mark Olšák. It
My apologies, Marek; my typing appears to have failed me, and renamed you to
Mark. I shall try not to make that mistake again.
--
Simon Farnsworth
Softw
busywaiting if the user provided a timeout.
Signed-off-by: Simon Farnsworth
---
This is a userspace only fix for my problem, as suggested by Mark Olšák. It
doesn't fix the case with a timeout (which doesn't matter to me), but works
on existing kernels.
Given that my previous suggested fix op
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
---
There's debate on
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
If the new kernel interface is unavailable, fall back to busywaiting.
Signed-off-by: Simon Farnsworth
---
This is simply addressing Michel's review comments against the v1
On Tuesday 31 January 2012, Michel Dänzer wrote:
> On Die, 2012-01-31 at 17:02 +0000, Simon Farnsworth wrote:
> > Instead of busywaiting for the GPU to finish a fence, use the new kernel
> > interface to wait for fence completion.
> >
> > If the new kernel interface i
However its use on Linux has sneaked back in causing suboptimal
> performance such as reported by Simon Farnsworth on r600g. Use sleep on
> Linux instead.
>
> Signed-off-by: Alan Swanson
>
I should note that I'm running my 3D app real-time (SCHED_RR) - the
performance pain I was fa
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
If the new kernel interface is unavailable, fall back to busywaiting.
Signed-off-by: Simon Farnsworth
---
This builds on top of the kernel interface I add in Message-Id:
<1328029
set in the
kernel and use those.
At a future date, I can envisage the DDX wanting to choose a different
tiling layout for DRI2 buffers, or XComposite backing pixmaps (e.g. because
someone's benchmarked it and found that choosing something beyond the bare
minimum that meets constraints impro
On Tuesday 13 December 2011, Simon Farnsworth
wrote:
> R600 and Evergreen have different tiling requirements. Fix Mesa to match the
> documented requirements.
>
> Signed-off-by: Simon Farnsworth
> ---
>
> This doesn't fix my problems with enabling macro tiling, but
R600 and Evergreen have different tiling requirements. Fix Mesa to match the
documented requirements.
Signed-off-by: Simon Farnsworth
---
This doesn't fix my problems with enabling macro tiling, but it does help
somewhat. I also need to fix tile shape in the kernel and alignment in the
D
>From discussion on IRC, tile_type should be 1 for depth or stencil textures.
On Evergreen, it should also be 1 for some color buffers, but that's handled
in the evergreen_cb function when required.
Signed-off-by: Simon Farnsworth
---
Doesn't fix my tiled scanout fun, but
It's unclear exactly what the alignment requirements are for Radeon tiled
surfaces, but they differ between the DDX and Mesa. Make Mesa match the DDX.
Signed-off-by: Simon Farnsworth
---
This basically copies across the DDX versions of the restrictions. They
differ, and I'm not sure w
://bugs.freedesktop.org/show_bug.cgi?id=41263
Signed-off-by: Simon Farnsworth
---
src/mesa/state_tracker/st_cb_fbo.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 05139ec..4d32158 100644
--- a/src
de like it's the format of the source buffer (the
system framebuffer) that matters, not the format of the destination buffer.
--
Thanks in advance for any advice you can offer,
Simon Farnsworth
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
h
21 matches
Mail list logo
