| Age | Commit message (Collapse) | Author |
|---|
|
Avoids spamming compilation output with tons of warnings about
use of possibly uninitialized variables.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The 965 path wasn't setting pClipRects for batch submission since it didn't
want kernel cliprect handling before. The 915 path also grew the INTEL_NO_HW=1
option for testing just driver overhead.
|
|
The previous COS function failed badly outside of [-pi/2, pi/2].
|
|
This is described in the link in the comment, and is the same technique that
r300 uses.
|
|
The Taylor series notably fails at producing sin(pi) == 0, which leads to
discontinuity every 2*pi. The quadratic gets us sin(pi) == 0 behavior, at the
expense of going from 2.4% THD with working Taylor series to 3.8% THD (easily
seen on comparative graphs of the two). However, our previous implementation
was producing sin(pi) < -1 and worse, so any reasonable approximation is an
improvement. This also fixes the repeating behavior, where the previous
implementation would repeat sin(x) for x>pi as sin(x % pi) and the opposite
for x < -pi.
|
|
The screen wide info such as pitch and cpp are obsoleted by the FBO
changes, so clean up the last few references to those, except for
setting up the legacy screen regions.
|
|
|
|
The fix for pageflipping with cliprects ended up causing a batch flush at
an inopportune time, which is fixed by moving it up.
Additionally, the recovery code for handling batch wraps at bad times is
replaced by just checking for the space up front, and using a no_batch_wrap
assert like on 965 to make sure that we weren't wrong about how much space that
was.
|
|
|
|
The previous change gave us only two modes, one which looped over the batch
per cliprect (3d drawing) and one that didn't (state updeast).
However, we really want 4:
- Batch doesn't care about cliprects (state updates)
- Batch needs DRAWING_RECTANGLE looping per cliprect (3d drawing)
- Batch needs to be executed just once (region fills, copies, etc.)
- Batch already includes cliprect handling, and must be flushed by unlock time
(copybuffers, clears).
All callers should now be fixed to use one of these states for any batchbuffer
emits. Thanks to Keith Whitwell for pointing out the failure.
|
|
Drop a bunch of unused arguments from intel_create_renderbuffer() and
introduce intel_renderbuffer_set_region() to set the region for
a renderbuffer.
|
|
Both drivers have ended up relying on lost_hardware being called after each
batch buffer, so update the name. This removes one of the calls on 965 whic
h was outside of the batchbuffer handling code and just duplicating what had
already happened through batchbuffer handling.
|
|
In particular, batch buffers are no longer flushed when switching from
CLIPRECTS to NO_CLIPRECTS or vice versa, and 965 just uses DRM cliprect
handling for primitives instead of trying to sneak in its own to avoid the
DRM stuff. The disadvantage is that we will re-execute state updates per
cliprect, but the advantage is that we will be able to accumulate larger
batch buffers, which were proving to be a major overhead.
|
|
|
|
|
|
Each array element is now a BUFFER_x token rather than a BUFFER_BIT_x bitmask.
The number of active color buffers is specified by _NumColorDrawBuffers.
This builds on the previous DrawBuffer changes and will help with drivers
implementing GL_ARB_draw_buffers.
|
|
These fields are no longer indexed by shader output. Now, we just have
a simple array of renderbuffer pointers.
If the shader writes to gl_FragData[i], send those colors to the N
_ColorDrawBuffers. Otherwise, replicate the single gl_FragColor (or
the fixed-function color) to the N _ColorDrawBuffers.
A few more changes and simplifications can follow from this...
|
|
rendering. fix #12786
|
|
MRD computation is now changed in mesa core
|
|
|
|
fix #11925
|
|
primitive needs to include the begin/end flags (broken since vbo-0.2). Should
fix missing first/last line segment on gamma, i810, i915, mga, r200, radeon,
s3v, savage, unichrome (r300 already correct). Tested on r200, fixes #13527.
|
|
|
|
|
|
The core problem was that _mesa_generate_mipmap was not respecting RowStride
of the source image. Additionally, the intel private data associated with the
images (level and face) was not being initialized for the
_mesa_generate_mipmap-generated images.
|
|
|
|
|
|
Fixes a crash when buffer objects are left around until context destroy.
|
|
This fixes a crash when stippling using data from a PBO.
|
|
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.
|
|
|
|
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 is currently believed to work but be a significant performance loss.
Performance recovery should be soon to follow.
The dri_bo_fake_disable_backing_store() call was added to allow backing store
disable like bufmgr_fake.c did, which is a significant performance win (though
it's missing the no-fence-subdata part).
This commit is a squash merge of the 965-ttm branch, which had some history
I wanted to avoid pulling due to noisiness and brokenness at many points
for git-bisecting.
|
|
|
|
|
|
|
|
|
|
This could lead to incorrect rendering or even lockups.
|
|
|
|
This requires that regions grow a marker of whether they are tiled or not,
because fence (surface) registers are ignored by the 965 2D engine.
|
|
|
|
|
|
|
|
The lock coverage and checks for cliprects were unneeded since the batchbuffer
will have INTEL_BATCH_CLIPRECTS anyway. It appeared to be a leftover from
intelClearWithBlit.
This makes the locking requirements of i915 meta_draw_quad match i965
meta_draw_quad.
|
