On Sat, Apr 05, 2003 at 07:37:13AM +0100, Keith Whitwell wrote:
José Fonseca wrote:
For now I'll be also plugging in the C++ classes into into the existent
TL code, but in the future I may want to change the way the software
TL interfaces with the [hardware] rasterizers, since the current
José Fonseca wrote:
On Fri, Apr 04, 2003 at 08:48:35AM -0700, Brian Paul wrote:
In general, this sounds reasonable but you also have to consider
performance.
The glVertex, Color, TexCoord, etc commands have to be simple and fast. As
it is now, glColor4f (for example) (when implemented in X86
On Fri, Apr 04, 2003 at 10:23:21PM +0100, Keith Whitwell wrote:
The optimization of the vertex api has yeilded huge improvements. Even
with the runtime-codegenerated versions of these functions in the
radeon/r200 driver, they *still* dominate viewperf profile runs - meaning
that *all
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
Right now people use things like Viewperf to make systems purchase
decisions. Unless the graphics hardware and the rest of the system are
very mismatched, the immediate API already has an impact on performance
On Fri, Apr 04, 2003 at 05:14:54PM -0700, Brian Paul wrote:
José Fonseca wrote:
The things I found more interesting in the issue of applting the TCL
operations on all the vertices at once, or a vertice at each time. From
previous discussions on this list it seems that nowadays most
of CPU
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
In principle, I think the producer/consumer idea is good. Why not
implement known optimizations in it from the start? We already having
*working code* to build formated vertex data (see the radeon r200
On Fri, Apr 04, 2003 at 05:13:44PM -0800, Ian Romanick wrote:
Realistically, either hardware or software uses either
array-of-strctures or structure-of-arrays. Most hardware uses the
former. At that point it becomes a matter of, for a given state vector,
what's the offset in the structure
On Fri, Apr 04, 2003 at 05:13:44PM -0800, Ian Romanick wrote:
| IMHO, we'd be better to spend our time writing a highly optimized
| just-in-time compiler for ARB_vertex_program. Then we could just write
| vertex programs for the different important state vectors and let the
| compiler
Brian Paul wrote:
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
Right now people use things like Viewperf to make systems purchase
decisions. Unless the graphics hardware and the rest of the system
are very mismatched, the immediate API already has an
Ian Romanick wrote:
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
In principle, I think the producer/consumer idea is good. Why not
implement known optimizations in it from the start? We already
having *working code* to build formated vertex data (see the
Ian Romanick wrote:
Before going down that road we'd want to sit down with oprofile and a
bunch of applications to decide which sets of state we wanted to tune
for. IMHO, we'd be better to spend our time writing a highly optimized
just-in-time compiler for ARB_vertex_program. Then we could
11 matches
Mail list logo
