| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Quickly tested with VMWare Workstation 7.1.4 on Linux with GeForce
GT220. SurfaceFlinger (the display server and compositor) works. 2D
apps with RGB visual works. However, due to missing
PIPE_FORMAT_R8G8B8A8_UNORM support, those with RGBA visual do not.
|
|
|
|
|
| |
Factor out C_SOURCES from Makefile to Makefile.sources, and let Makefile
and SConscript share it.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/state_tracker/st_atom_pixeltransfer.c
src/mesa/state_tracker/st_program.c
|
| | |
|
| |
| |
| |
| |
| |
| | |
Instead of always using the first element's size.
This fixes flashing floor on CINEBENCH R10.
|
| |
| |
| |
| |
| |
| |
| |
| | |
If a user-buffer was referenced twice by a draw command, the affected ranges
were uploaded separately, with only the last one being referenced by the
hardware. Make sure we upload only a single range.
Signed-off-by: Thomas Hellstrom <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| | |
We currently always treat contents of user-buffers as volatile so
we don't need to take any particular action when the state tracker
announces that the contents has changed.
Signed-off-by: Thomas Hellstrom <[email protected]>
|
| |
| |
| |
| | |
See preceeding commit for more info.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Viewperf uses some unusual vertex arrays where the stride is less
than the element size. In this case, the stride was 4 while the
element size was 12. The difference of 8 bytes causes us to miss
uploading the tail bit of the array data.
Typically the stride is >= the element size so there was no problem
with other apps.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Stream user buffer contents rather than trying to maintain persistent
host / hardware copies.
Resulting negative array offsets are not allowed by the hardware,
(well, at least not according to header files), so adjust index bias
to make all array offsets positive.
Signed-off-by: Thomas Hellstrom <[email protected]>
|
| |
| |
| |
| |
| |
| | |
This enables us to pack more data into single upload buffers.
Signed-off-by: Thomas Hellstrom <[email protected]>
|
|/
|
|
|
| |
Also, only flush when going from HW TNL to SW TNL, given it is impossible
for the buffers resulting from SWTNL to be ever referred by HW TNL path.
|
| |
|
|
|
|
| |
User-defined clip planes were a swtnl fallback before.
|
|
|
|
|
| |
This is safe because it's initialized if buffers & PIPE_CLEAR_COLOR and
probably doesn't have any effect otherwise.
|
|
|
|
|
|
| |
Just to keep drivers working.
Reviewed-by: Jakob Bornecrantz <[email protected]>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The earlier change to ensure rendertargets and textures are always
rebound at every command buffer start had the downside of making
successive flushes no longer no-ops, as a command buffer with merely
the rebinding commands were being unnecessarily sent to the vGPU.
This change only re-emits the bindings when necessary, by keeping track
of the need to rebind outside of the dirty state update mechanism.
|
| |
|
| |
|
|
|
|
| |
Fixes minor sub-pixel positioning error in some apps.
|
| |
|
|
|
|
|
|
|
| |
Move this to the winsys, given it is not a virtual device limitation,
but a limitation specific to certain winsyses.
Also update debug message.
|
|
|
|
|
| |
It is pointless to change, now that we don't replace user vertex buffer
with uploaded copy, per commit 52e598d200108ab9cfc9c9d828bbebdc576e9703.
|
|
|
|
|
|
|
|
| |
The code no longer supports otherwise -- it relies on buffers being
uploaded via u_upload_mgr -- so make this clear.
Also, there's no need to flush after draws from user buffers, given all
user content should have been copied by then.
|
|
|
|
|
|
|
|
| |
Should prevent the assert failure
svga_buffer_flush_mapped_range: Assertion `sbuf->map.writing' failed.
on nested transfers.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The drivers have been changed so that they behave as if all of the flags
were set. This is already implicit in most hardware drivers and required
for multiple contexts.
Some state trackers were also abusing the PIPE_FLUSH_RENDER_CACHE flag
to decide whether flush_frontbuffer should be called.
New flag ST_FLUSH_FRONT has been added to st_api.h as a replacement.
|
| |
|
|
|
|
| |
So that they don't have the driver-specific param and return type.
|
|
|
|
| |
Only st/xorg used it and even incorrectly with regards to pipelined transfers.
|
|
|
|
| |
DMAs.
|
|
|
|
|
|
|
|
| |
This reverts commit 6d4e337f3890105c7d8a2f132412c137d2570d25.
The commit is incorrect. I'll rework it. Revert for now.
Signed-off-by: Thomas Hellstrom <[email protected]>
|
|
|
|
|
|
|
| |
Make sure we only upload parts of vertex arrays that are actually used
by a draw command.
Signed-off-by: Thomas Hellstrom <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Do that later on when we set up the hwtnl state instead.
This addresses a problem when we drop the uploaded copy due to a vb
size change, it will remain referenced in svga->curr.vb[], and the
new contents of the vb will never be uploaded.
Signed-off-by: Thomas Hellstrom <[email protected]>
|
|
|
|
|
| |
This is a follow-up to the ARB_sync patch for st/mesa and completes
the ARB_sync implementation.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
buffer start.
The svga_update_state() mechanism is inadequate as it will always end up
flushing the primitives before processing the SVGA_NEW_COMMAND_BUFFER
dirty state flag.
|
| |
|
|
|
|
| |
Probably introduced with the surface view move from screen to context.
|
|
|
|
|
|
|
|
|
| |
before DMAs.
This behavior was last when moving the transfers to the contexts.
This fixes several piglit failures, which were reading the color renderbuffer
before the draw operations were emitted.
|
| |
|