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,
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 [EMAIL PROTECTED] wrote:
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
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
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
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 simply
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
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
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 simply hash
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
to
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 with
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
difference on
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
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.
Could
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 things
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
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.
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
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
19 matches
Mail list logo
