Re: [PATCH] r300 ia64 fixes
On Tuesday, March 08, 2005 4:24 pm, Paul Mackerras wrote: > Jesse Barnes writes: > > Anyone have a preference on this stuff? Should we remove the checks > > altogether or just the ones against the highmem variable? If we did the > > latter, we could remove the #ifdefs altogether, though I'm not sure how > > useful that check is--seems like we'd run into trouble elsewhere if we > > got a bad address anyway... > > My preference would be to remove the check altogether. Mine too, Dave, maybe you could check that one in (r300-ia64-fixes-3.patch)? How about the new virt_to_bus usage? That'll be a problem on ppc as well... Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage dri does not resume from disk
Alex Deucher <[EMAIL PROTECTED]> writes: > radeon has support for suspect resume as well. you need to add pm > hooks into your agp module to re-initialize it on resume (some agp > drivers may already have this). you also need to re-init the video > hardware properly. the radeon DDX does this in the enter/leaveVT > functions. this page may be of help: > http://cpbotha.net/dri_resume.html > The Xv stuff may need resume support too. there is a problem with the radeon resume though. on my thinkpad t40, running glxgears the frame rate drops from about 3300 to 3000 and if i run more graphics intensive applications (like flightgear for example) they are noticeably slower and feel choppy. restarting the x server cures the problem, so i think this has something to do with how the hardware is being re-initialized on resume but i don't know how to debug it. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300 ia64 fixes
Jesse Barnes writes: > Anyone have a preference on this stuff? Should we remove the checks > altogether or just the ones against the highmem variable? If we did the > latter, we could remove the #ifdefs altogether, though I'm not sure how > useful that check is--seems like we'd run into trouble elsewhere if we got a > bad address anyway... My preference would be to remove the check altogether. Paul. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] R300 texture format updates
I have updated the table of texture formats in r300_texstate.c based
on the definitions and comments in Mesa/src/mesa/main/texformat.h.
These changes assume that radeon_cp_dispatch_texture doesn't
byte-swap, i.e. that the patch I just posted has been applied.
I have tested formats 1, 13, 16 and 17 on big-endian. The patch below
adds what I think should be the correct definitions for little-endian
as well, but they are untested. I think the line for
MESA_FORMAT_ARGB for little-endian is wrong but I didn't change
it.
With this patch, pinball and chromium display correctly, tuxracer
displays mostly correctly except that the ice still looks a bit wrong,
and bzflag displays mostly correctly (some of the smaller characters
in the HUD seem to display the wrong background in their rectangle
though).
Paul.
diff -urN cvs/r300_driver/r300/r300_texstate.c r300_driver/r300/r300_texstate.c
--- cvs/r300_driver/r300/r300_texstate.c2005-03-07 08:21:34.0
+1100
+++ r300_driver/r300/r300_texstate.c2005-03-08 19:41:01.0 +1100
@@ -104,46 +104,52 @@
* should better find a way to ask the hardware to do the swapping.
* Jerome Glisse
*/
- {R300_EASY_TX_FORMAT(Y, Z, W, X, W8Z8Y8X8), 0},
- {R300_EASY_TX_FORMAT(Z, Y, X, W, W8Z8Y8X8), 0},
- {0xff02, 0},
- {0xff03, 0},
- {0xff04, 0},
- {0xff05, 0},
- {0xff06, 0},
- {0xff07, 0},
- {0xff08, 0},
- {0xff09, 0},
- {0xff10, 0},
- {0xff11, 0},
- {R300_EASY_TX_FORMAT(Y, Y, Y, X, Y8X8), 0},
- {0xff13, 0},
- {0xff14, 0},
- {R300_EASY_TX_FORMAT(X, X, X, X, X8), 0},
- {0xff16, 0},
- {0xff17, 0},
- };
+ {R300_EASY_TX_FORMAT(Z, Y, X, W, W8Z8Y8X8), 0}, // MESA_FORMAT_RGBA
+ {R300_EASY_TX_FORMAT(Y, Z, W, X, W8Z8Y8X8), 0}, //
MESA_FORMAT_RGBA_REV
+ {R300_EASY_TX_FORMAT(W, Z, Y, X, W8Z8Y8X8), 0}, // MESA_FORMAT_ARGB
+ {R300_EASY_TX_FORMAT(X, Y, Z, W, W8Z8Y8X8), 0}, //
MESA_FORMAT_ARGB_REV
+ {0xff04, 0},// MESA_FORMAT_RGB888 - how do we do 3
bytes/elt?
+ {0xff05, 0},// MESA_FORMAT_BGR888 - how do we do 3
bytes/elt?
+ {0xff06, 0},// MESA_FORMAT_RGB565
+ {R300_EASY_TX_FORMAT(X, Y, Z, ONE, Z5Y6X5), 0}, //
MESA_FORMAT_RGB565_REV
+ {R300_EASY_TX_FORMAT(Z, W, X, Y, W4Z4Y4X4), 0}, // MESA_FORMAT_ARGB
+ {R300_EASY_TX_FORMAT(X, Y, Z, W, W4Z4Y4X4), 0}, //
MESA_FORMAT_ARGB_REV
+ {0xff10, 0},// MESA_FORMAT_ARGB1555
+ {0xff11, 0},// MESA_FORMAT_ARGB1555_REV
+ {R300_EASY_TX_FORMAT(X, X, X, Y, Y8X8), 0}, // MESA_FORMAT_AL88
+ {R300_EASY_TX_FORMAT(Y, Y, Y, X, Y8X8), 0}, // MESA_FORMAT_AL88_REV
+ {R300_EASY_TX_FORMAT(X, Y, Z, ONE, Z3Y3X2), 0}, // MESA_FORMAT_RGB332
+ {R300_EASY_TX_FORMAT(ZERO, ZERO, ZERO, X, X8), 0}, // MESA_FORMAT_A8
+ {R300_EASY_TX_FORMAT(X, X, X, ONE, X8), 0}, // MESA_FORMAT_L8
+ {R300_EASY_TX_FORMAT(X, X, X, X, X8), 0}, // MESA_FORMAT_I8
+ {0xff18, 0},// MESA_FORMAT_CI8
+ {0xff19, 0},// MESA_FORMAT_YCBCR
+ {0xff20, 0},// MESA_FORMAT_YCBCR_REV
+
#else
- {R300_EASY_TX_FORMAT(Y, Z, W, X, W8Z8Y8X8), 0},
- {0xff01, 0},
- {0xff02, 0},
- {0xff03, 0},
- {0xff04, 0},
- {0xff05, 0},
- {R300_EASY_TX_FORMAT(X, Y, Z, ONE, Z5Y6X5), 0},
- {0xff07, 0},
- {R300_EASY_TX_FORMAT(Y, Z, W, X, W4Z4Y4X4), 0},
- {0xff09, 0},
- {0xff10, 0},
- {0xff11, 0},
- {R300_EASY_TX_FORMAT(Y, Y, Y, X, Y8X8), 0},
- {0xff13, 0},
- {0xff14, 0},
- {R300_EASY_TX_FORMAT(X, X, X, X, X8), 0},
- {0xff16, 0},
- {0xff17, 0},
- };
+ {R300_EASY_TX_FORMAT(Y, Z, W, X, W8Z8Y8X8), 0}, // MESA_FORMAT_RGBA
+ {R300_EASY_TX_FORMAT(Z, Y, X, W, W8Z8Y8X8), 0}, //
MESA_FORMAT_RGBA_REV
+ {R300_EASY_TX_FORMAT(X, Y, Z, W, W8Z8Y8X8), 0}, // MESA_FORMAT_ARGB
+ {R300_EASY_TX_FORMAT(W, Z, Y, X, W8Z8Y8X8), 0}, //
MESA_FORMAT_ARGB_REV
+ {0xff04, 0},// MESA_FORMAT_RGB888 - how do we do 3
bytes/elt?
+ {0xff05, 0},// MESA_FORMAT_BGR888 - how do we do 3
bytes/elt?
+ {R300_EASY_TX_FORMAT(X, Y, Z, ONE, Z5Y6X5), 0}, // MESA_FORMAT_RGB565
+ {0xff07, 0},// MESA_FORMAT_RGB565_REV
+ {R300_EASY_TX_FORMAT(Y, Z, W, X, W4Z4Y4X4), 0}, // MESA_FORMAT_ARGB
+ {R300_EASY_TX_FORMAT(Z, W, X, Y, W4Z4Y4X4), 0}, //
MESA_FORMAT_ARGB_REV
+ {0xff10, 0},// MESA_FORMAT_ARGB1555
+ {0xff11, 0},// MESA_FORMAT_ARGB1555_REV
+ {R300_EASY_
[PATCH] DRM texture dispatch using BITBLT_MULTI
I started looking into the issue of how we handle various texture
formats on R300 on big-endian machines. It became evident that
textures were getting byte-swapped on their way to the framebuffer.
Setting RADEON_HOST_DATA_SWAP_32BIT in RADEON_RBBM_GUICNTL doesn't
seem to have any effect on R300.
We can cope with the byte-swap for textures with 4 bytes/texel, but
not for textures with 2 or 1 byte/texel. So instead of using a
HOSTDATA_BLT in radeon_cp_dispatch_texture, I changed it to use a
BITBLT_MULTI. I still copy the texture into gart memory, but instead
of using an indirect buffer I just put the blit command into the ring
buffer. This avoids the byte swap that the CP does and gets the
texture to the framebuffer without being byte-swapped. It should be
just as fast this way as with the HOSTDATA_BLT.
The patch below implements this. With this patch we also need a patch
to the r300 client driver code, which I will post shortly.
Paul.
diff -urN cvs/r300_driver/drm/shared-core/radeon_state.c
r300_driver/drm/shared-core/radeon_state.c
--- cvs/r300_driver/drm/shared-core/radeon_state.c 2005-03-05
09:26:06.0 +1100
+++ r300_driver/drm/shared-core/radeon_state.c 2005-03-09 10:32:45.0
+1100
@@ -1471,7 +1471,7 @@
}
-#define RADEON_MAX_TEXTURE_SIZE (RADEON_BUFFER_SIZE - 8 * sizeof(u32))
+#define RADEON_MAX_TEXTURE_SIZE RADEON_BUFFER_SIZE
static int radeon_cp_dispatch_texture(DRMFILE filp,
drm_device_t * dev,
@@ -1488,6 +1488,7 @@
u32 height;
int i;
u32 texpitch, microtile;
+ u32 offset;
RING_LOCALS;
DRM_GET_PRIV_WITH_RETURN(filp_priv, filp);
@@ -1508,16 +1509,6 @@
RADEON_WAIT_UNTIL_IDLE();
ADVANCE_RING();
-#ifdef __BIG_ENDIAN
- /* The Mesa texture functions provide the data in little endian as the
-* chip wants it, but we need to compensate for the fact that the CP
-* ring gets byte-swapped
-*/
- BEGIN_RING(2);
- OUT_RING_REG(RADEON_RBBM_GUICNTL, RADEON_HOST_DATA_SWAP_32BIT);
- ADVANCE_RING();
-#endif
-
/* The compiler won't optimize away a division by a variable,
* even if the only legal values are powers of two. Thus, we'll
* use a shift instead.
@@ -1601,23 +1592,6 @@
buffer =
(u32 *) ((char *)dev->agp_buffer_map->handle + buf->offset);
dwords = size / 4;
- buffer[0] = CP_PACKET3(RADEON_CNTL_HOSTDATA_BLT, dwords + 6);
- buffer[1] = (RADEON_GMC_DST_PITCH_OFFSET_CNTL |
-RADEON_GMC_BRUSH_NONE |
-(format << 8) |
-RADEON_GMC_SRC_DATATYPE_COLOR |
-RADEON_ROP3_S |
-RADEON_DP_SRC_SOURCE_HOST_DATA |
-RADEON_GMC_CLR_CMP_CNTL_DIS |
-RADEON_GMC_WR_MSK_DIS);
-
- buffer[2] = (texpitch << 22) | (tex->offset >> 10);
- buffer[3] = 0x;
- buffer[4] = 0x;
- buffer[5] = (image->y << 16) | image->x;
- buffer[6] = (height << 16) | image->width;
- buffer[7] = dwords;
- buffer += 8;
if (microtile) {
/* texture micro tiling in use, minimum texture width
is thus 16 bytes.
@@ -1726,8 +1700,26 @@
}
buf->filp = filp;
- buf->used = (dwords + 8) * sizeof(u32);
- radeon_cp_dispatch_indirect(dev, buf, 0, buf->used);
+ buf->used = size;
+ offset = dev_priv->gart_buffers_offset + buf->offset;
+ BEGIN_RING(7);
+ OUT_RING(CP_PACKET3(RADEON_CNTL_BITBLT_MULTI, 5));
+ OUT_RING(RADEON_GMC_SRC_PITCH_OFFSET_CNTL |
+RADEON_GMC_DST_PITCH_OFFSET_CNTL |
+RADEON_GMC_BRUSH_NONE |
+(format << 8) |
+RADEON_GMC_SRC_DATATYPE_COLOR |
+RADEON_ROP3_S |
+RADEON_DP_SRC_SOURCE_MEMORY |
+RADEON_GMC_CLR_CMP_CNTL_DIS |
+RADEON_GMC_WR_MSK_DIS );
+ OUT_RING((texpitch << 22) | (offset >> 10));
+ OUT_RING((texpitch << 22) | (tex->offset >> 10));
+ OUT_RING(0);
+ OUT_RING((image->x << 16) | image->y);
+ OUT_RING((image->width << 16) | height);
+ ADVANCE_RING();
+
radeon_cp_discard_buffer(dev, buf);
/* Update the input parameters for next time */
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osd
[Bug 788] Display Artifacts at 1680x1050
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=788 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 15:43 --- fixed in xorg cvs head. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage dri does not resume from disk
On Wed, 09 Mar 2005 00:31:02 +0100, Felix Kühling <[EMAIL PROTECTED]> wrote: > Am Mittwoch, den 09.03.2005, 02:08 +0300 schrieb Sergey Zharkov: > > Felix, > > > > Sorry for reporting bug on this address - just culd not find any place t > > report for DRI, and you seems to be the only man who actually program > > the driver. > > The DRI developers list is [EMAIL PROTECTED] Savage > issues can also be discussed at [EMAIL PROTECTED], which is a moderated > list. > > > I've recently moved from Savage DRM 1.x to 2.x from cvs > > with kernel 2.6.11 - I've received 10% increase in speed, quality of > > rendering looks better as well (i got rid of some ugly artifacts on my > > favorite SeriousSam game) - the only thing DRI does not resume from disk > > anymore. It resumes from memory (acpi state S3) fine, but when I resume > > from disk even having no apps using DRI during suspend-resume, each time > > I try to start 3D application everything hangs and the only chance I > > have is to switch power off. Just curious are you aware about this - may > > be you have any idea how to make resume from disk working again, > > Not really. Resume from disk was only half working for me with DRM 1.x. > It locked up after some time with more demanding applications. I was > guessing that it locked up whenever the driver started using AGP > textures, but I never looked into it more seriously. > > With the new driver I have never tried resume from disk, and I don't > know what would be needed to make it work. I'm CCing to dri-devel. Can > someone give me a brief summary what a driver needs to support resume > from disk? I seem to remember that i915 and unichrome saw changes in > that area in the last months. radeon has support for suspect resume as well. you need to add pm hooks into your agp module to re-initialize it on resume (some agp drivers may already have this). you also need to re-init the video hardware properly. the radeon DDX does this in the enter/leaveVT functions. this page may be of help: http://cpbotha.net/dri_resume.html The Xv stuff may need resume support too. Alex > > > > > The hardware is Twinhead Efio 121A, KN266 based laptop > > > > > > Thank you > > > > Sergey > > > -- > | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | > | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | > --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage dri does not resume from disk
Am Mittwoch, den 09.03.2005, 02:08 +0300 schrieb Sergey Zharkov: > Felix, > > Sorry for reporting bug on this address - just culd not find any place t > report for DRI, and you seems to be the only man who actually program > the driver. The DRI developers list is [EMAIL PROTECTED] Savage issues can also be discussed at [EMAIL PROTECTED], which is a moderated list. > I've recently moved from Savage DRM 1.x to 2.x from cvs > with kernel 2.6.11 - I've received 10% increase in speed, quality of > rendering looks better as well (i got rid of some ugly artifacts on my > favorite SeriousSam game) - the only thing DRI does not resume from disk > anymore. It resumes from memory (acpi state S3) fine, but when I resume > from disk even having no apps using DRI during suspend-resume, each time > I try to start 3D application everything hangs and the only chance I > have is to switch power off. Just curious are you aware about this - may > be you have any idea how to make resume from disk working again, Not really. Resume from disk was only half working for me with DRM 1.x. It locked up after some time with more demanding applications. I was guessing that it locked up whenever the driver started using AGP textures, but I never looked into it more seriously. With the new driver I have never tried resume from disk, and I don't know what would be needed to make it work. I'm CCing to dri-devel. Can someone give me a brief summary what a driver needs to support resume from disk? I seem to remember that i915 and unichrome saw changes in that area in the last months. > > The hardware is Twinhead Efio 121A, KN266 based laptop > > > Thank you > > Sergey > -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 788] Display Artifacts at 1680x1050
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=788 --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 14:14 --- (In reply to comment #15) > Ignoring tiling, the strictest restriction for the pitch I can find in the > specs > is that it has to be a multiple of 64 bytes (I think even multiples of 32 > should > work, but the dedicated pitch registers (as opposed to the combined > offset/pitch > ones) probably need to be used for that). Where do the 64 pixels come from? That's a very good question. No idea. Those validatemode functions which do not call xf86ValidateModes in fact only request a pitch of 64bytes (for 32bit and 16bit) and 128bytes (for 8bit modes). And in fact, I _did_ adjust this RadeonSetPitch function to work correctly with color tiling, so this ought to work (phew!). This only leaves the original problem (e.g. without color tiling, depth pitch must be adjusted). I'll fix that in a minute. Maybe the requested pitchInc for xf86ValidateModes is indeed more restrictive than necessary, but I'm certainly not going to touch that... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300 ia64 fixes
On Tuesday, March 8, 2005 12:24 pm, Jesse Barnes wrote: > On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote: > > On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote: > > > Here are a few small fixes to get r300 going on ia64. Thanks to > > > Stephane for pointing out the resource size mismatch. The patch just > > > fixes that (PCI resources in Linux are 'unsigned long' at the moment, > > > not 'unsigned int') and adds the checking for write combining regions I > > > posted earlier since I don't think that's been applied. > > > > > > Thanks, > > > Jesse > > > > Or another one that removes the silly overflow and 'offset within real > > memory' checks altogether. Take your pick as to which should be applied > > :) > > Anyone have a preference on this stuff? Should we remove the checks > altogether or just the ones against the highmem variable? If we did the > latter, we could remove the #ifdefs altogether, though I'm not sure how > useful that check is--seems like we'd run into trouble elsewhere if we got > a bad address anyway... Oh, and these fixes, regardless of what they are, should go into the main drm tree not the r300 branch, since they're not related to the r300 stuff at all (IOW I can't commit them). Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300 ia64 fixes
On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote: > On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote: > > Here are a few small fixes to get r300 going on ia64. Thanks to Stephane > > for pointing out the resource size mismatch. The patch just fixes that > > (PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned > > int') and adds the checking for write combining regions I posted earlier > > since I don't think that's been applied. > > > > Thanks, > > Jesse > > Or another one that removes the silly overflow and 'offset within real > memory' checks altogether. Take your pick as to which should be applied :) Anyone have a preference on this stuff? Should we remove the checks altogether or just the ones against the highmem variable? If we did the latter, we could remove the #ifdefs altogether, though I'm not sure how useful that check is--seems like we'd run into trouble elsewhere if we got a bad address anyway... Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300 warning fixes
On Tuesday, March 8, 2005 10:43 am, Jesse Barnes wrote: > This small patch fixes some warnings I saw when building on ia64. I think > it's safe to apply. It just moves some of the RING_LOCALS macros to below > the local stack variables to avoid "mixing code & declarations" warnings > and adds vmalloc.h to drm_memory.h so that the vmalloc related stuff gets > pulled in. Just committed this to r300 cvs. Jesse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] Current(3/8/05) xorg/r300 cvs PPC issues
Hi, Ok currently I've noticed the following issues: 1) Xv Color issues 2) Text rendering problems in mozilla 3) Textures in 3d apps are upside down and show 4copies when there should be one. Let me know If you need more details. -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300 ia64 fixes
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
> Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
> for pointing out the resource size mismatch. The patch just fixes that
> (PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned
> int') and adds the checking for write combining regions I posted earlier
> since I don't think that's been applied.
>
> Thanks,
> Jesse
Or another one that removes the silly overflow and 'offset within real memory'
checks altogether. Take your pick as to which should be applied :)
Thanks,
Jesse
Index: drm/linux-core/drmP.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drmP.h,v
retrieving revision 1.2
diff -u -p -r1.2 drmP.h
--- drm/linux-core/drmP.h 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drmP.h 8 Mar 2005 19:03:03 -
@@ -55,6 +55,9 @@
#include /* For (un)lock_kernel */
#include
#include
+#ifdef __ia64__
+#include
+#endif
#if defined(__alpha__) || defined(__powerpc__)
#include/* For pte_wrprotect */
#endif
@@ -850,7 +853,7 @@ extern int drm_addmap(struct inode *inod
unsigned int cmd, unsigned long arg);
extern int drm_rmmap(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_initmap(drm_device_t * dev, unsigned int offset,
+extern int drm_initmap(drm_device_t * dev, unsigned long offset,
unsigned int size, unsigned int resource, int type,
int flags);
extern int drm_addbufs(struct inode *inode, struct file *filp,
Index: drm/linux-core/drm_bufs.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_bufs.c,v
retrieving revision 1.2
diff -u -p -r1.2 drm_bufs.c
--- drm/linux-core/drm_bufs.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_bufs.c 8 Mar 2005 19:03:03 -
@@ -53,7 +53,7 @@ EXPORT_SYMBOL(drm_get_resource_len);
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
* applicable and if supported by the kernel.
*/
-int drm_initmap(drm_device_t * dev, unsigned int offset, unsigned int size,
+int drm_initmap(drm_device_t * dev, unsigned long offset, unsigned int size,
unsigned int resource, int type, int flags)
{
drm_map_t *map;
@@ -63,10 +63,6 @@ int drm_initmap(drm_device_t * dev, unsi
if ((offset & (~PAGE_MASK)) || (size & (~PAGE_MASK)))
return -EINVAL;
-#if !defined(__sparc__) && !defined(__alpha__)
- if (offset + size < offset || offset < virt_to_phys(high_memory))
- return -EINVAL;
-#endif
if (!(list = drm_alloc(sizeof(*list), DRM_MEM_MAPS)))
return -ENOMEM;
memset(list, 0, sizeof(*list));
@@ -198,13 +194,6 @@ int drm_addmap(struct inode *inode, stru
/* addmap didn't match an existing permanent
map, that's an error */
return -EINVAL;
}
-#if !defined(__sparc__) && !defined(__alpha__) && !defined(__ia64__)
- if (map->offset + map->size < map->offset ||
- map->offset < virt_to_phys(high_memory)) {
- drm_free(map, sizeof(*map), DRM_MEM_MAPS);
- return -EINVAL;
- }
-#endif
#ifdef __alpha__
map->offset += dev->hose->mem_space->start;
#endif
Index: drm/linux-core/drm_vm.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_vm.c,v
retrieving revision 1.2
diff -u -p -r1.2 drm_vm.c
--- drm/linux-core/drm_vm.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_vm.c 8 Mar 2005 19:03:03 -
@@ -639,9 +639,13 @@ int drm_mmap(struct file *filp, struct v
vma->vm_flags |= VM_IO; /* not in core dump */
}
#if defined(__ia64__)
- if (map->type != _DRM_AGP)
+ if (efi_range_is_wc(vma->vm_start, vma->vm_end -
+ vma->vm_start) && (map->type != _DRM_AGP))
vma->vm_page_prot =
- pgprot_writecombine(vma->vm_page_prot);
+ pgprot_writecombine(vma->vm_page_prot);
+ else
+ vma->vm_page_prot =
+ pgprot_noncached(vma->vm_page_prot);
#endif
offset = dev->driver->get_reg_ofs(dev);
#ifdef __sparc__
Re: [PATCH] r300 ia64 fixes
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
> Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
> for pointing out the resource size mismatch. The patch just fixes that
> (PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned
> int') and adds the checking for write combining regions I posted earlier
> since I don't think that's been applied.
Here's a more complete patch that fixes up some ppc stuff as well.
Jesse
Index: drm/linux-core/drmP.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drmP.h,v
retrieving revision 1.2
diff -u -p -r1.2 drmP.h
--- drm/linux-core/drmP.h 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drmP.h 8 Mar 2005 19:00:54 -
@@ -55,6 +55,9 @@
#include /* For (un)lock_kernel */
#include
#include
+#ifdef __ia64__
+#include
+#endif
#if defined(__alpha__) || defined(__powerpc__)
#include/* For pte_wrprotect */
#endif
@@ -850,7 +853,7 @@ extern int drm_addmap(struct inode *inod
unsigned int cmd, unsigned long arg);
extern int drm_rmmap(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_initmap(drm_device_t * dev, unsigned int offset,
+extern int drm_initmap(drm_device_t * dev, unsigned long offset,
unsigned int size, unsigned int resource, int type,
int flags);
extern int drm_addbufs(struct inode *inode, struct file *filp,
Index: drm/linux-core/drm_bufs.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_bufs.c,v
retrieving revision 1.2
diff -u -p -r1.2 drm_bufs.c
--- drm/linux-core/drm_bufs.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_bufs.c 8 Mar 2005 19:00:54 -
@@ -53,7 +53,7 @@ EXPORT_SYMBOL(drm_get_resource_len);
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
* applicable and if supported by the kernel.
*/
-int drm_initmap(drm_device_t * dev, unsigned int offset, unsigned int size,
+int drm_initmap(drm_device_t * dev, unsigned long offset, unsigned int size,
unsigned int resource, int type, int flags)
{
drm_map_t *map;
@@ -63,7 +63,7 @@ int drm_initmap(drm_device_t * dev, unsi
if ((offset & (~PAGE_MASK)) || (size & (~PAGE_MASK)))
return -EINVAL;
-#if !defined(__sparc__) && !defined(__alpha__)
+#if !defined(__sparc__) && !defined(__alpha__) && !defined(__ia64__) &&
!defined(__powerpc__)
if (offset + size < offset || offset < virt_to_phys(high_memory))
return -EINVAL;
#endif
@@ -198,7 +198,7 @@ int drm_addmap(struct inode *inode, stru
/* addmap didn't match an existing permanent
map, that's an error */
return -EINVAL;
}
-#if !defined(__sparc__) && !defined(__alpha__) && !defined(__ia64__)
+#if !defined(__sparc__) && !defined(__alpha__) && !defined(__ia64__) &&
!defined(__powerpc__)
if (map->offset + map->size < map->offset ||
map->offset < virt_to_phys(high_memory)) {
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
Index: drm/linux-core/drm_vm.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_vm.c,v
retrieving revision 1.2
diff -u -p -r1.2 drm_vm.c
--- drm/linux-core/drm_vm.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_vm.c 8 Mar 2005 19:00:54 -
@@ -639,9 +639,13 @@ int drm_mmap(struct file *filp, struct v
vma->vm_flags |= VM_IO; /* not in core dump */
}
#if defined(__ia64__)
- if (map->type != _DRM_AGP)
+ if (efi_range_is_wc(vma->vm_start, vma->vm_end -
+ vma->vm_start) && (map->type != _DRM_AGP))
vma->vm_page_prot =
- pgprot_writecombine(vma->vm_page_prot);
+ pgprot_writecombine(vma->vm_page_prot);
+ else
+ vma->vm_page_prot =
+ pgprot_noncached(vma->vm_page_prot);
#endif
offset = dev->driver->get_reg_ofs(dev);
#ifdef __sparc__
[PATCH] r300 ia64 fixes
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane for
pointing out the resource size mismatch. The patch just fixes that (PCI
resources in Linux are 'unsigned long' at the moment, not 'unsigned int') and
adds the checking for write combining regions I posted earlier since I don't
think that's been applied.
Thanks,
Jesse
Index: drm/linux-core/drmP.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drmP.h,v
retrieving revision 1.2
diff -u -r1.2 drmP.h
--- drm/linux-core/drmP.h 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drmP.h 8 Mar 2005 18:40:03 -
@@ -55,6 +55,9 @@
#include /* For (un)lock_kernel */
#include
#include
+#ifdef __ia64__
+#include
+#endif
#if defined(__alpha__) || defined(__powerpc__)
#include/* For pte_wrprotect */
#endif
@@ -850,7 +853,7 @@
unsigned int cmd, unsigned long arg);
extern int drm_rmmap(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_initmap(drm_device_t * dev, unsigned int offset,
+extern int drm_initmap(drm_device_t * dev, unsigned long offset,
unsigned int size, unsigned int resource, int type,
int flags);
extern int drm_addbufs(struct inode *inode, struct file *filp,
Index: drm/linux-core/drm_bufs.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_bufs.c,v
retrieving revision 1.2
diff -u -r1.2 drm_bufs.c
--- drm/linux-core/drm_bufs.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_bufs.c 8 Mar 2005 18:40:03 -
@@ -53,7 +53,7 @@
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
* applicable and if supported by the kernel.
*/
-int drm_initmap(drm_device_t * dev, unsigned int offset, unsigned int size,
+int drm_initmap(drm_device_t * dev, unsigned long offset, unsigned int size,
unsigned int resource, int type, int flags)
{
drm_map_t *map;
@@ -63,7 +63,7 @@
if ((offset & (~PAGE_MASK)) || (size & (~PAGE_MASK)))
return -EINVAL;
-#if !defined(__sparc__) && !defined(__alpha__)
+#if !defined(__sparc__) && !defined(__alpha__) && !defined(__ia64__)
if (offset + size < offset || offset < virt_to_phys(high_memory))
return -EINVAL;
#endif
Index: drm/linux-core/drm_vm.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_vm.c,v
retrieving revision 1.2
diff -u -r1.2 drm_vm.c
--- drm/linux-core/drm_vm.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_vm.c 8 Mar 2005 18:40:03 -
@@ -639,9 +639,13 @@
vma->vm_flags |= VM_IO; /* not in core dump */
}
#if defined(__ia64__)
- if (map->type != _DRM_AGP)
+ if (efi_range_is_wc(vma->vm_start, vma->vm_end -
+ vma->vm_start) && (map->type != _DRM_AGP))
vma->vm_page_prot =
- pgprot_writecombine(vma->vm_page_prot);
+ pgprot_writecombine(vma->vm_page_prot);
+ else
+ vma->vm_page_prot =
+ pgprot_noncached(vma->vm_page_prot);
#endif
offset = dev->driver->get_reg_ofs(dev);
#ifdef __sparc__
[PATCH] r300 warning fixes
This small patch fixes some warnings I saw when building on ia64. I think
it's safe to apply. It just moves some of the RING_LOCALS macros to below
the local stack variables to avoid "mixing code & declarations" warnings and
adds vmalloc.h to drm_memory.h so that the vmalloc related stuff gets pulled
in.
Thanks,
Jesse
Index: drm/linux-core/drm_memory.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_memory.h,v
retrieving revision 1.2
diff -u -r1.2 drm_memory.h
--- drm/linux-core/drm_memory.h 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_memory.h 8 Mar 2005 18:40:03 -
@@ -35,6 +35,7 @@
#include
#include
+#include
#include "drmP.h"
/**
Index: drm/shared/r300_cmdbuf.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.17
diff -u -r1.17 r300_cmdbuf.c
--- drm/shared/r300_cmdbuf.c3 Mar 2005 04:40:21 - 1.17
+++ drm/shared/r300_cmdbuf.c8 Mar 2005 18:40:03 -
@@ -58,10 +58,10 @@
drm_radeon_cmd_buffer_t* cmdbuf,
int n)
{
- RING_LOCALS;
drm_clip_rect_t box;
int nr;
int i;
+ RING_LOCALS;
nr = cmdbuf->nbox - n;
if (nr > R300_SIMULTANEOUS_CLIPRECTS)
@@ -242,9 +242,9 @@
drm_radeon_cmd_buffer_t* cmdbuf,
drm_r300_cmd_header_t header)
{
- RING_LOCALS;
int reg;
int sz;
+ RING_LOCALS;
sz = header.unchecked_state.count;
reg = (header.unchecked_state.reghi << 8) |
header.unchecked_state.reglo;
@@ -281,9 +281,9 @@
drm_radeon_cmd_buffer_t* cmdbuf,
drm_r300_cmd_header_t header)
{
- RING_LOCALS;
int sz;
int addr;
+ RING_LOCALS;
sz = header.vpu.count;
addr = (header.vpu.adrhi << 8) | header.vpu.adrlo;
@@ -344,9 +344,9 @@
static __inline__ int r300_emit_raw(drm_radeon_private_t* dev_priv,
drm_radeon_cmd_buffer_t* cmdbuf)
{
- RING_LOCALS;
unsigned int u;
int count;
+ RING_LOCALS;
if (4 > cmdbuf->bufsz)
return DRM_ERR(EINVAL);
Index: drm/shared-core/r300_cmdbuf.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.17
diff -u -r1.17 r300_cmdbuf.c
--- drm/shared-core/r300_cmdbuf.c 3 Mar 2005 04:40:21 - 1.17
+++ drm/shared-core/r300_cmdbuf.c 8 Mar 2005 18:40:03 -
@@ -58,10 +58,10 @@
drm_radeon_cmd_buffer_t* cmdbuf,
int n)
{
- RING_LOCALS;
drm_clip_rect_t box;
int nr;
int i;
+ RING_LOCALS;
nr = cmdbuf->nbox - n;
if (nr > R300_SIMULTANEOUS_CLIPRECTS)
@@ -242,9 +242,9 @@
drm_radeon_cmd_buffer_t* cmdbuf,
drm_r300_cmd_header_t header)
{
- RING_LOCALS;
int reg;
int sz;
+ RING_LOCALS;
sz = header.unchecked_state.count;
reg = (header.unchecked_state.reghi << 8) |
header.unchecked_state.reglo;
@@ -281,9 +281,9 @@
drm_radeon_cmd_buffer_t* cmdbuf,
drm_r300_cmd_header_t header)
{
- RING_LOCALS;
int sz;
int addr;
+ RING_LOCALS;
sz = header.vpu.count;
addr = (header.vpu.adrhi << 8) | header.vpu.adrlo;
@@ -344,9 +344,9 @@
static __inline__ int r300_emit_raw(drm_radeon_private_t* dev_priv,
drm_radeon_cmd_buffer_t* cmdbuf)
{
- RING_LOCALS;
unsigned int u;
int count;
+ RING_LOCALS;
if (4 > cmdbuf->bufsz)
return DRM_ERR(EINVAL);
Re: [R300] Problem with current cvs on PPC
Hi, Doh, sorry to waste everyones time. I installed cvs X over 6.8.1 and it was picking up some old stuff. I moved 6.8.1 and reinstall cvs and all is well. Now anything I can help test on PPC? Keith On Tue, 2005-03-08 at 16:40 +0100, Jerome Glisse wrote: > (WW) RADEON(0): Direct rendering not yet supported on Radeon 9500 and > newer cards > > seems you got a xorg 6.8.1 you should use lastest cvs xorg or at least > a 6.8.2 if my memory is rigth there have been change in xorg for r300 since > then and now i think that you need a 6.8.2 or a recent cvs checkout. > > For testing you could install a xorg cvs elsewhere than /usr/X11R6 > see build instruction of xorg to see how. > > Jerome Glisse > -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 788] Display Artifacts at 1680x1050
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=788 --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 09:01 --- Ignoring tiling, the strictest restriction for the pitch I can find in the specs is that it has to be a multiple of 64 bytes (I think even multiples of 32 should work, but the dedicated pitch registers (as opposed to the combined offset/pitch ones) probably need to be used for that). Where do the 64 pixels come from? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: more mesa-solo trouble w/r300 on ia64
On Tuesday, March 8, 2005 12:01 am, Vladimir Dergachev wrote: > Hi Jesse ! > > On Mon, 7 Mar 2005, Jesse Barnes wrote: > > Ok, so I've applied Stephane's fixes and sample_server comes up and > > miniglxtest no longer segfaults. However, after setting the mode, > > sample_server seems to die and wedge my display. miniglxtest just fails > > right away with this message: > > > > [EMAIL PROTECTED] miniglx]$ ./miniglxtest > > [miniglx] probed chipset 0x4e4b > > CreateNotify > > Authorize - magic 1 > > Unknown device ID 4E4B, please report. Assuming plain R300. > > ^ > > This is a bit odd - if the r300 driver does not know about the device why > does the DRM driver load ? > > Also, are you using the drm driver from r300.sf.net ? The message > below (error -22) might be indicative of wrong drm driver, try to insmod > it with explicit path, like this: > > insmod ./drm.ko > insmod ./radeon.ko Yeah, I'm using that driver and it seems to work ok with recent X.org bits (modulo some tiling issues that I saw--though sroland said that was to be expected on the particular tree I'm running). I'm updating my X tree now to see if that goes away. As for the solo stuff, Stephane suggested that I might have to port some of the X DDX bits to the solo driver code (mostly 2d & setup stuff I guess?), could that explain what I'm seeing? Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Problem with current cvs on PPC
On Tue, 8 Mar 2005, Jerome Glisse wrote: (WW) RADEON(0): Direct rendering not yet supported on Radeon 9500 and newer cards seems you got a xorg 6.8.1 you should use lastest cvs xorg or at least a 6.8.2 if my memory is rigth there have been change in xorg for r300 since then and now i think that you need a 6.8.2 or a recent cvs checkout. Actually I would suggest to just use X.org CVS, as the patch does not include some fixes for the mouse, also R300 pacification sequence is in a slightly more optimal place in X.org. Since with the patch one has to compile xc tree anyway, one could use X.org CVS just as well.. best Vladimir Dergachev For testing you could install a xorg cvs elsewhere than /usr/X11R6 see build instruction of xorg to see how. Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 788] Display Artifacts at 1680x1050
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=788 --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 08:04 --- (> > They are, but the radeon driver doesn't use xf86ValidateModes() in all cases but > > has some of its own validation functions. > I think they ALL call xf86ValidateModes though. Argh, that's apparently not true. This is sick, there are two dozens different validation routines, and they don't validate all the same things. So, I'll add that check back. However, these modes which are not going through the xf86ValidateModes validator and are thus not tested for a "valid" pitchInc are not going to work with color tiling. Since the pitchInc is 64 pixels even without color tiling, I'm wondering why those work at all? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Problem with current cvs on PPC
Hi, I tried loading drm w/o agpgart but in needs agpgart to load. Btw I actually replaced the old drm.ko with the r300 cvs version. So I don't think an old drm is causing any issues. Thanks Keith On Tue, 2005-03-08 at 12:45 +0100, Jerome Glisse wrote: > Do you have agpgart running before drm ? Try with & without > agpgart this maybe related to this. Moreover have you try to > do a reboot before trying lastest drm, old drm may put the > hardware in strange state (don't think so but i know to little > on that...) Thus maybe a reboot with loading the new drm > should help you. > > Anyone have any idea on that ? > > Jerome Glisse > > On Tue, 8 Mar 2005 12:23:59 +0100, Jerome Glisse <[EMAIL PROTECTED]> wrote: > > Finaly get 5min to test lastest cvs and it works "perfectly" > > here. Could you send me your xorg log file showing that > > dri is disable. > > > > Jerome Glisse > > > > On Mon, 07 Mar 2005 14:41:56 -0500, Keith Conger > > <[EMAIL PROTECTED]> wrote: > > > Hi Guys, > > > > > > Sorry should have noted this. As of the time of my intitial email is > > > when I checked out both Xorg r300_demo and r300_driver. > > > > > > Thanks > > > Keith > > > On Mon, 2005-03-07 at 19:04 +0100, Jerome Glisse wrote: > > > > Do you use lastest r300 CVS drm? There have been a huge > > > > update of r300 drm not so long ago. > > > > > > > > > > > > On Sun, 06 Mar 2005 13:46:22 -0500, Keith Conger > > > > <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > > > > > My Machine > > > > > Powerbook G4 > > > > > ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 64MB > > > > > Ubuntu Hoary (kernel 2.6.10) > > > > > > > > > > The drm module doesn't seem to work any longer for me. Drm loads > > > > > without > > > > > error but I don't get the normal microcode message. r300_demo now seg > > > > > faults when it runs, X doesn't seem to want to enable the dri. One > > > > > thing > > > > > I noticed is lspci seems to indicate a have 128MB or video ram when I > > > > > only have 64. > > > > > > > > lspci indicate 64 before ? Could you test with a previous CVS version > > > > (say one week ago). > > > > > > > > Jerome Glisse > > > > > > > -- > > > > > > Keith Conger > > > [EMAIL PROTECTED] > > > http://pimpstation.org > > > > > > > > > -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 788] Display Artifacts at 1680x1050
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=788 --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 07:40 --- (In reply to comment #12) > (In reply to comment #11) > > Are not all modes validated? > > They are, but the radeon driver doesn't use xf86ValidateModes() in all cases > but > has some of its own validation functions. I think they ALL call xf86ValidateModes though. > Even when xf86ValidateModes() is used, > I'm not sure how it interacts with virtual resolutions e.g.? I believe that actually _only_ virtual resolutions are validated. > Have you tried 1680x1050 virtual resolution? I have tried virtual resolutions slightly larger than 1280x1024 (e.g. 1288x1024) they all result in a pitch of 1344, without problems. However, I have also tried the same with UseFBDev, the indicated pitch was still 1344, but the results inconclusive to that specific problem, since the screen in 2d was a garbled mess anyway. All virtual resolutions which do not have a pitch of 64 pixels simply do not work, maybe the modes used by fbdev and the modes which xorg thinks get used (as per mode validation) are not quite the same or something like that. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Problem with current cvs on PPC
(WW) RADEON(0): Direct rendering not yet supported on Radeon 9500 and newer cards seems you got a xorg 6.8.1 you should use lastest cvs xorg or at least a 6.8.2 if my memory is rigth there have been change in xorg for r300 since then and now i think that you need a 6.8.2 or a recent cvs checkout. For testing you could install a xorg cvs elsewhere than /usr/X11R6 see build instruction of xorg to see how. Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Problem with current cvs on PPC
Hi, I have attached my X log and dmesg log of when I run r300_demo. Keith On Tue, 2005-03-08 at 12:23 +0100, Jerome Glisse wrote: > Finaly get 5min to test lastest cvs and it works "perfectly" > here. Could you send me your xorg log file showing that > dri is disable. > > Jerome Glisse > > > On Mon, 07 Mar 2005 14:41:56 -0500, Keith Conger > <[EMAIL PROTECTED]> wrote: > > Hi Guys, > > > > Sorry should have noted this. As of the time of my intitial email is > > when I checked out both Xorg r300_demo and r300_driver. > > > > Thanks > > Keith > > On Mon, 2005-03-07 at 19:04 +0100, Jerome Glisse wrote: > > > Do you use lastest r300 CVS drm? There have been a huge > > > update of r300 drm not so long ago. > > > > > > > > > On Sun, 06 Mar 2005 13:46:22 -0500, Keith Conger > > > <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > My Machine > > > > Powerbook G4 > > > > ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 64MB > > > > Ubuntu Hoary (kernel 2.6.10) > > > > > > > > The drm module doesn't seem to work any longer for me. Drm loads without > > > > error but I don't get the normal microcode message. r300_demo now seg > > > > faults when it runs, X doesn't seem to want to enable the dri. One thing > > > > I noticed is lspci seems to indicate a have 128MB or video ram when I > > > > only have 64. > > > > > > lspci indicate 64 before ? Could you test with a previous CVS version > > > (say one week ago). > > > > > > Jerome Glisse > > > > > -- > > > > Keith Conger > > [EMAIL PROTECTED] > > http://pimpstation.org > > > > > -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org # ./r300_demo --triangles CHECKPOINT main 389 driver "radeon" version 1.15.0 driver description "ATI Radeon" AGPVendorID: AGPDeviceId: BusID: "" Context 1 AGP base: 0x Map Offset SizeType Handle Mtrr 0 0xb800 131072 KB FB 0x none 1 0xb000 64 KB REG 0xd274 none Segmentation fault dmesg <--cut--> drm: no version for "struct_module" found: kernel tainted. [drm] Initialized drm 1.0.0 20040925 [drm:drm_init] [drm:drm_get_dev] [drm:drm_initmap] [drm:drm_initmap] initmap offset = 0xb000, size = 0x0001, type = 1 [drm:drm_initmap] finished [drm:drm_initmap] [drm:drm_initmap] initmap offset = 0xb800, size = 0x0800, type = 0 [drm:drm_initmap] finished [drm:radeon_preinit] AGP card detected [drm:setup_i2c_bus] I2C bus monid registered. [drm:setup_i2c_bus] I2C bus dvi registered. [drm:setup_i2c_bus] I2C bus vga registered. [drm:setup_i2c_bus] I2C bus crt2 registered. [drm:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0 [drm:drm_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm:drm_get_head] [drm:drm_get_head] new minor assigned 0 [drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [drm] Used old pci detect: framebuffer loaded [drm:drm_stub_open] [drm:drm_open_helper] pid = 17890, minor = 0 [drm:radeon_driver_open_helper] [drm:drm_setup] [drm:drm_ioctl] pid=17890, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1 [drm:drm_ioctl] pid=17890, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 [drm:drm_ioctl] pid=17890, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 [drm:drm_release] open_count = 1 [drm:drm_release] pid = 17890, device = 0xe200, open_count = 1 [drm:drm_fasync] fd = -1, device = 0xe200 [drm:drm_takedown] [drm:radeon_do_cleanup_cp] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_stub_open] [drm:drm_open_helper] pid = 17890, minor = 0 [drm:radeon_driver_open_helper] [drm:drm_setup] [drm:drm_ioctl] pid=17890, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=17890, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_release] open_count = 1 [drm:drm_release] pid = 17890, device = 0xe200, open_count = 1 [drm:drm_fasync] fd = -1, device = 0xe200 [drm:drm_takedown] [drm:radeon_do_cleanup_cp] [drm:drm_stub_open] [drm:drm_open_helper] pid = 17890, minor = 0 [drm:radeon_driver_open_helper] [drm:drm_setup] [drm:drm_ioctl] pid=17890, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=17890, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=17890, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 [drm:drm_ioctl] pid=17890, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 [drm:drm_ioctl] pid=17890, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=17890, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=17890, cmd=0x40206433, nr=0x3
Re: [R300] Problem with current cvs on PPC
Hi, Yes agpgart and uninorth_agp are both loaded before drm. I'll try removing them first and email back. Keith On Tue, 2005-03-08 at 12:45 +0100, Jerome Glisse wrote: > Do you have agpgart running before drm ? Try with & without > agpgart this maybe related to this. Moreover have you try to > do a reboot before trying lastest drm, old drm may put the > hardware in strange state (don't think so but i know to little > on that...) Thus maybe a reboot with loading the new drm > should help you. > > Anyone have any idea on that ? > > Jerome Glisse > > On Tue, 8 Mar 2005 12:23:59 +0100, Jerome Glisse <[EMAIL PROTECTED]> wrote: > > Finaly get 5min to test lastest cvs and it works "perfectly" > > here. Could you send me your xorg log file showing that > > dri is disable. > > > > Jerome Glisse > > > > On Mon, 07 Mar 2005 14:41:56 -0500, Keith Conger > > <[EMAIL PROTECTED]> wrote: > > > Hi Guys, > > > > > > Sorry should have noted this. As of the time of my intitial email is > > > when I checked out both Xorg r300_demo and r300_driver. > > > > > > Thanks > > > Keith > > > On Mon, 2005-03-07 at 19:04 +0100, Jerome Glisse wrote: > > > > Do you use lastest r300 CVS drm? There have been a huge > > > > update of r300 drm not so long ago. > > > > > > > > > > > > On Sun, 06 Mar 2005 13:46:22 -0500, Keith Conger > > > > <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > > > > > My Machine > > > > > Powerbook G4 > > > > > ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 64MB > > > > > Ubuntu Hoary (kernel 2.6.10) > > > > > > > > > > The drm module doesn't seem to work any longer for me. Drm loads > > > > > without > > > > > error but I don't get the normal microcode message. r300_demo now seg > > > > > faults when it runs, X doesn't seem to want to enable the dri. One > > > > > thing > > > > > I noticed is lspci seems to indicate a have 128MB or video ram when I > > > > > only have 64. > > > > > > > > lspci indicate 64 before ? Could you test with a previous CVS version > > > > (say one week ago). > > > > > > > > Jerome Glisse > > > > > > > -- > > > > > > Keith Conger > > > [EMAIL PROTECTED] > > > http://pimpstation.org > > > > > > > > > -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Problem with current cvs on PPC
Do you have agpgart running before drm ? Try with & without agpgart this maybe related to this. Moreover have you try to do a reboot before trying lastest drm, old drm may put the hardware in strange state (don't think so but i know to little on that...) Thus maybe a reboot with loading the new drm should help you. Anyone have any idea on that ? Jerome Glisse On Tue, 8 Mar 2005 12:23:59 +0100, Jerome Glisse <[EMAIL PROTECTED]> wrote: > Finaly get 5min to test lastest cvs and it works "perfectly" > here. Could you send me your xorg log file showing that > dri is disable. > > Jerome Glisse > > On Mon, 07 Mar 2005 14:41:56 -0500, Keith Conger > <[EMAIL PROTECTED]> wrote: > > Hi Guys, > > > > Sorry should have noted this. As of the time of my intitial email is > > when I checked out both Xorg r300_demo and r300_driver. > > > > Thanks > > Keith > > On Mon, 2005-03-07 at 19:04 +0100, Jerome Glisse wrote: > > > Do you use lastest r300 CVS drm? There have been a huge > > > update of r300 drm not so long ago. > > > > > > > > > On Sun, 06 Mar 2005 13:46:22 -0500, Keith Conger > > > <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > My Machine > > > > Powerbook G4 > > > > ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 64MB > > > > Ubuntu Hoary (kernel 2.6.10) > > > > > > > > The drm module doesn't seem to work any longer for me. Drm loads without > > > > error but I don't get the normal microcode message. r300_demo now seg > > > > faults when it runs, X doesn't seem to want to enable the dri. One thing > > > > I noticed is lspci seems to indicate a have 128MB or video ram when I > > > > only have 64. > > > > > > lspci indicate 64 before ? Could you test with a previous CVS version > > > (say one week ago). > > > > > > Jerome Glisse > > > > > -- > > > > Keith Conger > > [EMAIL PROTECTED] > > http://pimpstation.org > > > > > --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Problem with current cvs on PPC
Finaly get 5min to test lastest cvs and it works "perfectly" here. Could you send me your xorg log file showing that dri is disable. Jerome Glisse On Mon, 07 Mar 2005 14:41:56 -0500, Keith Conger <[EMAIL PROTECTED]> wrote: > Hi Guys, > > Sorry should have noted this. As of the time of my intitial email is > when I checked out both Xorg r300_demo and r300_driver. > > Thanks > Keith > On Mon, 2005-03-07 at 19:04 +0100, Jerome Glisse wrote: > > Do you use lastest r300 CVS drm? There have been a huge > > update of r300 drm not so long ago. > > > > > > On Sun, 06 Mar 2005 13:46:22 -0500, Keith Conger > > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > My Machine > > > Powerbook G4 > > > ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 64MB > > > Ubuntu Hoary (kernel 2.6.10) > > > > > > The drm module doesn't seem to work any longer for me. Drm loads without > > > error but I don't get the normal microcode message. r300_demo now seg > > > faults when it runs, X doesn't seem to want to enable the dri. One thing > > > I noticed is lspci seems to indicate a have 128MB or video ram when I > > > only have 64. > > > > lspci indicate 64 before ? Could you test with a previous CVS version > > (say one week ago). > > > > Jerome Glisse > > > -- > > Keith Conger > [EMAIL PROTECTED] > http://pimpstation.org > > --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2673] Missing memset lets setversion ioctl corrupt memory.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2673 --- Additional Comments From [EMAIL PROTECTED] 2005-03-08 02:38 --- Created an attachment (id=2049) --> (https://bugs.freedesktop.org/attachment.cgi?id=2049&action=view) Fix -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2673] New: Missing memset lets setversion ioctl corrupt memory.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2673 Summary: Missing memset lets setversion ioctl corrupt memory. Product: DRI Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] drm_setversion() calls the driver specific version() function passing a pointer to a local structure. The driver version function copies data to memory pointed to by the name, date and desc structure elements if these are not NULL. Since they are uninitialized and the structure lives on the stack these pointers point to random addresses. Bug found in 2.6.11 RC. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: more mesa-solo trouble w/r300 on ia64
Hi Jesse ! On Mon, 7 Mar 2005, Jesse Barnes wrote: Ok, so I've applied Stephane's fixes and sample_server comes up and miniglxtest no longer segfaults. However, after setting the mode, sample_server seems to die and wedge my display. miniglxtest just fails right away with this message: [EMAIL PROTECTED] miniglx]$ ./miniglxtest [miniglx] probed chipset 0x4e4b CreateNotify Authorize - magic 1 Unknown device ID 4E4B, please report. Assuming plain R300. ^ This is a bit odd - if the r300 driver does not know about the device why does the DRM driver load ? Also, are you using the drm driver from r300.sf.net ? The message below (error -22) might be indicative of wrong drm driver, try to insmod it with explicit path, like this: insmod ./drm.ko insmod ./radeon.ko best Vladimir Dergachev Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=32 Allocating 284420 bytes command buffer (max state is 11140 bytes) *WARN_ONCE* File r300_state.c function r300Enable line 516 Don't know how to enable polygon offset point/line. Help me ! *** MapRequest Hang on... drawing 6 frames Redraw event drmRadeonCmdBuffer: -22 (exiting) DestroyNotify --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
