aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/winsys/r600/drm/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* r600g: move all files from winsys/r600 into drivers/r600Marek Olšák2011-09-301-15/+0
| | | | | | Be sure to reconfigure after this commit. Reviewed-by: Alex Deucher <[email protected]>
* r600g: cleanup build include dirs and dependenciesMarek Olšák2011-09-121-1/+0
| | | | The scons build still depended on libdrm_radeon.
* winsys/r600: share the source listChia-I Wu2011-08-251-6/+2
| | | | | | | Factor out C_SOURCES from Makefile to Makefile.sources, and let Makefile and SConscript share it. Reviewed-by: Marek Olšák <[email protected]>
* r600g: merge radeon_bo with r600_boMarek Olšák2011-08-161-1/+0
| | | | Reviewed-by: Alex Deucher <[email protected]>
* r600g: remove the cache buffer manager from winsys/r600Marek Olšák2011-08-161-2/+1
| | | | | | As we've just started using the one from winsys/radeon. Reviewed-by: Alex Deucher <[email protected]>
* r600g: remove unused codeMarek Olšák2011-08-021-1/+0
|
* r600g: Use radeon pciid list for the family lookup tableBenjamin Franzke2011-06-071-0/+1
| | | | Reviewed-by: Alex Deucher <[email protected]>
* r600g: r600_new() and r600_delete() are unused.Henri Verbeet2010-12-221-1/+0
|
* r600g: avoid using pb* helper we are loosing previous cpu cycle with itJerome Glisse2010-12-091-2/+2
| | | | | | | | | | | | r600g is up to a point where all small CPU cycle matter and pb* turn high on profile. It's mostly because pb try to be generic and thus trigger unecessary check for r600g driver. To avoid having too much abstraction & too much depth in the call embedded everythings into r600_bo. Make code simpler & faster. The performance win highly depend on the CPU & application considered being more important on slower CPU and marginal/unoticeable on faster one. Signed-off-by: Jerome Glisse <[email protected]>
* r600g: rename radeon_ws_bo to r600_boJerome Glisse2010-10-041-1/+1
| | | | Signed-off-by: Jerome Glisse <[email protected]>
* r600g: more cleanupJerome Glisse2010-09-291-5/+5
| | | | Signed-off-by: Jerome Glisse <[email protected]>
* r600g: delete old pathJerome Glisse2010-09-291-6/+1
| | | | | | Lot of clean can now happen. Signed-off-by: Jerome Glisse <[email protected]>
* r600g: initial evergreen support in new pathJerome Glisse2010-09-231-0/+1
| | | | | | This doesn't work yet. Signed-off-by: Jerome Glisse <[email protected]>
* r600g: alternative command stream building from contextJerome Glisse2010-09-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Winsys context build a list of register block a register block is a set of consecutive register that will be emited together in the same pm4 packet (the various r600_block* are there to provide basic grouping that try to take advantage of states that are linked together) Some consecutive register are emited each in a different block, for instance the various cb[0-7]_base. At winsys context creation, the list of block is created & an index into the list of block. So to find into which block a register is in you simply use the register offset and lookup the block index. Block are grouped together into group which are the various pkt3 group of config, context, resource, Pipe state build a list of register each state want to modify, beside register value it also give a register mask so only subpart of a register can be updated by a given pipe state (the oring is in the winsys) There is no prebuild register list or define for each pipe state. Once pipe state are built they are bound to the winsys context. Each of this functions will go through the list of register and will find into which block each reg falls and will update the value of the block with proper masking (vs/ps resource/constant are specialized variant with somewhat limited capabilities). Each block modified by r600_context_pipe_state_set* is marked as dirty and we update a count of dwords needed to emit all dirty state so far. r600_context_pipe_state_set* should be call only when pipe context change some of the state (thus when pipe bind state or set state) Then to draw primitive you make a call to r600_context_draw void r600_context_draw(struct r600_context *ctx, struct r600_draw *draw) It will check if there is enough dwords in current cs buffer and if not will flush. Once there is enough room it will copy packet from dirty block and then add the draw packet3 to initiate the draw. The flush will send the current cs, reset the count of dwords to 0 and remark all states that are enabled as dirty and recompute the number of dwords needed to send the current context. Signed-off-by: Jerome Glisse <[email protected]>
* r600g: add support for kernel boDave Airlie2010-09-171-1/+2
| | | | this moves to using a pb bufmgr instead of kernel bos directly.
* r600g: attempt to abstract kernel bos from pipe driver.Dave Airlie2010-09-171-1/+2
| | | | | | introduce an abstraction layer between kernel bos and the winsys BOs. this is to allow plugging in pb manager with minimal disruption to pipe driver.
* r600g: adapt to latest interfaces changesMarek Olšák2010-05-271-0/+23
- Wrapped the buffer and texture create/destroy/transfer/... functions using u_resource, which is then used to implement the resource functions. - Implemented texture transfers. I left the buffer and texture transfers separate because one day we'll need a special codepath for textures. - Added index_bias to the draw_*elements functions. - Removed nonexistent *REP and *FOR instructions. - Some pipe formats have changed channel ordering, so I've removed/fixed nonexistent ones. - Added stubs for create/set/destroy sampler views. - Added a naive implementation of vertex elements state (new CSO). - Reworked {texture,buffer}_{from,to}_handle. - Reorganized winsys files, removed dri,egl,python directories. - Added a new build target dri-r600.