Ian Romanick wrote:
> On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
>
>
>>One option is to have the kernel actually do the fixup of the buffers when
>>they are submitted by the client, so the driver never knows really where it's
>>textures are, but talks about them via. some
On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
> One option is to have the kernel actually do the fixup of the buffers when
> they are submitted by the client, so the driver never knows really where it's
> textures are, but talks about them via. some indirection.
I've been loo
Ian Romanick wrote:
> On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote:
>
>>Ian Romanick wrote:
>>
>>>- Do we really need the &3 in radeon_vtxfmt_c.c:
>>>
>>> static void radeon_MultiTexCoord1fARB( GLenum target, GLfloat s )
>>> {
>>>- GLfloat *dest = vb.texcoordptr[(target - GL_
On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote:
> Ian Romanick wrote:
> > - Do we really need the &3 in radeon_vtxfmt_c.c:
> >
> > static void radeon_MultiTexCoord1fARB( GLenum target, GLfloat s )
> > {
> > - GLfloat *dest = vb.texcoordptr[(target - GL_TEXTURE0_ARB)&1];
> > +
On Fri, 27 Sep 2002, Jens Owen wrote:
>
> 2) This one's a little wild just for what you want, but it's something
> Workstation Vendors have done in the past to virtualize limited
> resources...When stealing memory, setup the page tables to generate a
> page fault if it's accessed. Then have
On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
> > from overwriting normalptr and floatcolorptr. :) In actuality, should this
> > be expanded anyway? How was the value 15 arrived at?
>
> Yes, you need a bigger maximum for the extra texture coord.
Okay. It should be changed t
Ian Romanick wrote:
>>>A lot of this stuff is inherently device independent with some device
>>>dependent "direction" (i.e., *ChooseTextureFormat), but it hasn't been
>>>implemented that way. As a reference point, my previous work removed
>>>somewhere around 450 lines of code from the MGA driver
On Fri, 27 Sep 2002, Ian Romanick wrote:
>
> > > A lot of this stuff is inherently device independent with some device
> > > dependent "direction" (i.e., *ChooseTextureFormat), but it hasn't been
> > > implemented that way. As a reference point, my previous work removed
> > > somewhere around 4
>
> Right. Here's my updated suggestion. Leave the '&3' in the patch, but
> expand the 'vertex' array in radeon_vb from 15 elements to 17. That will
> prevent code like
>
> glMultiTexCoord2fv( GL_TEXTURE3, foo );
Yes, that works for this path. The other you have to look at is where t
On Thu, Sep 26, 2002 at 04:51:37PM +0100, Keith Whitwell wrote:
> Ian Romanick wrote:
> > On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote:
> > I guess my problem is, should values other than [GL_TEXTURE0, GL_TEXTURE0 +
> > MAX_TEXTURE_UNITS] ever get this far in the pipeline?
>
> T
Ian Romanick wrote:
> Here is a patch that will enable the 3rd texture unit in the Radeon
> R100/RV200 driver. I have tested it using multiarb on a Radeon "classic"
> DDR and a Radeon M6 (AGP developer board). There are a few issues that I
> came across that should be resolved before applying.
>
11 matches
Mail list logo
