mesa3d-dev

[Mesa3d-dev] Lighting code in 3.5

[Gareth H. <ga...@va...>]

Keith, I haven't looked into this much yet, but I was wondering if you
could give me a quick rundown of the changes you've made to
t_shade_tmp.h -- I've noticed the masked versions have gone, as has the
light->IsMatSpecular[side] test.

Thanks.  I'd like any work I do on replacements of the 3.4 code (for
hardware drivers) to be easily transitioned to 3.5 when the time comes.

-- Gareth

Re: [Mesa3d-dev] Lighting code in 3.5

[Keith W. <ke...@va...>]

Gareth Hughes wrote:
> 
> Keith, I haven't looked into this much yet, but I was wondering if you
> could give me a quick rundown of the changes you've made to
> t_shade_tmp.h -- I've noticed the masked versions have gone, as has the
> light->IsMatSpecular[side] test.
> 
> Thanks.  I'd like any work I do on replacements of the 3.4 code (for
> hardware drivers) to be easily transitioned to 3.5 when the time comes.
> 

The early culling code turned out to be a dead end in the face of assembly,
particularly 3dnow and I guess SSE, and cards that did fast culling at the end
of the pipe.  There ended up being less and less reason for it until you look
at the DRI drivers and they all turn it off.  I've removed it in 3.5.

The IsMatSpecular test I'm not so adamant about.  It can come back if anyone
feels strongly, but I felt it might be easier to get a clean assembly
implementation of lighting without it.

Anyway, there's another change to that file rattling through the pipes. 
Here's my latest code which cleans a few things up, and importantly removes
the requirement that VB->Flags exists (for DrawArrays this was a pain).

Keith

Re: [Mesa3d-dev] Lighting code in 3.5

[Gareth H. <ga...@va...>]

Keith Whitwell wrote:
> 
> The early culling code turned out to be a dead end in the face of assembly,
> particularly 3dnow and I guess SSE, and cards that did fast culling at the end
> of the pipe.  There ended up being less and less reason for it until you look
> at the DRI drivers and they all turn it off.  I've removed it in 3.5.

Excellent.  I'd still like to do some performance analysis of culling in
render_vb_triangles and friends as we've discussed, but I'm glad to see
this gone.

> The IsMatSpecular test I'm not so adamant about.  It can come back if anyone
> feels strongly, but I felt it might be easier to get a clean assembly
> implementation of lighting without it.

Thinking about it, I don't really care either way.  It certainly reduces
the combinatoral explosion of my per-light assembly code, but it's not
that big a deal.  Non-specular lighting will be slower of course.

I'll forward my code for you and Brian to check out, and you'll be able
to see how I would handle specular vs. non-specular lights.  I'll
reserve my judgement for later on this one.

> Anyway, there's another change to that file rattling through the pipes.
> Here's my latest code which cleans a few things up, and importantly removes
> the requirement that VB->Flags exists (for DrawArrays this was a pain).

Nice work -- I really like the changes you've made here.  It fits in
quite nicely with what I've been working on, so there are no problems
there.  As I said, I'll forward a snapshot (based on the 3.4 code) on
Monday or thereabouts for you to check out.

-- Gareth