Re: [Dri-devel] Radeon TCL driver tested
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 all of the Mesa/GLUT demos are pointless these days for > measuring T&L performance. Enlarging the window to these sizes makes > them a fill test, and not a very good one at that :-) > > For real T&L performance measurements, you need to look at things like > viewperf, maybe glperf, things like that. You basically need a > polygonal model with 100K+ triangles before it gets interesting. Even > then, you have to be careful about things like data submission and so > on, to ensure you're really testing T&L performance and not AGP > bandwidth, rasterization throughput etc. Certainly all of the t&l tests are also AGP bandwidth tests at the moment - we don't yet store display lists on card or even agp memory. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa viewport transformation and depth scaling
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 when I tested this). -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon TCL driver tested
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 these days for measuring T&L performance. Enlarging the window to these sizes makes them a fill test, and not a very good one at that :-) For real T&L performance measurements, you need to look at things like viewperf, maybe glperf, things like that. You basically need a polygonal model with 100K+ triangles before it gets interesting. Even then, you have to be careful about things like data submission and so on, to ensure you're really testing T&L performance and not AGP bandwidth, rasterization throughput etc. -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA
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 submission to the chip. Right now, I'm not 100% sure that the > mach64 is one of those sorts of chips, but it's shaping up to be a good > prospect for that. > > > -- > Frank Earl > If there is any chance mach64 is one of those chips, it's surely worth trying. Things will get clearer as we get forward. Regards, José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon TCL driver tested
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? -- Trond Eivind Glomsrød Red Hat, Inc. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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 and over) if
RADEON_PAGEFLIP exists. Plus sorting out drawOffset.
I removed what I assume is either for old clients or a bogus emit_state
call in the clear stuff, and I suspect an off-by-1 error somewhere,
which I hacked by removing the -1 from the x2,y2 figures (you get a
flashing line at the bottom and right of the screen otherwise)
Lots of things are broken about it (switching to a console, the obvious
effects with windowed apps, single buffered demos that don't call
glSwapBuffers don't display anything (there don't appear to be any none
doublebuffered visuals for the tests in the driver to ever fail?)
But it seems to work fine with q3, rtcw and fullscreen stuff.
Occasionally it exits on the dark side too no doubt a call to
CloseFullScreen would help.
At the moment 1024x768 (which I expected to get the biggest benefit)
hits lack of texture space and/or maybe depth clears / lack of
hierarchical z, even with the pixmap cache set to 1 page and low
texturing - at the mo this is still only a 2 or 3 fps gain there.
--
Michael.
Index: lib/GL/mesa/src/drv/radeon/radeon_context.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c,v
retrieving revision 1.7.2.11
diff -u -3 -p -r1.7.2.11 radeon_context.c
--- lib/GL/mesa/src/drv/radeon/radeon_context.c 9 Mar 2002 00:40:41 -
1.7.2.11
+++ lib/GL/mesa/src/drv/radeon/radeon_context.c 10 Mar 2002 23:03:57 -
@@ -71,6 +71,8 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
int RADEON_DEBUG = (0);
#endif
+static GLboolean radeonOpenFullScreen( __DRIcontextPrivate *driContextPriv );
+static GLboolean radeonCloseFullScreen( __DRIcontextPrivate *driContextPriv );
/* Return the width and height of the current color buffer.
@@ -631,6 +633,8 @@ radeonMakeCurrent( __DRIcontextPrivate *
_mesa_set_viewport( newRadeonCtx->glCtx, 0, 0,
driDrawPriv->w, driDrawPriv->h );
}
+ if (getenv("RADEON_PAGEFLIP"))
+ radeonOpenFullScreen ( driContextPriv );
} else {
_mesa_make_current( 0, 0 );
}
@@ -652,13 +656,13 @@ radeonUnbindContext( __DRIcontextPrivate
static GLboolean
radeonOpenFullScreen( __DRIcontextPrivate *driContextPriv )
{
-#if 0
+#if 1
radeonContextPtr rmesa = (radeonContextPtr)driContextPriv->driverPrivate;
GLint ret;
/* FIXME: Do we need to check this?
*/
- if ( !rmesa->glCtx->Visual.doubleBufferMode )
+ if ( !rmesa->glCtx->Visual.doubleBufferMode || rmesa->doPageFlip )
return GL_TRUE;
LOCK_HARDWARE( rmesa );
@@ -666,11 +670,12 @@ radeonOpenFullScreen( __DRIcontextPrivat
/* Ignore errors. If this fails, we simply don't do page flipping.
*/
- ret = drmRadeonFullScreen( rmesa->driFd, GL_TRUE );
+ ret = drmRadeonFullScreen( rmesa->dri.fd, GL_TRUE );
UNLOCK_HARDWARE( rmesa );
rmesa->doPageFlip = ( ret == 0 );
+ rmesa->currentPage = 0;
#endif
return GL_TRUE;
}
@@ -680,7 +685,7 @@ radeonOpenFullScreen( __DRIcontextPrivat
static GLboolean
radeonCloseFullScreen( __DRIcontextPrivate *driContextPriv )
{
-#if 0
+#if 1
radeonContextPtr rmesa = (radeonContextPtr)driContextPriv->driverPrivate;
LOCK_HARDWARE( rmesa );
@@ -688,7 +693,7 @@ radeonCloseFullScreen( __DRIcontextPriva
/* Don't care if this fails, we're not page flipping anymore.
*/
- drmRadeonFullScreen( rmesa->driFd, GL_FALSE );
+ drmRadeonFullScreen( rmesa->dri.fd, GL_FALSE );
UNLOCK_HARDWARE( rmesa );
Index: lib/GL/mesa/src/drv/radeon/radeon_span.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_span.c,v
retrieving revision 1.11.2.1
diff -u -3 -p -r1.11.2.1 radeon_span.c
--- lib/GL/mesa/src/drv/radeon/radeon_span.c20 Feb 2002 01:06:32 -
1.11.2.1
+++ lib/GL/mesa/src/drv/radeon/radeon_span.c10 Mar 2002 23:03:57 -
@@ -292,12 +292,22 @@ static void radeonSetReadBuffer( GLconte
switch ( mode ) {
case GL_FRONT_LEFT:
- rmesa->state.pixel.readOffset = rmesa->radeonScreen->frontOffset;
- rmesa->state.pixel.readPitch = rmesa->radeonScreen->frontPitch;
+ if ( rmesa->doPageFlip && rmesa->currentPage == 0 ) {
+rmesa->state.color.drawOffset = rmesa->radeonScreen->backOffset;
+rmesa->state.color.drawPitch = rmesa->radeonScreen->backPitch;
+ } else {
+ rmesa->state.color.drawOffset = rmesa->radeonScreen->frontOffset;
+ rmesa->state.color.drawPitch = rmesa->radeonScreen->frontPitch;
+ }
break;
case GL_BACK_LEFT:
- rmesa->state.pixel.readOffset = rmesa->radeonScreen->backOffset;
- r
Re: [Dri-devel] Mach64 DMA
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 taking in direct commands from userspace in DMA buffers and sending them on to the chip as time goes along. If you can make it so that it doesn't lock up the card or the machine and doesn't compromise system security in any way (i.e. issuing a DMA pass from a part of memory to the framebuffer and then from the framebuffer to another part of memory so as to clobber things or to pilfer info from other areas), it's pretty safe to do "direct" commands. From observations, it appears that you can't get the engine to do anything except GUI operations during a properly set up GUI-mastering pass. The only risks that I can see right at the moment with sending direct commands over "indirect" commands is one of not resetting certain select registers to what they were before the pass and one of the engine not handling certian GUI operations well. The first is easily taken care of by having the driver have a 4k block submitted in the descriptor chain as the last entry that updates those registers accordingly- the list of commands should only need to be built once and reused often since these registers won't be changed by the DRM engine, Mesa driver, or the XAA driver after the XAA driver does it's setup for the chip operation. The second case is a tough one and one that copying/mapping won't protect you from it- you have to process commands to prevent them from occuring (compute intensive and there might be other cases, each time you'd have to come up with yet another workaround) or find something to detect a hang on the engine and reset it proper. I seriously doubt that we'd encounter one of those, but we might all the same. I've still got one or two more tests to run (I've yet to deliberately hang the engine, detect the same, and then do a reset- but then I've yet to be able to hang the engine with it _properly_ set up...) but most of the innards for copying commands or whatever would be largely the same (some of the interfaces might change, but that's less of an issue than the heart of the DMA engine itself which is the same no matter what...) so I'm going to get _SOMETHING_ in place to see what our performance actually would be with some DMA operation going on. > > Mapping and unmapping a memory space is somewhat compute intensive. > > This one has to be compared to the time that takes to copy a buffer, > unless there is a way to do it in a secure manner without copying or > unmapping. 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 submission to the chip. Right now, I'm not 100% sure that the mach64 is one of those sorts of chips, but it's shaping up to be a good prospect for that. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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,/* mov(%ebx), %ebx */ > >0x88, 0xd8,/* mov%bl, %al */ > >0x88, 0xf9,/* mov%bh, %cl */ > > > > It does this twice... > > Yeah, there was mixed 'what was wrong' and 'what is wrong' in my > explanation, this code is what I committed last night. OK - that's why I didn't recognize the code above... > > Good point - these extra steps are skipped in the "cached codegen" case. But > > they really need to be done... > > Your CHOOSE_COLOR patch fixes what I was seeing in tuxracer. > > (q3 is looking much better, 102.8fps @ 640x480HQ with kludged page > flipping (adds about 7-8fps), 76.8 @ 800x600) Nice. How kludged is kludged? Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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 */ >0x88, 0xd8,/* mov%bl, %al */ >0x88, 0xf9,/* mov%bh, %cl */ > > It does this twice... Yeah, there was mixed 'what was wrong' and 'what is wrong' in my explanation, this code is what I committed last night. > Good point - these extra steps are skipped in the "cached codegen" case. But > they really need to be done... Your CHOOSE_COLOR patch fixes what I was seeing in tuxracer. (q3 is looking much better, 102.8fps @ 640x480HQ with kludged page flipping (adds about 7-8fps), 76.8 @ 800x600) -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA
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 putting the hacks I've been > playing with into a unified DMA framework. I should be putting the first > updates to the branch in over the next couple of days. > I look forward to check it out. > Of note, when I did find some spare time, I ran tests on what we needed > to do > to secure the chip's DMA path. I found out some interesting facts. > > It will accept any values written to the registers. > It will not act on any of those settings during the DMA pass unless > they're a > GUI specific operation when it's doing a command-type DMA. > It will not act on many of the settings after a DMA pass is complete. > It will not let you set up any sort of DMA pass during the operation. > Junk commands, by themselves, do not seem to hose up the engine in > operation. I didn't fully understand the implications of above, but shouldn't the direct access to the chip registers still be denied to clients? > Mapping and unmapping a memory space is somewhat compute intensive. This one has to be compared to the time that takes to copy a buffer, unless there is a way to do it in a secure manner without copying or unmapping. > > -- > Frank Earl > José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mesa viewport transformation and depth scaling
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 previous mach64 (mesa 3.x) driver defined the coord setup as
#define COORD \
do {\
GLfloat *win = VB->Win.data[i]; \
v->v.x = win[0] + xoffset; \
v->v.y = - win[1] + yoffset; \
v->v.z = win[2]; \
v->v.rhw = win[3]; \
} while (0)
while for example the R128 defined as
#define COORD \
do {\
GLfloat *win = VB->Win.data[i]; \
v->v.x = win[0] + xoffset; \
v->v.y = - win[1] + yoffset; \
v->v.z = depth_scale * win[2]; \
v->v.rhw = v->v.rhw2 = win[3]; \
} while (0)
So I removed the 'depth_scale' in calculation of hw_viewport, in
mach64CalcViewport, and everything worked fine.
But I still don't understand what's the relationship between *CalcViewport
and the viewport calculations made in _mesa_set_viewport. At
_mesa_set_viewport, for instance, there is a comment that says "This is
really driver-specific and should be maintained elsewhere if at all.". It
seems that _mesa_set_viewport sets the scale to [0,MaxDepth], but the
*CalcViewport in most DRI drivers "undo" this scaling, rescaling to a
[0,1].
My question is why the other DRI drivers do this (don't the chips expect
the depths in integer format as well?) and in what depth scale should the
vertex buffers be after all?
This understanding would be important because the current mach64 triangle
setup engine is able to specify the z values in 16.1 format, but only the
16 integer part is being used, so I would like to implement that as well.
Regards,
José Fonseca
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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 colours >ergo > red snow (there is no codegen for non PKCOLOR 4ub case it just does return 0, > so it always used the generic stuff, albeit afaict incorrectly?). Yes, it should never have been in the 4ub path. The _ae_loopback change was definitely correct. > Once that was changed CHOOSE_COLOR calls radeon_makeX86Color4ubv, the > non PKCOLOR case, which (unless there was some deep magic I missed?) > was written like makeX86Color4ub, taking params off the stack @ 4(%esp), > 8(%esp) etc, rather than ubv. 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 */ 0x88, 0xd8,/* mov%bl, %al */ 0x88, 0xf9,/* mov%bh, %cl */ It does this twice... > But, that aside, in CHOOSE_COLOR, in the generic case where there is no > CODEGEN function, it checks FPALPHA (which isn't true) so it wouldn't > call 4ubv_4f (and the semantics of makeX86Color4ubv when PKCOLOR is > false match this 4ub_4f case). > > Without a codegen 4ubv function, CHOOSE_COLOR would check FPCOLOR (true) > and conditionally call copy_to_current, _mesa_install_exec_vtxfmt and > finally the Color4ubv_3f in radeon_vtxfmt_c.c Obviously the codegen stuff > doesn't do any of this additional stuff. Good point - these extra steps are skipped in the "cached codegen" case. But they really need to be done... > I'm assuming here, that it should check FPALPHA and return 0 if > it's false? (or have the processing for the 3f cases?) > > Am I completely hatstand? No, it sounds like you've spotted a bunch of good problems... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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 is no codegen for non PKCOLOR 4ub case it just does return 0, so it always used the generic stuff, albeit afaict incorrectly?). Once that was changed CHOOSE_COLOR calls radeon_makeX86Color4ubv, the non PKCOLOR case, which (unless there was some deep magic I missed?) was written like makeX86Color4ub, taking params off the stack @ 4(%esp), 8(%esp) etc, rather than ubv. But, that aside, in CHOOSE_COLOR, in the generic case where there is no CODEGEN function, it checks FPALPHA (which isn't true) so it wouldn't call 4ubv_4f (and the semantics of makeX86Color4ubv when PKCOLOR is false match this 4ub_4f case). Without a codegen 4ubv function, CHOOSE_COLOR would check FPCOLOR (true) and conditionally call copy_to_current, _mesa_install_exec_vtxfmt and finally the Color4ubv_3f in radeon_vtxfmt_c.c Obviously the codegen stuff doesn't do any of this additional stuff. I'm assuming here, that it should check FPALPHA and return 0 if it's false? (or have the processing for the 3f cases?) Am I completely hatstand? -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA
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 filtered with just the messages regarding mach64 at > http://mefriss1.swan.ac.uk/~jfonseca/dri/mailing-lists/ The problem was that the XAA driver for mach64 was setting the FIFO size up for some reason and it was leaving the chip in a state that wouldn't work for the DMA mode. If we set the size back to the default setting before we do the first DMA pass, everybody's happy. I suspect if we got with the developer of the XAA driver we can sell him on leaving that setting alone in the driver's setup. 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 putting the hacks I've been playing with into a unified DMA framework. I should be putting the first updates to the branch in over the next couple of days. Of note, when I did find some spare time, I ran tests on what we needed to do to secure the chip's DMA path. I found out some interesting facts. It will accept any values written to the registers. It will not act on any of those settings during the DMA pass unless they're a GUI specific operation when it's doing a command-type DMA. It will not act on many of the settings after a DMA pass is complete. It will not let you set up any sort of DMA pass during the operation. Junk commands, by themselves, do not seem to hose up the engine in operation. Mapping and unmapping a memory space is somewhat compute intensive. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA
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 > > Bob 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 filtered with just the messages regarding mach64 at http://mefriss1.swan.ac.uk/~jfonseca/dri/mailing-lists/ I hope this helps. Regards, José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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! :-) > > I did but I think it's still wrong. > > In the fallback case (RADEON_NO_CODEGEN=1) it calls radeon_Color4ubv_3f > which works differently to what I changed (which is effectively > radeon_Color4ubv_4f) > > That messes the fog somehow. What did you change exactly? Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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 wrong. In the fallback case (RADEON_NO_CODEGEN=1) it calls radeon_Color4ubv_3f which works differently to what I changed (which is effectively radeon_Color4ubv_4f) That messes the fog somehow. -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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 heap of demos / samples and Tuxracer) The rmesa->vertex_format / rmesa->tcl_vertex_format thing is all kindof broken and has been the source of quite a few bugs. The real problem is that there are 3 files all which believe that rmesa->vertex_format is their own private state that they can modify at will without notifying anyone else. When they get swapped between (_tris.c, _tcl.c, _vtxfmt.c) they often find the rest of their state out of sync with rmesa->vertex_format. An obvious thing to do would be to triplicate that variable and give them each a private copy & make sure nobody else uses it (ie pass it as a parameter to all external usage of the field) Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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 debugging messages from the FIXUP2 macro, but I don't > > think there is a problem. > > > > Here's the messages and a stack trace from when they are > > generated...just in case. > > > > radeonCreateScreen > > radeon_makeX86Color4ubv/438 CVAL 0 OFFSET 2 > > radeon_makeX86Color4ubv/439 CVAL deadbeaf OFFSET 27 > > radeon_makeX86Color4ubv/440 CVAL deadbeaf OFFSET 33 > > radeon_makeX86Color4ubv/441 CVAL deadbeaf OFFSET 55 > > radeon_makeX86Color4ubv/442 CVAL deadbeaf OFFSET 61 > > This is just me not quite finishing my job. The next step would be to turn > all those FIXUP2's into FIXUP's using the results printed above. > Jens - I've done this. Can you check your app is still working... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 DMA
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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
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't > think there is a problem. > > Here's the messages and a stack trace from when they are > generated...just in case. > > radeonCreateScreen > radeon_makeX86Color4ubv/438 CVAL 0 OFFSET 2 > radeon_makeX86Color4ubv/439 CVAL deadbeaf OFFSET 27 > radeon_makeX86Color4ubv/440 CVAL deadbeaf OFFSET 33 > radeon_makeX86Color4ubv/441 CVAL deadbeaf OFFSET 55 > radeon_makeX86Color4ubv/442 CVAL deadbeaf OFFSET 61 This is just me not quite finishing my job. The next step would be to turn all those FIXUP2's into FIXUP's using the results printed above. I could even do something crazy like print out code that can be cut & pasted in instead of this which needs some interpretation... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
