Aapo Tahkola wrote:
static void build_passthrough( struct tnl_program *p, GLuint inputs )
{
+ GLcontext *ctx = p->ctx;
+ GLuint i, nr_lights = 0;
+
+ if (ctx->Light.Enabled == GL_FALSE)
+ emit_op1(p, VP_OPCODE_MOV, register_output(p, VERT_RESULT_COL0), 0,
+ register_input(p, V
Aapo Tahkola wrote:
Mesa is holding drivers private data bound to programs in containers just
like in i915NewProgram.
I suggest this to be sorted out by adding PrivatePrt to vertex and fragment
program structures in Mesa.
This way drivers can allocate their private structures at translation stage
On Mon, 09 May 2005 19:09:40 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Aapo Tahkola wrote:
> > On Tue, 03 May 2005 14:59:53 +0100
> > Keith Whitwell <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Aapo Tahkola wrote:
> >>
> >>>On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
> >>>Vladimir Dergachev <[EMA
Aapo Tahkola wrote:
On Tue, 03 May 2005 14:59:53 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
Aapo Tahkola wrote:
On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
On Thu, 21 Apr 2005, Aapo Tahkola wrote:
On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
Vladimir D
Aapo Tahkola wrote:
On Tue, 03 May 2005 14:59:53 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
Aapo Tahkola wrote:
On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
On Thu, 21 Apr 2005, Aapo Tahkola wrote:
On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
Vladimir D
On Tue, 03 May 2005 14:59:53 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Aapo Tahkola wrote:
> > On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
> > Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> >
> >
> >>
> >>On Thu, 21 Apr 2005, Aapo Tahkola wrote:
> >>
> >>
> >>>On Wed, 23 Feb 2005 15:03:38
Aapo Tahkola wrote:
On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
On Thu, 21 Apr 2005, Aapo Tahkola wrote:
On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
With regard to state switching, it might be worth it to sim
On Sat, 30 Apr 2005 15:43:08 +0300
Aapo Tahkola <[EMAIL PROTECTED]> wrote:
> Ill add something that allows to switch between hw and sw tnl on the fly
> using magic keys later today.
Attached offensive beast does this.
When compiled r300_tnl_switch.so is loaded with LD_PRELOAD, applications that
> Maybe for average case but not for worst.
>
> Heres a list of problems that prevent r300 driver from using Keith's ffp
> program generator:
> 1. _TnlProgram is of fixed size type and smaller than r300_vertex_program
> 2. Programs generated are incomplete in sense that they dont move input color
On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 21 Apr 2005, Aapo Tahkola wrote:
>
> > On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
> > Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> >
> >>With regard to state switching, it might be worth it
Jerome Glisse wrote:
Seems like everyone's working on the same thing. I've just committed a
file which implements most of this internally in Mesa. I've got a few
other commits to make before it can be turned on, but it should be
pretty much the facility you're looking for.
Btw you are not workin
On Thu, 21 Apr 2005, Jerome Glisse wrote:
Seems like everyone's working on the same thing. I've just committed a
file which implements most of this internally in Mesa. I've got a few
other commits to make before it can be turned on, but it should be
pretty much the facility you're looking for.
B
Jerome Glisse wrote:
Seems like everyone's working on the same thing. I've just committed a
file which implements most of this internally in Mesa. I've got a few
other commits to make before it can be turned on, but it should be
pretty much the facility you're looking for.
Btw you are not wo
> Seems like everyone's working on the same thing. I've just committed a
> file which implements most of this internally in Mesa. I've got a few
> other commits to make before it can be turned on, but it should be
> pretty much the facility you're looking for.
Btw you are not working on same thi
On Thu, 21 Apr 2005, Aapo Tahkola wrote:
On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
With regard to state switching, it might be worth it to simply hash
various configuration (fog on /fog off, etc) and just upload state
difference on such changes.
Coul
Jerome Glisse wrote:
On 4/21/05, Aapo Tahkola <[EMAIL PROTECTED]> wrote:
On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
With regard to state switching, it might be worth it to simply hash
various configuration (fog on /fog off, etc) and just upload state
d
On 4/21/05, Aapo Tahkola <[EMAIL PROTECTED]> wrote:
> On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
> Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
>
> >With regard to state switching, it might be worth it to simply hash
> > various configuration (fog on /fog off, etc) and just upload state
> > dif
On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
>With regard to state switching, it might be worth it to simply hash
> various configuration (fog on /fog off, etc) and just upload state
> difference on such changes.
Could work reasonably well. Problem
Hi Aapo,
I have been thinking about this as well - the current code is just the
attempt to get multitexturing working a little bit, apparently there is
some info that is missing from r300_reg.h, or perhaps I misunderstood
something.
With regard to state switching, it might be worth it to si
Greetings all.
I noticed that the code generation for r300 fixed pipeline has just
started and decided to start this discussion before the actual
implementation gets going at full speed.
To cut to the chase, I would like to suggest alternative implementation
using mesas struct vertex_program as a
20 matches
Mail list logo
