Re: [Dri-devel] Radeon Clear Bug
On Wed, 2002-06-05 at 01:05, Jens Owen wrote: > > Have you seen any clear bugs when the server regenerates? > > After Linus asked the questions regarding locking optimizations for the > Radeon, I decided to explore the current policies in the Radeon driver. > After building a fully debugable server and running in a bare bones > environment, I noticed the screen wasn't clearing when the server > regenerated. > > This problem goes away when the DRI is disabled, so it might be related > to using CP mode in the 2D driver. > > This bug shows up on the TCL branch and the main development trunk. > > Would it be helpful if I dove into this deeper? or do you already have > a fix for this? I submitted a workaround for this (set info->indirectBuffer = NULL in ScreenInit()) to [EMAIL PROTECTED] on March 9th, your fix is better though. r128 has the same problem BTW. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon Clear Bug
Jens Owen wrote:
>
> Kevin E Martin wrote:
> >
> > On Tue, Jun 04, 2002 at 05:05:05PM -0600, Jens Owen wrote:
> > > Kevin,
> > >
> > > Have you seen any clear bugs when the server regenerates?
> >
> > Not yet, but I haven't looked yet. The code is not currently in a state
> > that I can test this, but I will add it to the list of things for me to
> > check out.
> >
> > > After Linus asked the questions regarding locking optimizations for the
> > > Radeon, I decided to explore the current policies in the Radeon driver.
> > > After building a fully debugable server and running in a bare bones
> > > environment, I noticed the screen wasn't clearing when the server
> > > regenerated.
> >
> > I'm not sure what you mean by "not clearing". Is the problem that the
> > root weave does not appear on server regeneration?
>
> Yes. Just the upper half.
Turns out it was the whole thing...I was just corropting the upper half.
> > If so, then does the
> > rest of the server run properly and just the first fill is not working.
>
> Yes. xrefresh fixes the root weave, too.
>
> > > This problem goes away when the DRI is disabled, so it might be related
> > > to using CP mode in the 2D driver.
> >
> > I agree.
Yup, a little CP house cleaning in RADEONDRICloseScreen did the trick.
> > > This bug shows up on the TCL branch and the main development trunk.
> > >
> > > Would it be helpful if I dove into this deeper? or do you already have
> > > a fix for this?
> >
> > It would be very helpful to dig deeper, if you have time. If you figure
> > out what's going on (or even better come up with a patch to fix it :-),
> > please let me know what you find.
>
> I'll take a look tonight and let you know if I find anything.
I've submitted fixes to the trunk and to the tcl branch.
> > I've just looked through my list of patches that I'm integrating and no
> > one has addressed this problem. I'm still mainly concentrating on
> > getting the non-DRI Radeon driver in shape, but I've done a bit of clean
> > up and patch integration on the CP based 2D code. I'll let you know
> > what I find when I finish integrating these 2D CP patches.
Here is the standalone patch relative to the TCL branch in case you need
it.
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
Index: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v
retrieving revision 1.21.2.4
diff -u -r1.21.2.4 radeon_dri.c
--- xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 21 May 2002 17:26:27
- 1.21.2.4
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 5 Jun 2002 04:39:17
+-
@@ -1509,9 +1509,20 @@
{
ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
RADEONInfoPtr info = RADEONPTR(pScrn);
+RING_LOCALS;
/* Stop the CP */
if (info->directRenderingEnabled) {
+ /* If we've generated any CP commands
+* we must flush them to the kernel module now.
+*/
+ if (info->CPInUse) {
+ RADEON_FLUSH_CACHE();
+ RADEON_WAIT_UNTIL_IDLE();
+ RADEONCPReleaseIndirect(pScrn);
+
+ info->CPInUse = FALSE;
+ }
RADEONCP_STOP(pScrn, info);
}
[Dri-devel] refinance now 1053
We promise that we can find a lower payment and lower rate than you pay right now for your house. Takes less than 1 minute to see if we can save you some money. href=http://www.status100.com/mortgage/index34.html 1053 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon Clear Bug
Kevin E Martin wrote: > > On Tue, Jun 04, 2002 at 05:05:05PM -0600, Jens Owen wrote: > > Kevin, > > > > Have you seen any clear bugs when the server regenerates? > > Not yet, but I haven't looked yet. The code is not currently in a state > that I can test this, but I will add it to the list of things for me to > check out. > > > After Linus asked the questions regarding locking optimizations for the > > Radeon, I decided to explore the current policies in the Radeon driver. > > After building a fully debugable server and running in a bare bones > > environment, I noticed the screen wasn't clearing when the server > > regenerated. > > I'm not sure what you mean by "not clearing". Is the problem that the > root weave does not appear on server regeneration? Yes. Just the upper half. > If so, then does the > rest of the server run properly and just the first fill is not working. Yes. xrefresh fixes the root weave, too. > > This problem goes away when the DRI is disabled, so it might be related > > to using CP mode in the 2D driver. > > I agree. > > > This bug shows up on the TCL branch and the main development trunk. > > > > Would it be helpful if I dove into this deeper? or do you already have > > a fix for this? > > It would be very helpful to dig deeper, if you have time. If you figure > out what's going on (or even better come up with a patch to fix it :-), > please let me know what you find. I'll take a look tonight and let you know if I find anything. > I've just looked through my list of patches that I'm integrating and no > one has addressed this problem. I'm still mainly concentrating on > getting the non-DRI Radeon driver in shape, but I've done a bit of clean > up and patch integration on the CP based 2D code. I'll let you know > what I find when I finish integrating these 2D CP patches. > > Thanks! > Kevin -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon Clear Bug
On Tue, Jun 04, 2002 at 05:05:05PM -0600, Jens Owen wrote: > Kevin, > > Have you seen any clear bugs when the server regenerates? Not yet, but I haven't looked yet. The code is not currently in a state that I can test this, but I will add it to the list of things for me to check out. > After Linus asked the questions regarding locking optimizations for the > Radeon, I decided to explore the current policies in the Radeon driver. > After building a fully debugable server and running in a bare bones > environment, I noticed the screen wasn't clearing when the server > regenerated. I'm not sure what you mean by "not clearing". Is the problem that the root weave does not appear on server regeneration? If so, then does the rest of the server run properly and just the first fill is not working. > This problem goes away when the DRI is disabled, so it might be related > to using CP mode in the 2D driver. I agree. > This bug shows up on the TCL branch and the main development trunk. > > Would it be helpful if I dove into this deeper? or do you already have > a fix for this? It would be very helpful to dig deeper, if you have time. If you figure out what's going on (or even better come up with a patch to fix it :-), please let me know what you find. I've just looked through my list of patches that I'm integrating and no one has addressed this problem. I'm still mainly concentrating on getting the non-DRI Radeon driver in shape, but I've done a bit of clean up and patch integration on the CP based 2D code. I'll let you know what I find when I finish integrating these 2D CP patches. Thanks! Kevin ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: atimisc_drv.o relies on drm
: Well, I built kernel 2.4.18-0.26 (from RH Rawhide SRPM) and got much trouble. The worst of it that my vmware does not work any more:( The vm* modules are built OK but I get OOPS loading them. Well, but even drm does not work any better. I rebuilt mach64.o again and still get those "Permission denied" messages. Any clues? Regards, Sergey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 8500 Drivers
On Tuesday 04 June 2002 18:53, you wrote: > Maybe you should start reading about advanced c programming > technics first? (Okay, Pascal will do the job as well.) > advanced here means programming with mutexes, semaphores, > interrupts, object handles, buffering, chaching, memory I'm supposed to know most of this, hope my boss doesn't read this list :-). > ringbuffer = . So the ringbuffer is nothing more than an implementation of a fifo queue in which the driver puts the commands to be processed by the command processor. > freelist = hmm it seems to have something to do with dma buffers but since i don't know the dma structs/api, i'll have to take a closer look. If my impression is right, the only thing the kernel module does is (next to init/cleanup) converting a user ioctl request (draw vertex, go full screen) to appropriate commands for the CP. It does this by using a ring buffer for the commands and dma transfers for the textures (with appropriate cp instructions i presume) managed by a freelist. Hmm, rereading the DRI DEV FAQ (thanks for this wonderfull document), I'll next get familiar with the drm_* code before i ask any more 'obvious' questions :-) Peter ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon Clear Bug
Kevin, Have you seen any clear bugs when the server regenerates? After Linus asked the questions regarding locking optimizations for the Radeon, I decided to explore the current policies in the Radeon driver. After building a fully debugable server and running in a bare bones environment, I noticed the screen wasn't clearing when the server regenerated. This problem goes away when the DRI is disabled, so it might be related to using CP mode in the 2D driver. This bug shows up on the TCL branch and the main development trunk. Would it be helpful if I dove into this deeper? or do you already have a fix for this? Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] NO_BATCH_DISPATCH path
Leif, As I was restructuring part of the DMA submission code I realized that there is a fault in the NO_BATCH_DISPATCH path. You don't guarantee that the card doesn't stop at any momment because you've chosen not check if a change in the last buffer continuation flag is sucessful or not, and wait for idle & restart if not. This means that in _every_ wait loop we have to account for possibility of the card to stop in result of that (this include e.g., _wait_ring, but many others). I tried to make quick fix to this, but it didn't solve anything (I can reproduce the bug everytime I want by runing TO - a Mod to UT), so I stopped trying to concentrate on what I was doing before. I just wanted to tell you because you're probably looking at that too. Regarding the restructuring I'm doing, is basically a simplification to bring more closely what I had previously in mind. I'm making the RING_* macros to commit the buffers immediately, and the DMA_* macros to fire up one buffer (also commiting immediately). After seeing this problem I'm not sure if it won't be better to wait for idle when commiting a buffer to ring too late, because this would allow to assume that the card is either running or finished, and would lessen the chances of bugs. This is gonna take some days, but I'll come back with a diff for you to comment as soon as I have it running minimally. Regards, José Fonseca ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] the CREDIT LAW is on your side DRI-DEVEL ! Get PERFECT CREDIT NOW!
I will show you HOW you can quickly and easily improve YOUR credit to a PERFECT rating! Click here NOW for full FREE details! ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Card swap?
Anybody want to swap me a voodoo[2-5] for an ATI Mach64 AGP? I want to fart around with the voodoo driver for learning experience and could use one to test with. AGP or PCI is fine. -Al Tobey This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] tdfx: OpenGL/Mesa 1.3 version? texture compression?
Now to the tdfx OpenGL/Mesa 1.3 version string question... Texture compression was half way working some "months", ago. Taken from a post to Brian. [-] Re: [Dri-devel] Benchmarking with UT? Von: Dieter Nützel <[EMAIL PROTECTED]> An: Brian Paul <[EMAIL PROTECTED]> Kopie: "Dri-devel" <[EMAIL PROTECTED]> Am Donnerstag, 14. Dezember 2000 20:18 schrieben Sie: > Dieter Nützel wrote: > > Which resolution, window size (if not fullscreen :-) depth, etc. we are > > talking about? > > Fullscreen, at the resolutions and color depths I stated before. > > -Brian Here are some new Q3 benchmarks for the record. System was: AMD Athlon 550 SlotA (poor, the first generation, snif) MSI MS-6167 Rev. 1.0B (AMD Irongate C4, without bypass) 256 MB PC100 2-2-2 SDRAM Voodoo5 5500 AGP (only one VSA-100, no SLI/FSAA) Linux 2.4.0-test12 Glibc-2.2 DRI CVS tdfx-3-0-0-branch (Mesa DRI Voodoo4 20001214) Mesa with 3DNow! but Glide3 without (because of texture bug) [-] SunWave1>./glinfo GL_VERSION: 1.2 Mesa 3.4 GL_EXTENSIONS: GL_ARB_multitexture GL_ARB_texture_compression GL_ARB_tranpose_matrix GL_EXT_abgr GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_object GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_HP_occlusion_test GL_MESA_window_pos GL_MESA_resize_buffers GL_NV_texgen_reflection GL_PGI_misc_hints GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_pixel_texture GL_SGIS_texture_edge_clamp GL_SGIX_pixel_texture GL_3DFX_texture_compression_FXT1 GL_RENDERER: Mesa DRI Voodoo4 20001214 GL_VENDOR: VA Linux Systems, Inc. GLU_VERSION: 1.1 Mesa 3.3 GLU_EXTENSIONS: GL_EXT_abgr GLUT_API_VERSION: 3 GLUT_XLIB_IMPLEMENTATION: 15 [-] Compare this too the current version. Mesa/demos> ./glinfo GL_VERSION: 1.2 Mesa 4.0.3 GL_EXTENSIONS: GL_ARB_multitexture GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_bgra GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_texture3D GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_object GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_HP_occlusion_test GL_IBM_rasterpos_clip GL_MESA_window_pos GL_NV_texgen_reflection GL_RENDERER: Mesa DRI 20020221 Voodoo4 x86/MMX/3DNow! GL_VENDOR: VA Linux Systems, Inc. GLU_VERSION: 1.3 GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess GLUT_API_VERSION: 3 GLUT_XLIB_IMPLEMENTATION: 15 Should I rollback my tree to the Mesa DRI Voodoo4 20001214 version and try to integrate the 3DFX_texture_compression_FXT1 extention? Thanks, Dieter BTW There is someone complaining about the "broken" tdfx driver in the DRI devel list from time to time. If he have to say something he should speak up. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk: tdfx, textures are all blue and mostly invisible
On Tuesday 04 June 2002 14:32, Michel Dänzer wrote: > On Tue, 2002-06-04 at 06:12, Dieter Nützel wrote: > > I checked out the latest trunk update and found that the textures are > > broken, now. They are mostly invisible and blue. > > > > Maybe I have some compiler/optimization problems because I'm testing some > > better gcc flags for the Athlon. > > > > -O -mcpu=i686 -march=i686 -fno-gcse -fno-regmove -fomit-frame-pointer > > -mpreferred-stack-boundary=2 > > > > All stuff is working and fast except of the textures (the only thing that > > changed in the tree apart from the Radeon stuff). > > Should be fixed now (tested r128 on the Athlon box at work, it was also > broken by my last changes), the problem was that __BIG_ENDIAN is also > defined on little endian. > > I'm not sure if this fix will build on all Mesa platforms though, maybe > we'll have to introduce something like Xarch.h. OK, thank's Michel. Back to normal. -Dieter ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Status of AMD 760MP + Radeon lockups?
On Tue, 4 Jun 2002, hy0 wrote:
> Thanks for digging into this problem.
> Here are a few more things to try according to your feedback.
I again tried all your suggestions at once, and the lockup still ocurred.
[If it had stopped, I would have done a binary search on the changes.]
I should make some general comments on my set up, in case I am doing
something wrong. I have a stock RedHat 7.3 installation, except my kernel
is 2.5.20-dj2. I built and installed XFree86 from CVS with
#define ProjectRoot /usr/X11R6-CVS
#define NothingOutsideProjectRoot YES
#define EtcX11Directory ProjectRoot/etc
in xc/config/cf/site.def. Then I changed the link /usr/X11R6/bin/X to
point to /usr/X11R6-CVS/bin/XFree86. So I am running gdm from RedHat 7.3,
but it runs the new XFree86.
I noticed something else new. Namely, my test now consists of starting
gdm, switching to the 1st console, and switching back. With the patched
CVS XFree86, when I do this, the screen first shows the prior screen with
a box of garbage, then the background is redrawn (and the gdm window is
blank), then the gdm window is redrawn. I am even able to type in a few
characters to gdm, and only then does X lock up. From the XFree86.0.log
file (below), it looks as if the point of lockup is the point at which
drmRadeonWaitForIdleCP() starts returning -1022 instead of 0.
With the stock RedHat 7.3 XFree86, X locks up just after showing the prior
screen with the garbage box (and the garbage box is a different size and
location). I didn't test the unpatched XFree86 CVS, although if you like,
I could do that, and if it behaves differently from the patched XFree86
CVS, I could do a binary search on the difference until I find out what
explains the difference.
Anyway, that's the current scoop. If you like, I'll be able to try more
changes until Saturday, after that I'm going to swapping out this Tyan
S2460 motherboard.
Below is first the full diff between the my current patched XFree86 and
the version I grabbed from CVS, then the XFree86.0.log from the above
test.
Cheers,
Wayne
P.S. It's not so important, but for some reason with the XFree86 CVS, my
gnome-terminals come up with the wrong background color (black instead of
off-white) and the colors in xosview are all wrong.
diff -u radeon_accel.c.~1.25.~ radeon_accel.c
--- radeon_accel.c.~1.25.~ Wed Apr 24 09:20:39 2002
+++ radeon_accel.c Tue Jun 4 11:48:23 2002
@@ -191,11 +191,13 @@
intret;
inti= 0;
-FLUSH_RING();
+RADEONTRACE(("RADEONCPWaitForIdle: Skipping FLUSH_RING()\n"));
+/* FLUSH_RING(); */
for (;;) {
do {
ret = drmRadeonWaitForIdleCP(info->drmFD);
+ RADEONTRACE(("RADEONCPWaitForIdle: drmRadeonWaitForIdleCP returned %d\n",
+ret));
if (ret && ret != -EBUSY) {
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"%s: CP idle %d\n", __FUNCTION__, ret);
@@ -1572,6 +1574,9 @@
/* Sync */
a->Sync = RADEONCPWaitForIdle;
+/* Disable 2D Acceleration */
+return;
+
/* Solid Filled Rectangle */
a->PolyFillRectSolidFlags = 0;
a->SetupForSolidFill= RADEONCPSetupForSolidFill;
diff -u radeon_dri.c.~1.16.~ radeon_dri.c
--- radeon_dri.c.~1.16.~Wed Apr 24 09:20:40 2002
+++ radeon_dri.cTue Jun 4 11:18:16 2002
@@ -795,6 +795,14 @@
mode, vendor, device,
info->PciInfo->vendor,
info->PciInfo->chipType);
+
+mode = 0x1f000201;
+
+xf86DrvMsg(pScreen->myNum, X_INFO,
+ "[agp] Mode 0x%08lx [AGP 0x%04x/0x%04x; Card 0x%04x/0x%04x]\n",
+ mode, vendor, device,
+ info->PciInfo->vendor,
+ info->PciInfo->chipType);
if (drmAgpEnable(info->drmFD, mode) < 0) {
xf86DrvMsg(pScreen->myNum, X_ERROR, "[agp] AGP not enabled\n");
diff -u radeon_driver.c.~1.56.~ radeon_driver.c
--- radeon_driver.c.~1.56.~ Tue May 14 13:02:34 2002
+++ radeon_driver.c Tue Jun 4 11:19:58 2002
@@ -4188,7 +4188,7 @@
}
/* Define PLL registers for requested video mode */
-static void RADEONInitPLLRegisters(RADEONSavePtr save, RADEONPLLPtr pll,
+static void RADEONInitPLLRegisters(ScrnInfoPtr pScrn, RADEONSavePtr save,
+RADEONPLLPtr pll,
double dot_clock)
{
unsigned long freq = dot_clock * 100;
@@ -4240,7 +4240,7 @@
}
/* Define PLL2 registers for requested video mode */
-static void RADEONInitPLL2Registers(RADEONSavePtr save, RADEONPLLPtr pll,
+static void RADEONInitPLL2Registers(ScrnInfoPtr pScrn, RADEONSavePtr save,
+RADEONPLLPtr pll,
double dot_clock)
{
unsigned long freq = dot_clock * 100;
@@ -4360,14 +4360,14 @@
if (!RADEONInitCrtc2Registers(pScrn, save,
pScrn->currentMode,info))
RE: [Dri-devel] 8500 Drivers
> First, I took a look at the current radeon source, > but if someone could explain me what the ringbuffer > and the freelist are, i think i would at least > be able to imagine something of what's supposed to happen. Maybe you should start reading about advanced c programming technics first? (Okay, Pascal will do the job as well.) advanced here means programming with mutexes, semaphores, interrupts, object handles, buffering, chaching, memory management and all that makes up a true multitasking OS. Of course you can still do a good job at open source movement, even if you have only standard c knowledge in the beginning. But i will explain for you below... ringbuffer = fifo alike object in contiguous memory range, written by a pointer an read by a second pointer, the pointers are moving in only one direction and are wrapped at some limit, having both pointer the same value means buffer empty and write pointe one before read pointer means buffer full, most famous representative of ringbuffer is a keyboard buffer, in terms of grafics the buffer is read by the grafics adapter and filled in with commands or data by the host cpu. freelist = (i dont know exactly, not watched that source), maybe here its just a memory manager that contains a list of linked pointers to account chunks of memory that is free for usage in the system, when to free objects are adjancent then they get merged, when there is a memory request that requires less than the object provides then the object is split according to the request, possible applications are GART ranges, mem pools, texture mem, offscreen heap. If you want to understand some particular hardware programming you will be in need for the chip documentation or at least for someone who explains the main concepts of the participating devices that specific area. Regards Alex. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk: tdfx, textures are all blue and mostlyinvisible
On Tue, 2002-06-04 at 06:12, Dieter Nützel wrote: > > I checked out the latest trunk update and found that the textures are broken, > now. They are mostly invisible and blue. > > Maybe I have some compiler/optimization problems because I'm testing some > better gcc flags for the Athlon. > > -O -mcpu=i686 -march=i686 -fno-gcse -fno-regmove -fomit-frame-pointer > -mpreferred-stack-boundary=2 > > All stuff is working and fast except of the textures (the only thing that > changed in the tree apart from the Radeon stuff). Should be fixed now (tested r128 on the Athlon box at work, it was also broken by my last changes), the problem was that __BIG_ENDIAN is also defined on little endian. I'm not sure if this fix will build on all Mesa platforms though, maybe we'll have to introduce something like Xarch.h. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk: tdfx, textures are all blue and mostlyinvisible
On Tue, 2002-06-04 at 06:12, Dieter Nützel wrote: > > I checked out the latest trunk update and found that the textures are broken, > now. They are mostly invisible and blue. > > Maybe I have some compiler/optimization problems because I'm testing some > better gcc flags for the Athlon. > > -O -mcpu=i686 -march=i686 -fno-gcse -fno-regmove -fomit-frame-pointer > -mpreferred-stack-boundary=2 > > All stuff is working and fast except of the textures (the only thing that > changed in the tree apart from the Radeon stuff). Did my changes break this? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
