android-x86-mesa.git/src/gallium/drivers/r600/Makefile, branch r300

r600g: add back u_upload_mgr integration

2011-01-30T02:29:48Z

I can't see a performance difference with this code, which means all the driver-specific code removed in this commit was unnecessary. Now we use u_upload_mgr in a slightly different way than we did before it got dropped. I am not restoring the original code "as is" due to latest u_upload_mgr changes that r300g performance benefits from. This also fixes: - piglit/fp-kil

r600g: specialized upload manager

2010-12-09T21:07:05Z

Allow important performance increase by doing hw specific implementation of the upload manager helper. Drop the range flushing that is not hit with this code (and wasn't with previous neither). Performance improvement are mostly visible on slow CPU. Signed-off-by: Jerome Glisse

r600g: start splitting out common code from eg/r600.

2010-10-21T09:58:09Z

no point duplicating code that doesn't touch hw, also make it easier to spot mistakes

r600g: more cleanup

2010-09-29T19:40:32Z

Signed-off-by: Jerome Glisse

r600g: cleanup

2010-09-29T19:06:04Z

Signed-off-by: Jerome Glisse

r600g: delete old path

2010-09-29T18:28:48Z

Lot of clean can now happen. Signed-off-by: Jerome Glisse

r600g: initial evergreen support in new path

2010-09-23T21:10:28Z

This doesn't work yet. Signed-off-by: Jerome Glisse

r600g: alternative command stream building from context

2010-09-17T14:49:05Z

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

r600g: add initial evergreen support

2010-09-10T09:41:18Z

adds shader opcodes + assembler support (except ARL) uses constant buffers add interp instructions in fragment shader adds all evergreen hw states adds evergreen pm4 support. this runs gears for me on my evergreen

r600g: abstract the hw states out behind a vtbl.

2010-09-07T22:30:59Z

this is step one towards evergreen support, it lets us plug in whole new hw level states.