| Age | Commit message (Collapse) | Author |
|---|
|
|
|
front/back-face changes)
|
|
|
|
Only set front material colors to make it noticable if front/back-face
determination is incorrect anywhere.
|
|
|
|
Fixes a crash when buffer objects are left around until context destroy.
|
|
This fixes a crash when stippling using data from a PBO.
|
|
The diffuse color format is always ARGB32, regardless of the destination
surface format.
|
|
|
|
mipmap pitches must account for the device alignment requirements, which
used to be fairly simple; just align to a 4-byte boundary. However, to allow
textures to be drawn to under TTM, they now need to be aligned to a 64-byte
boundary. Placing all of the alignment constraints in a single function
allows this new constraint to be applied uniformly.
There was some pitch constraining code in intel_miptree_create, but that was
modifying the pitch long after the miptree had been layed out, so it only
served to wreck the mipmap and cause rendering errors.
|
|
|
|
|
|
|
|
|
|
With FBOs, we end up wanting to do 3D metaops against one or the other without
having to find the other one to fill in if we're not going to draw to it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Don't dereference NULL renderbuffer pointer, and make sure the software
fallback sticks.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=13694 .
|
|
|
|
|
|
|
|
While I haven't tested the imaging extension, this matches what 915 does.
|
|
This removes the delayed texture upload optimization from 965, in exchange for
bringing us closer to PBO support. It also disables SGIS_generate_mipmap,
which didn't seem to be working before anyway, according to the lodbias demo.
|
|
|
|
965 gains fixed TTM typing of the buffer object buffers and unused PBO
functions, and 915 gains buffer size == 0 fixes from 965.
|
|
This adds (so far) unused PBO functions, and holding the lock while writing
to regions (which may be shared static screen regions).
|
|
|
|
|
|
|
|
The idling it was trying to ensure was covered by the
intel_miptree_image_map()->intel_region_map() that immediately followed it.
|
|
|
|
|
|
|
|
Each buffer object now has a relocation buffer pointer, which contains the
relocations for the buffer if there are any. At the point where we have to
create a new type of relocation entry, we can change the code over to allowing
multiple relocation lists, but trying to anticipate what that'll look like
now just increases complexity.
This is a 30% performance improvement on 965.
|
|
The user-space suballocator that was used avoided relocation computations by
using the general and surface state base registers and allocating those types
of buffers out of pools built on top of single buffer objects. It also
avoided calls into the buffer manager for these small state allocations, since
only one buffer object was being used.
However, the buffer allocation cost appears to be low, and with relocation
caching, computing relocations for buffers is essentially free. Additionally,
implementing the suballocator required a don't-fence-subdata flag to disable
waiting on buffer maps so that writing new data didn't block on rendering using
old data, and careful handling when mapping to update old data (which we need
to do for unavoidable relocations with FBOs). More importantly, when the
suballocator filled, it had no replacement algorithm and just threw out all
of the contents and forced them to be recomputed, which is a significant cost.
This is the first step, which just changes the buffer type, but doesn't yet
improve the hash table to not result in full recompute on overflow. Because
the buffers are all allocated out of the general buffer allocator, we can
no longer use the general/surface state bases to avoid relocations, and they
are set to 0 instead.
|
|
Now that the dri_bufmgr is stored in the context rather than the screen, all
access to one is single-threaded anyway.
|
|
|
|
bufmgr_fake doesn't care about it, but with ttm we would end up with the
buffer remaining referenced until application exit.
|
|
|
|
I broke this with cherry-pick resolving on
93c98a466947570e0589b662df49095b2f4bc43c.
|
|
Putting the bufmgr in the screen is not thread-safe since the emit_reloc
changes. It also led to a significant performance hit from pthread usage
for the attempted thread-safety (up to 12% of a cpu spent on refcounting
protection in single-threaded 965). The motivation had been to allow
multi-context bufmgr sharing in classic mode, but it wasn't worth the cost.
|
|
|
|
This takes advantage of the DRM_BO_HINT_PRESUMED_OFFSET change and allows
the kernel to avoid mapping and re-writing buffers when relocations occur.
|
|
|
|
|
|
|
