gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
/**************************************************************************
|
|
|
|
*
|
|
|
|
* Copyright 2007 Tungsten Graphics, Inc., Cedar Park, Texas.
|
|
|
|
* All Rights Reserved.
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the
|
|
|
|
* "Software"), to deal in the Software without restriction, including
|
|
|
|
* without limitation the rights to use, copy, modify, merge, publish,
|
|
|
|
* distribute, sub license, and/or sell copies of the Software, and to
|
|
|
|
* permit persons to whom the Software is furnished to do so, subject to
|
|
|
|
* the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the
|
|
|
|
* next paragraph) shall be included in all copies or substantial portions
|
|
|
|
* of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
|
|
|
|
* OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
|
|
|
|
* IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
|
|
|
|
* ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
|
|
|
|
* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
|
|
|
|
* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
*
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Authors:
|
|
|
|
* Keith Whitwell <keith@tungstengraphics.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "draw/draw_context.h"
|
|
|
|
#include "draw/draw_private.h"
|
|
|
|
#include "draw/draw_pt.h"
|
2008-11-05 15:58:40 +00:00
|
|
|
#include "tgsi/tgsi_dump.h"
|
2008-11-12 16:03:58 +00:00
|
|
|
#include "util/u_math.h"
|
2009-06-19 16:45:23 +01:00
|
|
|
#include "util/u_prim.h"
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
|
2008-05-30 14:51:09 +01:00
|
|
|
static unsigned trim( unsigned count, unsigned first, unsigned incr )
|
|
|
|
{
|
2008-07-04 16:59:43 +01:00
|
|
|
if (count < first)
|
|
|
|
return 0;
|
2008-05-30 14:51:09 +01:00
|
|
|
return count - (count - first) % incr;
|
|
|
|
}
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-16 10:03:18 +01:00
|
|
|
/* Overall we split things into:
|
|
|
|
* - frontend -- prepare fetch_elts, draw_elts - eg vcache
|
|
|
|
* - middle -- fetch, shade, cliptest, viewport
|
|
|
|
* - pipeline -- the prim pipeline: clipping, wide lines, etc
|
|
|
|
* - backend -- the vbuf_render provided by the driver.
|
|
|
|
*/
|
2008-04-19 13:20:26 +01:00
|
|
|
static boolean
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
draw_pt_arrays(struct draw_context *draw,
|
|
|
|
unsigned prim,
|
|
|
|
unsigned start,
|
|
|
|
unsigned count)
|
|
|
|
{
|
|
|
|
struct draw_pt_front_end *frontend = NULL;
|
|
|
|
struct draw_pt_middle_end *middle = NULL;
|
2008-04-16 10:03:18 +01:00
|
|
|
unsigned opt = 0;
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
|
2008-05-30 14:51:09 +01:00
|
|
|
/* Sanitize primitive length:
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
unsigned first, incr;
|
|
|
|
draw_pt_split_prim(prim, &first, &incr);
|
|
|
|
count = trim(count, first, incr);
|
|
|
|
if (count < first)
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2008-10-06 12:22:55 +01:00
|
|
|
if (!draw->force_passthrough) {
|
|
|
|
if (!draw->render) {
|
|
|
|
opt |= PT_PIPELINE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (draw_need_pipeline(draw,
|
|
|
|
draw->rasterizer,
|
|
|
|
prim)) {
|
|
|
|
opt |= PT_PIPELINE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!draw->bypass_clipping && !draw->pt.test_fse) {
|
|
|
|
opt |= PT_CLIPTEST;
|
|
|
|
}
|
|
|
|
|
2010-02-22 20:36:22 +00:00
|
|
|
opt |= PT_SHADE;
|
2008-04-16 10:03:18 +01:00
|
|
|
}
|
2008-10-06 12:22:55 +01:00
|
|
|
|
2008-05-12 15:20:38 +01:00
|
|
|
if (opt == 0)
|
2008-04-19 13:20:26 +01:00
|
|
|
middle = draw->pt.middle.fetch_emit;
|
2008-05-29 14:35:30 +01:00
|
|
|
else if (opt == PT_SHADE && !draw->pt.no_fse)
|
2008-05-12 19:40:20 +01:00
|
|
|
middle = draw->pt.middle.fetch_shade_emit;
|
2008-05-12 15:20:38 +01:00
|
|
|
else
|
|
|
|
middle = draw->pt.middle.general;
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
|
2008-04-16 10:03:18 +01:00
|
|
|
|
2008-04-24 21:22:47 +01:00
|
|
|
/* Pick the right frontend
|
2008-04-16 10:03:18 +01:00
|
|
|
*/
|
2008-05-12 17:36:35 +01:00
|
|
|
if (draw->pt.user.elts || (opt & PT_PIPELINE)) {
|
2008-04-24 21:22:47 +01:00
|
|
|
frontend = draw->pt.front.vcache;
|
|
|
|
} else {
|
|
|
|
frontend = draw->pt.front.varray;
|
|
|
|
}
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
|
2008-04-16 10:03:18 +01:00
|
|
|
frontend->prepare( frontend, prim, middle, opt );
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
|
2008-04-25 14:10:32 +01:00
|
|
|
frontend->run(frontend,
|
|
|
|
draw_pt_elt_func(draw),
|
|
|
|
draw_pt_elt_ptr(draw, start),
|
|
|
|
count);
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
|
|
|
|
frontend->finish( frontend );
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
boolean draw_pt_init( struct draw_context *draw )
|
|
|
|
{
|
2008-06-10 00:32:52 +01:00
|
|
|
draw->pt.test_fse = debug_get_bool_option("DRAW_FSE", FALSE);
|
|
|
|
draw->pt.no_fse = debug_get_bool_option("DRAW_NO_FSE", FALSE);
|
2008-05-12 19:40:20 +01:00
|
|
|
|
2008-04-16 10:03:18 +01:00
|
|
|
draw->pt.front.vcache = draw_pt_vcache( draw );
|
|
|
|
if (!draw->pt.front.vcache)
|
2008-04-03 12:21:30 +01:00
|
|
|
return FALSE;
|
|
|
|
|
2008-04-24 21:22:47 +01:00
|
|
|
draw->pt.front.varray = draw_pt_varray(draw);
|
|
|
|
if (!draw->pt.front.varray)
|
|
|
|
return FALSE;
|
|
|
|
|
2008-04-19 13:20:26 +01:00
|
|
|
draw->pt.middle.fetch_emit = draw_pt_fetch_emit( draw );
|
|
|
|
if (!draw->pt.middle.fetch_emit)
|
|
|
|
return FALSE;
|
2008-04-13 06:47:07 +01:00
|
|
|
|
2008-05-28 23:54:18 +01:00
|
|
|
draw->pt.middle.fetch_shade_emit = draw_pt_middle_fse( draw );
|
|
|
|
if (!draw->pt.middle.fetch_shade_emit)
|
|
|
|
return FALSE;
|
2008-05-12 15:20:38 +01:00
|
|
|
|
2010-02-23 03:02:58 +00:00
|
|
|
draw->pt.middle.general = draw_pt_fetch_pipeline_or_emit_llvm( draw );
|
|
|
|
if (!draw->pt.middle.general)
|
|
|
|
draw->pt.middle.general = draw_pt_fetch_pipeline_or_emit( draw );
|
2008-04-19 13:20:26 +01:00
|
|
|
if (!draw->pt.middle.general)
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void draw_pt_destroy( struct draw_context *draw )
|
|
|
|
{
|
2008-04-19 13:20:26 +01:00
|
|
|
if (draw->pt.middle.general) {
|
|
|
|
draw->pt.middle.general->destroy( draw->pt.middle.general );
|
|
|
|
draw->pt.middle.general = NULL;
|
|
|
|
}
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
|
2008-04-19 13:20:26 +01:00
|
|
|
if (draw->pt.middle.fetch_emit) {
|
|
|
|
draw->pt.middle.fetch_emit->destroy( draw->pt.middle.fetch_emit );
|
|
|
|
draw->pt.middle.fetch_emit = NULL;
|
|
|
|
}
|
2008-04-13 06:47:07 +01:00
|
|
|
|
2008-05-12 19:40:20 +01:00
|
|
|
if (draw->pt.middle.fetch_shade_emit) {
|
|
|
|
draw->pt.middle.fetch_shade_emit->destroy( draw->pt.middle.fetch_shade_emit );
|
|
|
|
draw->pt.middle.fetch_shade_emit = NULL;
|
|
|
|
}
|
|
|
|
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
if (draw->pt.front.vcache) {
|
|
|
|
draw->pt.front.vcache->destroy( draw->pt.front.vcache );
|
|
|
|
draw->pt.front.vcache = NULL;
|
|
|
|
}
|
2008-04-24 21:22:47 +01:00
|
|
|
|
|
|
|
if (draw->pt.front.varray) {
|
|
|
|
draw->pt.front.varray->destroy( draw->pt.front.varray );
|
|
|
|
draw->pt.front.varray = NULL;
|
|
|
|
}
|
gallium: beginnings of draw module vertex rework
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
2008-03-23 16:44:59 +00:00
|
|
|
}
|
2008-04-18 20:36:38 +01:00
|
|
|
|
|
|
|
|
2008-11-06 21:57:20 +00:00
|
|
|
/**
|
|
|
|
* Debug- print the first 'count' vertices.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
draw_print_arrays(struct draw_context *draw, uint prim, int start, uint count)
|
|
|
|
{
|
|
|
|
uint i;
|
|
|
|
|
|
|
|
debug_printf("Draw arrays(prim = %u, start = %u, count = %u)\n",
|
|
|
|
prim, start, count);
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
2009-11-21 00:03:48 +00:00
|
|
|
uint ii = 0;
|
|
|
|
uint j;
|
2008-11-06 21:57:20 +00:00
|
|
|
|
|
|
|
if (draw->pt.user.elts) {
|
|
|
|
/* indexed arrays */
|
|
|
|
switch (draw->pt.user.eltSize) {
|
|
|
|
case 1:
|
|
|
|
{
|
|
|
|
const ubyte *elem = (const ubyte *) draw->pt.user.elts;
|
|
|
|
ii = elem[start + i];
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
{
|
|
|
|
const ushort *elem = (const ushort *) draw->pt.user.elts;
|
|
|
|
ii = elem[start + i];
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
{
|
|
|
|
const uint *elem = (const uint *) draw->pt.user.elts;
|
|
|
|
ii = elem[start + i];
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
assert(0);
|
|
|
|
}
|
|
|
|
debug_printf("Element[%u + %u] -> Vertex %u:\n", start, i, ii);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* non-indexed arrays */
|
|
|
|
ii = start + i;
|
|
|
|
debug_printf("Vertex %u:\n", ii);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 0; j < draw->pt.nr_vertex_elements; j++) {
|
|
|
|
uint buf = draw->pt.vertex_element[j].vertex_buffer_index;
|
|
|
|
ubyte *ptr = (ubyte *) draw->pt.user.vbuffer[buf];
|
2009-01-26 18:45:45 +00:00
|
|
|
ptr += draw->pt.vertex_buffer[buf].stride * ii;
|
2008-11-06 21:57:20 +00:00
|
|
|
ptr += draw->pt.vertex_element[j].src_offset;
|
|
|
|
|
|
|
|
debug_printf(" Attr %u: ", j);
|
|
|
|
switch (draw->pt.vertex_element[j].src_format) {
|
|
|
|
case PIPE_FORMAT_R32_FLOAT:
|
|
|
|
{
|
|
|
|
float *v = (float *) ptr;
|
|
|
|
debug_printf("%f @ %p\n", v[0], (void *) v);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case PIPE_FORMAT_R32G32_FLOAT:
|
|
|
|
{
|
|
|
|
float *v = (float *) ptr;
|
|
|
|
debug_printf("%f %f @ %p\n", v[0], v[1], (void *) v);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case PIPE_FORMAT_R32G32B32_FLOAT:
|
|
|
|
{
|
|
|
|
float *v = (float *) ptr;
|
|
|
|
debug_printf("%f %f %f @ %p\n", v[0], v[1], v[2], (void *) v);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case PIPE_FORMAT_R32G32B32A32_FLOAT:
|
|
|
|
{
|
|
|
|
float *v = (float *) ptr;
|
|
|
|
debug_printf("%f %f %f %f @ %p\n", v[0], v[1], v[2], v[3],
|
|
|
|
(void *) v);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
debug_printf("other format (fix me)\n");
|
|
|
|
;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2008-04-18 20:36:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Draw vertex arrays
|
|
|
|
* This is the main entrypoint into the drawing module.
|
|
|
|
* \param prim one of PIPE_PRIM_x
|
|
|
|
* \param start index of first vertex to draw
|
|
|
|
* \param count number of vertices to draw
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
draw_arrays(struct draw_context *draw, unsigned prim,
|
|
|
|
unsigned start, unsigned count)
|
|
|
|
{
|
2009-12-30 17:54:04 +00:00
|
|
|
draw_arrays_instanced(draw, prim, start, count, 0, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
draw_arrays_instanced(struct draw_context *draw,
|
|
|
|
unsigned mode,
|
|
|
|
unsigned start,
|
|
|
|
unsigned count,
|
|
|
|
unsigned startInstance,
|
|
|
|
unsigned instanceCount)
|
|
|
|
{
|
|
|
|
unsigned reduced_prim = u_reduced_prim(mode);
|
|
|
|
unsigned instance;
|
|
|
|
|
2008-05-12 19:40:20 +01:00
|
|
|
if (reduced_prim != draw->reduced_prim) {
|
2009-12-30 17:54:04 +00:00
|
|
|
draw_do_flush(draw, DRAW_FLUSH_STATE_CHANGE);
|
2008-05-12 19:40:20 +01:00
|
|
|
draw->reduced_prim = reduced_prim;
|
2008-04-18 20:36:38 +01:00
|
|
|
}
|
|
|
|
|
2008-11-06 21:57:20 +00:00
|
|
|
if (0)
|
2009-12-30 17:54:04 +00:00
|
|
|
draw_print_arrays(draw, mode, start, MIN2(count, 20));
|
2008-11-06 21:57:20 +00:00
|
|
|
|
2008-11-05 15:58:40 +00:00
|
|
|
#if 0
|
|
|
|
{
|
|
|
|
int i;
|
2009-12-30 17:54:04 +00:00
|
|
|
debug_printf("draw_arrays(mode=%u start=%u count=%u):\n",
|
|
|
|
mode, start, count);
|
2008-11-05 15:58:40 +00:00
|
|
|
tgsi_dump(draw->vs.vertex_shader->state.tokens, 0);
|
|
|
|
debug_printf("Elements:\n");
|
|
|
|
for (i = 0; i < draw->pt.nr_vertex_elements; i++) {
|
2010-02-17 15:44:38 +00:00
|
|
|
debug_printf(" format=%s\n",
|
|
|
|
util_format_name(draw->pt.vertex_element[i].src_format));
|
2008-11-05 15:58:40 +00:00
|
|
|
}
|
|
|
|
debug_printf("Buffers:\n");
|
|
|
|
for (i = 0; i < draw->pt.nr_vertex_buffers; i++) {
|
2009-01-26 18:45:45 +00:00
|
|
|
debug_printf(" stride=%u offset=%u ptr=%p\n",
|
|
|
|
draw->pt.vertex_buffer[i].stride,
|
2008-11-05 15:58:40 +00:00
|
|
|
draw->pt.vertex_buffer[i].buffer_offset,
|
|
|
|
draw->pt.user.vbuffer[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2009-12-29 22:21:01 +00:00
|
|
|
for (instance = 0; instance < instanceCount; instance++) {
|
|
|
|
draw->instance_id = instance + startInstance;
|
|
|
|
draw_pt_arrays(draw, mode, start, count);
|
|
|
|
}
|
|
|
|
}
|