Gareth Hughes wrote:
>
> Trond Eivind Glomsrød wrote:
> > Gareth Hughes <[EMAIL PROTECTED]> writes:
> >>That's probably more of a rasterization/fill test than a T&L test, so
> >>it's not surprising there isn't a more significant increase.
> >>
> >
> > What tests do you recommend?
>
> Pretty much
On Sun, 10 Mar 2002, José Fonseca wrote:
...
> So I removed the 'depth_scale' in calculation of hw_viewport, in
> mach64CalcViewport, and everything worked fine.
Good catch! This fixes some of the rendering problems I was seeing in
tuxracer and gltron (I just set depth_scale=1 in StateInit wh
Trond Eivind Glomsrød wrote:
> Gareth Hughes <[EMAIL PROTECTED]> writes:
>>That's probably more of a rasterization/fill test than a T&L test, so
>>it's not surprising there isn't a more significant increase.
>>
>
> What tests do you recommend?
Pretty much all of the Mesa/GLUT demos are pointless
On 2002.03.10 21:30 Frank C. Earl wrote:
> ...
>
> If you don't have issues with sending commands directly, you don't need
> to
> copy or map/unmap. You don't need special clear commands or swap
> commands,
> you only need to issue DMAable buffers of commands to the DRM engine for
> eventual sub
Gareth Hughes <[EMAIL PROTECTED]> writes:
> Jeffrey W. Baker wrote:
> >
> > glxgears at 1600x1200x24 improved from 804 to 824fps.
>
> That's probably more of a rasterization/fill test than a T&L test, so
> it's not surprising there isn't a more significant increase.
What tests do you recommend
On Sun, Mar 10, 2002 at 10:44:00PM +, Keith Whitwell wrote:
> Nice. How kludged is kludged?
Attached.
Most of it is just uncommenting what's already there, and adding a call
(probably in the wrong place as MakeCurrent seems to be called a lot,
hence the check added to avoid enabling over an
On Sunday 10 March 2002 04:36 pm, José Fonseca wrote:
> I didn't fully understand the implications of above, but shouldn't the
> direct access to the chip registers still be denied to clients?
Depends.
Looking at the gamma source code (I could be wrong, mind...) it appears that
the DRM is ta
Michael wrote:
>
> On Sun, Mar 10, 2002 at 07:28:21PM +, Keith Whitwell wrote:
> > Are you sure? It loads *v into %ebx, then pulls it apart to %al, %cl
> >
> >0x8b, 0x5c, 0x24, 0x08,/* mov0x8(%esp,1), %ebx */
> >0x8b, 0x1b,/* mo
On Sun, Mar 10, 2002 at 07:28:21PM +, Keith Whitwell wrote:
> Are you sure? It loads *v into %ebx, then pulls it apart to %al, %cl
>
>0x8b, 0x5c, 0x24, 0x08,/* mov0x8(%esp,1), %ebx */
>0x8b, 0x1b,/* mov(%ebx), %ebx */
>
On 2002.03.10 15:55 Frank C. Earl wrote:
> On Sunday 10 March 2002 11:44 am, José Fonseca wrote:
>
> ...
>
> Sorry for being silent for so long gang. Been, yet again, crushed under
> with lovely personal business. I have started a new branch
> (mach64-0-0-3-dma-branch), and I'm actually puttin
The current mach64 (mesa 4.x) driver doesn't seem to be doing z depth
test. After assuring that the mach64's z control register was being set
properly I realized that the vertex buffers had the z in a [0,1] scale
while the primitive drawing functions expected them in a a [0,0x].
The previo
Michael wrote:
>
> On Sun, Mar 10, 2002 at 04:35:31PM +, Keith Whitwell wrote:
> > What did you change exactly?
>
> Originally _ae_loopback_array_element called glColor4ub passing it 1 param, I
>changed that to
> call glColor4ubv (api_arrayelt.c). So original code took random values for col
On Sun, Mar 10, 2002 at 04:35:31PM +, Keith Whitwell wrote:
> What did you change exactly?
Originally _ae_loopback_array_element called glColor4ub passing it 1 param, I changed
that to
call glColor4ubv (api_arrayelt.c). So original code took random values for colours ergo
red snow (there i
On Sunday 10 March 2002 11:44 am, José Fonseca wrote:
> I really don't know much about that, since it must happened before I
> subscribed to this mailing list, but perhaps you'll want to take a look to
> the Utah-GLX and this list archives. You can get these archives in mbox
> format and also fil
On 2002.03.10 11:30 Robert Lunnon wrote:
> A while back there was a problem with the Mach64 initialisation such that
> it
> locked up after executing dma, can someone point at what the resolution
> to
> that problem was and where things were patched so I can have a look at it
> ?
>
> Thanks
>
>
Michael wrote:
>
> On Sat, Mar 09, 2002 at 11:34:30PM -0700, Jens Owen wrote:
> > Michael Fitzpatrick wrote:
> >
> > > Log message:
> > > Fix arrayelts color processing, vtxfmt_x86 Color4ubv function (red snow
> > > problem in Tuxracer)
> >
> > Good work Michael. You got the Red Out! :-)
>
On Sat, Mar 09, 2002 at 11:34:30PM -0700, Jens Owen wrote:
> Michael Fitzpatrick wrote:
>
> > Log message:
> > Fix arrayelts color processing, vtxfmt_x86 Color4ubv function (red snow
> > problem in Tuxracer)
>
> Good work Michael. You got the Red Out! :-)
I did but I think it's still wron
Michael Fitzpatrick wrote:
>
> CVSROOT:/cvsroot/dri
> Module name:xc
> Repository: xc/xc/lib/GL/mesa/src/drv/radeon/
> Changes by: leahcim@usw-pr-cvs1.02/03/09 20:16:11
>
> Log message:
> Fix IDX typo. Fix tcl_vertex_format breakage (better fix for
> this? Fixes a hea
Keith Whitwell wrote:
>
> Jens Owen wrote:
> >
> > Michael Fitzpatrick wrote:
> >
> > > Log message:
> > > Fix arrayelts color processing, vtxfmt_x86 Color4ubv function (red snow
> > > problem in Tuxracer)
> >
> > Good work Michael. You got the Red Out! :-)
> >
> > I am seeing some debuggin
A while back there was a problem with the Mach64 initialisation such that it
locked up after executing dma, can someone point at what the resolution to
that problem was and where things were patched so I can have a look at it ?
Thanks
Bob
___
Dri-de
Jens Owen wrote:
>
> Michael Fitzpatrick wrote:
>
> > Log message:
> > Fix arrayelts color processing, vtxfmt_x86 Color4ubv function (red snow
> > problem in Tuxracer)
>
> Good work Michael. You got the Red Out! :-)
>
> I am seeing some debugging messages from the FIXUP2 macro, but I don
21 matches
Mail list logo
