| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
On my rv530 at least HiZ is causing rendering issues in gears.
|
|
This implements fast Z clear, Z compression, and HiZ support for r300->r500
GPUs.
It also allows cbzb clears when fast Z clears are being used for the ZB.
It requires a kernel with hyper-z support.
Thanks to Marek Olšák <maraeo@gmail.com>, who started this off, and Alex Deucher at AMD for providing lots of hints.
v2:
squashed zmask ram size fix]
squashed r300g/blitter: fix Z readback when compressed]
v3:
rebase around texture changes in master - .1 fix more bits
v4:
migrated to using u_mm in r300_texture to manage hiz/zmask rams consistently
disabled HiZ when using OQ
flush z-cache before turning hyper-z off
update hyper-z state on dsa state change
store depthclearvalue across cbzb clears and replace it afterwards.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The BGNLOOP and ENDLOOP instructions are now being used correctly, which
makes break and continue possible. The deadcode pass has been modified to
handle breaks, and the compiler is more careful about which loops are
unrolled.
|
|
This stops us advertising lots of ms visuals we can't actually use.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=29372
|
|
If texture coordinates come from the vertex shader, there are always
4 components in the rasterizer input packet, but if the coordinates
are stuffed (like for point sprites), there are only 2 or 3 components
(based on GB_ENABLE) and if we rasterize more, it locks up.
|
|
Getting tiling right has always been tricky.
There are so many subtle details...
|
|
The Draw flush inside r300_flush was the culprit.
Also, no need to flush Draw when changing a state since the flush is
already inside swtcl_draw_vbo.
|
|
|
|
This fixes fdo bug #29286.
|
|
That is, remove pipe_context::draw_arrays, pipe_context::draw_elements,
pipe_context::draw_arrays_instanced,
pipe_context::draw_elements_instanced,
pipe_context::draw_range_elements.
|
|
Some drivers define a generic function that is called by all drawing
functions. To implement draw_vbo for such drivers, either draw_vbo
calls the generic function or the prototype of the generic function is
changed to match draw_vbo.
Other drivers have no such generic function. draw_vbo is implemented by
calling either draw_arrays and draw_elements.
For most drivers, set_index_buffer does not mark the state dirty for
tracking. Instead, the index buffer state is emitted whenever draw_vbo
is called, just like the case with draw_elements. It surely can be
improved.
|
|
isn't a problem yet, but have issues in hiz branch.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Because the hw can't sample it, I reinterpret the format as G16R16 and
sample the G component. This gives 16 bits of precision, which should be
enough for depth texturing (surprisingly, the sampled values are exactly
the same as in D16 textures).
This also enables EXT_packed_depth_stencil on those old chipsets, finally.
|
|
The number of macrotiles in the Y direction must be even, otherwise memory
corruption may happen (e.g. broken fonts). Basically, if we get a buffer
in resource_from_handle, we can determine from the buffer size whether it's
safe to use the CBZB clear or not.
|
|
|
|
We were using TXPITCH_EN for textures from the DDX since ever, for nothing.
|
|
This decouples initializing a texture layout/miptree description
from an actual texture creation, it also partially unifies texture_create
and texture_from_handle.
r300_texture inherits r300_texture_desc, which inherits u_resource.
The CBZB clear criteria are moved to r300_texture_desc::cbzb_allowed[level].
And other minor cleanups.
|
|
The driver gets a buffer and its size in resource_from_handle.
It computes the required minimum buffer size from given texture
properties, and compares the two sizes.
This is to early detect DDX bugs.
|
|
|
|
I don't remember why the alignment was there, but it seems to be
no longer needed. I guess it was a dirty fix for some other bug.
|
|
Depth clamping seems to be implicit if clipping is disabled.
It's not perfect, but it's good enough for wine and passes
the corresponding piglit tests.
|
|
|
|
The problem is destroy_context is almost NEVER called.
The only test for destroy_context I know is compiz.
Reported by Vinson Lee.
FDO bug #29150.
|
|
|
|
The improvement in Tremulous: 68.9 fps -> 71.1 fps.
|
|
fix vb/ib uploads
|
|
|
|
Ooops.
|
|
FDO bug #29128.
|
|
|
|
|
|
|
|
|
|
rv3x0 can't do it.
|
|
|
|
|
|
It is a lot simplier, cleaner, and more stable now.
|
|
|
|
An initial implementation made by Dave Airlie.
For it to be used, a color-only clear must be invoked and exactly one
point-sampled render target must be set. The render target must be
macrotiled (for us to overcome alignment issues) and bpp must be either
16 or 32.
I can't see a difference in performance. :(
Conflicts:
src/gallium/drivers/r300/r300_blit.c
|
|
With an ordinary quad, the pixels on the main diagonal are computed
and stored twice, which is somewhat inefficient and might not work well
with specialized clear codepaths.
|
|
And other minor fixups.
|
|
FDO bug #28563.
|
|
This fixes sluggishness in vdrift.
|
|
This is a typo fix, the generated code should be the same.
|
