This lets us replace the current inner drawing loop of mesa:
for each prim {
compute bo list
if (check_aperture_space(bo list)) {
batch_flush()
compute bo list
if (check_aperture_space(bo list)) {
whine_about_batch_size()
fall back;
}
}
upload state to BOs
}
with this inner loop:
for each prim {
retry:
upload state to BOs
if (check_aperture_space(batch)) {
if (!retried) {
reset_to_last_prim()
batch_flush()
} else {
if (batch_flush())
whine_about_batch_size()
goto retry;
}
}
}
This avoids having to implement code to walk over certain sets of GL
state twice (the "compute bo list" step). While it's not a
performance improvement, it's a significant win in code complexity:
about -200 lines, and one place to make mistakes related to aperture
space instead of N places to forget some BO we should have included.
Note how if we do a reset in the new loop , we immediately flush. We
don't need to check aperture space -- the kernel will tell us if we
actually ran out of aperture or not. And if we did run out of
aperture, it's because either the single prim was too big, or because
check_aperture was wrong at the point of setting up the last
primitive.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few of the bitfield-based booleans are left in place. Changing them
to "bool" results in the same code size, so I'm erring on the side of
not changing things.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's more compatible; at least the Intel driver now rejects 32 bit
depths since it generally can't support real 32 bit framebuffers
(supports 30, 36, and 64 bit, but not 32).
To enable usage of xf86drm.h from C++ programs/frameworks.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
[ickle: also wrap xf86drmMode.h]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both drmIoctl and ioctl define second argument as unigned long.
Debugging/tracing tools (like strace or valgrind) on 64-bit machines see
different request value for ioctls with 32nd bit set, because casting
signed int to unsigned long extends 32nd bit to upper word, so 0x80000000
becomes 0xFFFFFFFF80000000)
Nobody noticed because higher 32 bits are chopped off on their way to kernel.
Hi Alex,
Enclosed is a revised version of the patch sent on Mar 18, against
the master branch of the drm userspace (i.e. libdrm). Details
summarised in this thread:
http://lists.freedesktop.org/archives/dri-devel/2011-March/009499.html
This patch reconciles libdrm with the the kernel change that Dave
pushed this morning. It *supersedes* the previously sent patch (i.e.
apply it to the master branch as it exists at the time of this writing,
not as an incremental patch to the one sent previously).
Regards,
Ilija
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
This is Fail.
First patch to libdrm, and I've borked it up.
Noticed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... and if asked to open a bo by the same global name, return a fresh
reference to the previously allocated buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The nvc0 gallium drivers passes NULL here to indicate to the memory manager
that a buffer is being used, but without creating an actual reloc.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Eric Anholt
Dave Airlie
Jakob Bornecrantz
Jesse Barnes
Tapani Pälli
Daniel Vetter
Matt Turner
Marcin Slusarz
Ben Widawsky
Yuanhan Liu
Chih-Wei Huang
Chris Wilson
Ilija Hadzic
Javier Jardón
Ben Skeggs
Kristian Høgsberg
Benjamin Franzke
nobled