[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #40 from Tomasz Czapiewski 2010-10-24 22:16:30 PDT --- I've done some more testing in spectate mode (so I can go closer to walls, even fly through them) and my theory about 60->30 FPS drop does not work everytime as there are walls which can look at (very close look) where I have 60 FPS and the problem is still there but it might be something with lightning with lightmaps on just s3tc textures. The textures which (always) are not broken (probably not s3tc) when s3tc+lightmaps are enabled on the same map have working lightmaps effect. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DRM Vblank timestamping patches. 1st Try.
Oh btw., the patches are against the current drm-radeon-testing tree, applied after commit... 21c74a8ea8b47eb6c3c621e36578f6e27f65c5c7 "drm, kdb, kms: Change mode_set_base_atomic() enter argument to be an enum" ... and should apply cleanly. thanks, -mario
[Bug 29726] New CRTC ID query breaks Radeon DRM in Zaphod mode
https://bugs.freedesktop.org/show_bug.cgi?id=29726 --- Comment #7 from Alex Deucher 2010-10-24 22:09:03 PDT --- (In reply to comment #6) > I was thinking you actually meant the .drirc setting rather than an actual > environment variable but you were right. Setting this in .drirc makes no > difference but the environment variable does indeed make the problem go away. > It's works in the .drirc as well, but it requires slightly different handling for dri2 drivers, e.g., > I quite like vsyncing so I'm a little sad if it's broken. I think it was > working before? It wasn't supported before. KMS vsync support was added with the commit cited in this bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 3/3] kms/i915: Add support for precise vblank timestamping.
This patch adds new functions for use by the drm core:
.get_vblank_timestamp() provides a precise timestamp
for the end of the most recent (or current) vblank
interval of a given crtc, as needed for the DRI2
implementation of the OML_sync_control extension.
It is a thin wrapper around the drm function
drm_calc_vbltimestamp_from_scanoutpos() which does
almost all the work.
.get_scanout_position() provides the current horizontal
and vertical video scanout position and "in vblank"
status of a given crtc, as needed by the drm for use by
drm_calc_vbltimestamp_from_scanoutpos().
The patch modifies the pageflip completion routine
to use these precise vblank timestamps as the timestamps
for pageflip completion events.
This code has been only tested on a HP-Mini Netbook with
Atom processor and Intel 945GME gpu. The codepath for
(IS_G4X(dev) || IS_IRONLAKE(dev) || IS_GEN6(dev)) gpu's
has not been tested so far due to lack of hardware.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/i915/i915_drv.c |2 +
drivers/gpu/drm/i915/i915_drv.h |7 +++
drivers/gpu/drm/i915/i915_irq.c | 92 ++
drivers/gpu/drm/i915/intel_display.c | 31 +---
drivers/gpu/drm/i915/intel_drv.h |1 +
5 files changed, 126 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c3decb2..4d8184a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -603,6 +603,8 @@ static struct drm_driver driver = {
.device_is_agp = i915_driver_device_is_agp,
.enable_vblank = i915_enable_vblank,
.disable_vblank = i915_disable_vblank,
+ .get_vblank_timestamp = i915_get_vblank_timestamp,
+ .get_scanout_position = i915_get_crtc_scanoutpos,
.irq_preinstall = i915_driver_irq_preinstall,
.irq_postinstall = i915_driver_irq_postinstall,
.irq_uninstall = i915_driver_irq_uninstall,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 73ad8bf..276fbdb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -948,6 +948,13 @@ void
i915_disable_pipestat(drm_i915_private_t *dev_priv, int pipe, u32 mask);
void intel_enable_asle (struct drm_device *dev);
+int i915_get_vblank_timestamp(struct drm_device *dev, int crtc,
+ int *max_error,
+ struct timeval *vblank_time,
+ unsigned flags);
+
+int i915_get_crtc_scanoutpos(struct drm_device *dev, int pipe,
+int *vpos, int *hpos);
#ifdef CONFIG_DEBUG_FS
extern void i915_destroy_error_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 64c07c2..c9c8d4a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -243,6 +243,98 @@ u32 gm45_get_vblank_counter(struct drm_device *dev, int
pipe)
return I915_READ(reg);
}
+int i915_get_crtc_scanoutpos(struct drm_device *dev, int pipe,
+int *vpos, int *hpos)
+{
+ drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
+ int reg;
+ u32 vbl = 0, position = 0;
+ int vbl_start, vbl_end, htotal, vtotal;
+ bool in_vbl = true;
+ int ret = 0;
+
+ if (!i915_pipe_enabled(dev, pipe)) {
+ DRM_DEBUG_DRIVER("trying to get scanoutpos for disabled "
+ "pipe %d\n", pipe);
+ return 0;
+ }
+
+ /* Get vtotal. */
+ reg = pipe ? VTOTAL_B : VTOTAL_A;
+ vtotal = 1 + ((I915_READ(reg) >> 16) & 0x1fff);
+
+ if (IS_G4X(dev) || IS_IRONLAKE(dev) || IS_GEN6(dev)) {
+ /* No obvious pixelcount register. Only query vertical
+* scanout position from Display scan line register.
+*/
+ reg = pipe ? PIPEBDSL : PIPEADSL;
+ position = I915_READ(reg);
+
+ /* Decode into vertical scanout position. Don't have
+* horizontal scanout position.
+*/
+ *vpos = position & 0x1fff;
+ *hpos = 0;
+ } else {
+ /* Have access to pixelcount since start of frame.
+* We can split this into vertical and horizontal
+* scanout position.
+*/
+ reg = pipe ? PIPEBFRAMEPIXEL : PIPEAFRAMEPIXEL;
+ position = (I915_READ(reg) & PIPE_PIXEL_MASK) >>
PIPE_PIXEL_SHIFT;
+
+ reg = pipe ? HTOTAL_B : HTOTAL_A;
+ htotal = 1 + ((I915_READ(reg) >> 16) & 0x1fff);
+ *vpos = position / htotal;
+ *hpos = position - (*vpos * htotal);
+ }
+
+ /* Query vblank area. */
+ reg = pipe ? VBLANK_B : VBLANK_A;
+ vbl = I915_READ(reg);
+
+ /* Test position against vblank region. */
+
[PATCH 2/3] kms/radeon: Add support for precise vblank timestamping.
This patch adds new functions for use by the drm core:
.get_vblank_timestamp() provides a precise timestamp
for the end of the most recent (or current) vblank
interval of a given crtc, as needed for the DRI2
implementation of the OML_sync_control extension.
It is a thin wrapper around the drm function
drm_calc_vbltimestamp_from_scanoutpos() which does
almost all the work and is shared across drivers.
.get_scanout_position() provides the current horizontal
and vertical video scanout position and "in vblank"
status of a given crtc, as needed by the drm for use by
drm_calc_vbltimestamp_from_scanoutpos().
The function is also used by the dynamic gpu reclocking
code to determine when it is safe to reclock inside vblank.
For that purpose radeon_pm_in_vbl() is modified to
accomodate a small change in the function prototype of
the radeon_get_crtc_scanoutpos() which is hooked up to
.get_scanout_position().
This code has been tested on AVIVO hardware, a RV530
(ATI Mobility Radeon X1600) in a Intel Core-2 Duo MacBookPro
and some R600 variant (FireGL V7600) in a single cpu
AMD Athlon 64 PC.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/radeon/radeon_display.c | 40 --
drivers/gpu/drm/radeon/radeon_drv.c |8 ++
drivers/gpu/drm/radeon/radeon_kms.c | 21
drivers/gpu/drm/radeon/radeon_mode.h|7 +
drivers/gpu/drm/radeon/radeon_pm.c |6 ++--
5 files changed, 55 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 0383631..37bfc48 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1015,7 +1015,7 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
/*
* Retrieve current video scanout position of crtc on a given gpu.
*
- * \param rdev Device to query.
+ * \param dev Device to query.
* \param crtc Crtc to query.
* \param *vpos Location where vertical scanout position should be stored.
* \param *hpos Location where horizontal scanout position should go.
@@ -1027,72 +1027,74 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc
*crtc,
*
* \return Flags, or'ed together as follows:
*
- * RADEON_SCANOUTPOS_VALID = Query successfull.
- * RADEON_SCANOUTPOS_INVBL = Inside vblank.
- * RADEON_SCANOUTPOS_ACCURATE = Returned position is accurate. A lack of
+ * DRM_SCANOUTPOS_VALID = Query successfull.
+ * DRM_SCANOUTPOS_INVBL = Inside vblank.
+ * DRM_SCANOUTPOS_ACCURATE = Returned position is accurate. A lack of
* this flag means that returned position may be offset by a constant but
* unknown small number of scanlines wrt. real scanout position.
*
*/
-int radeon_get_crtc_scanoutpos(struct radeon_device *rdev, int crtc, int
*vpos, int *hpos)
+int radeon_get_crtc_scanoutpos(struct drm_device *dev, int crtc, int *vpos,
int *hpos)
{
u32 stat_crtc = 0, vbl = 0, position = 0;
int vbl_start, vbl_end, vtotal, ret = 0;
bool in_vbl = true;
+ struct radeon_device *rdev = dev->dev_private;
+
if (ASIC_IS_DCE4(rdev)) {
if (crtc == 0) {
vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END +
EVERGREEN_CRTC0_REGISTER_OFFSET);
position = RREG32(EVERGREEN_CRTC_STATUS_POSITION +
EVERGREEN_CRTC0_REGISTER_OFFSET);
- ret |= RADEON_SCANOUTPOS_VALID;
+ ret |= DRM_SCANOUTPOS_VALID;
}
if (crtc == 1) {
vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END +
EVERGREEN_CRTC1_REGISTER_OFFSET);
position = RREG32(EVERGREEN_CRTC_STATUS_POSITION +
EVERGREEN_CRTC1_REGISTER_OFFSET);
- ret |= RADEON_SCANOUTPOS_VALID;
+ ret |= DRM_SCANOUTPOS_VALID;
}
if (crtc == 2) {
vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END +
EVERGREEN_CRTC2_REGISTER_OFFSET);
position = RREG32(EVERGREEN_CRTC_STATUS_POSITION +
EVERGREEN_CRTC2_REGISTER_OFFSET);
- ret |= RADEON_SCANOUTPOS_VALID;
+ ret |= DRM_SCANOUTPOS_VALID;
}
if (crtc == 3) {
vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END +
EVERGREEN_CRTC3_REGISTER_OFFSET);
position = RREG32(EVERGREEN_CRTC_STATUS_POSITION +
EVERGREEN_CRTC3_REGISTER_OFFSET);
- ret |= RADEON_SCANOUTPOS_VALID;
+ ret |= DRM_SCANOUTPOS_VALID;
}
if (crtc == 4) {
[PATCH 1/3] drm/vblank: Add support for precise vblank timestamping.
The DRI2 swap & sync implementation needs precise vblank counts and precise timestamps corresponding to those vblank counts. For conformance to the OpenML OML_sync_control extension specification the DRM timestamp associated with a vblank count should correspond to the start of video scanout of the first scanline of the video frame following the vblank interval for that vblank count. Therefore we need to carry around precise timestamps for vblanks. Currently the DRM and KMS drivers generate timestamps ad-hoc via do_gettimeofday() in some places. The resulting timestamps are sometimes not very precise due to interrupt handling delays, they don't conform to OML_sync_control and some are wrong, as they aren't taken synchronized to the vblank. This patch implements support inside the drm core for precise and robust timestamping. It consists of the following interrelated pieces. 1. Vblank timestamp caching: A per-crtc ringbuffer stores the most recent vblank timestamps corresponding to vblank counts. The ringbuffer can be read out lock-free via the accessor function: struct timeval timestamp; vblankcount = drm_vblank_count_and_time(dev, crtcid, ). The function returns the current vblank count and the corresponding timestamp for start of video scanout following the vblank interval. It can be used anywhere between enclosing drm_vblank_get(dev, crtcid) and drm_vblank_put(dev,crtcid) statements. It is used inside the drmWaitVblank ioctl and in the vblank event queueing and handling. It should be used by kms drivers for timestamping of bufferswap completion. The timestamp ringbuffer is reinitialized each time vblank irq's get reenabled in drm_vblank_get()/ drm_update_vblank_count(). It is invalidated when vblank irq's get disabled. The ringbuffer is updated inside drm_handle_vblank() at each vblank irq. 2. Calculation of precise vblank timestamps: drm_get_last_vbltimestamp() is used to compute the timestamp for the end of the most recent vblank (if inside active scanout), or the expected end of the current vblank interval (if called inside a vblank interval). The function calls into a new optional kms driver entry point dev->driver->get_vblank_timestamp() which is supposed to provide the precise timestamp. If a kms driver doesn't implement the entry point or if the call fails, a simple do_gettimeofday() timestamp is returned as crude approximation of the true vblank time. A new drm module parameter drm.timestamp_precision_usec allows to disable high precision timestamps (if set to zero) or to specify the maximum acceptable error in the timestamps in microseconds. Kms drivers could implement their get_vblank_timestamp() function in a gpu specific way, as long as returned timestamps conform to OML_sync_control, e.g., by use of gpu specific hardware timestamps. Optionally, kms drivers can simply wrap and use the new utility function drm_calc_vbltimestamp_from_scanoutpos(). This function calls a new optional kms driver function dev->driver->get_scanout_position() which returns the current horizontal and vertical video scanout position of the crtc. The scanout position together with the drm_display_timing of the current video mode is used to calculate elapsed time relative to start of active scanout for the current video frame. This elapsed time is subtracted from the current do_gettimeofday() time to get the timestamp corresponding to start of video scanout. Currently non-interlaced, non-doublescan video modes, with or without panel scaling are handled correctly. Interlaced/ doublescan modes are tbd in a future patch. 3. Filtering of redundant vblank irq's and removal of some race-conditions in the vblank irq enable/disable path: Some gpu's (e.g., Radeon R500/R600) send spurious vblank irq's outside the vblank if vblank irq's get reenabled. These get detected by use of the vblank timestamps and filtered out to avoid miscounting of vblanks. Some race-conditions between the vblank irq enable/disable functions, the vblank irq handler and the gpu itself (updating its hardware vblank counter in the "wrong" moment) are fixed inside vblank_disable_and_save() and drm_update_vblank_count() by use of the vblank timestamps and a new spinlock dev->vblank_time_lock. The time until vblank irq disable is now configurable via a new drm module parameter drm.vblankoffdelay to allow experimentation with timeouts that are much shorter than the current 5 seconds and should allow longer vblank off periods for better power savings. Followup patches will use these new functions to implement precise timestamping for the intel and radeon kms drivers. Signed-off-by: Mario Kleiner --- drivers/gpu/drm/drm_crtc_helper.c | 13 +- drivers/gpu/drm/drm_irq.c | 563 +++-- drivers/gpu/drm/drm_stub.c| 10 + include/drm/drmP.h| 93 ++ include/drm/drm_crtc.h|9 + 5 files changed, 662 insertions(+), 26 deletions(-) diff --git
DRM Vblank timestamping patches. 1st Try.
Hi all, after obsessing over these for another month after xds 2010, this is the first version of my vblank timestamping patches that i'm not totally ashamed off. 1st patch modifies the drm vblank handling to maintain precise timestamps of when vblanks happen. It timestamps the end of each vblank interval (= start of active scanout of the following frame), as required by the OpenML OML_sync_control extension spec, so the DRI2 swap & sync bits should return proper timestamps to gl clients. It also takes care of keeping timestamps and vblcounts consistent across vblank irq on/off and hopefully fixes a few off-by-one vblank counts due to race conditions in those on/off bits. There is still one small race condition between the vblank on/off bits and the gpu (updating its hardware vblank counter at the wrong moment) which can cause miscounting of vblanks across enable/disable. I have an idea how to fix that, based on these patches but will need to tinker around with it a bit more. After that we could reduce the vblankoffdelay from 5000 msecs to something smaller like 100 msecs to save more power on desktops with desktop composition enabled, where already a blinking cursor in a terminal window or a ticking clock in the menu bar can keep vblanks turned on all the time with a 5000 msecs timeout. All the timestamping inside the drmWaitVblank ioctl() and in vblank event handling now uses the timestamps calculated in this patch. 2nd and 3rd patches add the new timestamping and scanout position functions to the i915 and radeon drivers. Wrt. what i showed you at xds, i made the following changes: I've moved the actual timestamping routine as a helper function into the core. kms drivers now optionally export the crtc scanout position query function in addition to the vblank timestamping function to the drm core. Whenever the core has to recalculate timestamps it goes like: core -> kmsdriver-timestamping() -> core-timestampinghelper() -> kmsdriver-getscanoutposition() The kms driver can implement its own version of the timestamping function, e.g., using special hardware timestamping registers in some more recent gpu's, or it can simply export a getscanoutposition() function with standardized behaviour across drivers and call the timestamping routine implemented in the core. The routine in the core works in non-interlaced, non-doublescan video modes, with or without panel scaling. It can compensate for any random delay up to 1 video refresh duration. For more robustness one would need to use a gpu specific hardware method. I also moved the calculation of the constants needed for timetamping into the drm_crtc_helper routine, so they only get recalculated after a mode switch, not at each vblank. At modeset time i cache the adjusted_mode after validation/adjustment by the crtc and encoders inside the drm_crtc struct. Needed to account for panel scaling, and i have a few other ideas that would require that cached value. More details in the different commit messages and the code, just some more remarks. @Jesse: I replaced the n extra dynamically allocated spin-locks for n crtc's by one statically allocated lock shared by all crtc's and renamed it. I think i also worked all your other suggestions into the patches. Thanks a lot for your first review of the earlier version. The intel driver uses the timestamps inside the finish pageflip function for timestamps of bufferswap completion. I've tested with an Atom Mini netbook with Intel 945 GME gpu and there it works perfect. I don't have any other intel test machines, so the finish pageflip and scanout query functions for ironlake, gen6 and g4x aren't tested, only coded based on some of the intel manuals at xorg. In the pageflip irq handlers there is this uncertainty if pageflip irq's get delivered before or after the vblank irq's for the vblank interval of swap completion. The i945 delivers pagflip irq's before handling the vblank irq's so the completion handler needs to account for that. I guessed from the code, which ones do deliver before/after vblank, but that guesses may be wrong, so this needs testing. @Alex: Thanks for your feedback at xds. I think the radeon part should be as we discussed. The radeon patch builds onto what you committed already into drm-radeon-testing for the reclocking fixes. It slightly changes the interface between the scanout query function and radeon_pm_in_vbl(), but doesn't change the implementation. Testing of the timestamps on the Intel 945GME, a Radeon R500 and a R600 against external measurement equipment shows that the timestamps are essentially perfect. Error wrt. to the external measurement is less than 20 microseconds (for the radeon's) and jitter is +/- 1 usec. The intel error is less than 0.5 msecs, but i can't test how much better because my photo-diode can't do better and my usec precise equipment only works with DVI, but the intel test machine only has a vga output. Now this swapbuffers timestamping is only trustworthy
[PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info
On regarding this bug https://bugs.freedesktop.org/show_bug.cgi?id=29726 what is the relation between querying crtc id and the vblank event? Could you point where this query is needed? -- Lucas Clemente Vella lvella at gmail.com
[Bug 29726] New CRTC ID query breaks Radeon DRM in Zaphod mode
https://bugs.freedesktop.org/show_bug.cgi?id=29726 --- Comment #6 from James Le Cuirot 2010-10-24 16:03:20 PDT --- I was thinking you actually meant the .drirc setting rather than an actual environment variable but you were right. Setting this in .drirc makes no difference but the environment variable does indeed make the problem go away. I quite like vsyncing so I'm a little sad if it's broken. I think it was working before? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #39 from Marek Ol??k 2010-10-24 15:38:54 PDT --- (In reply to comment #38) > (In reply to comment #32) > > In the kernel, there is function r100_copy_blit for copying buffers between > > RAM > > and VRAM using the 2D engine, and it's hooked up in the TTM. The function is > > used on r100 up to r500. > > > > I believe switching between the 2D and 3D engine doesn't work as it should > > or > > we don't flush some cache or something. > > Interesting theory - should this bug now include a title tag for r100-r500 DRM > kernel modules? Not necessary, it's just a theory. It would be interesting to rewrite that function to use the 3D engine on r300 and see if it fixes anything. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #38 from Chris Rankin 2010-10-24 15:31:05 PDT --- (In reply to comment #32) > In the kernel, there is function r100_copy_blit for copying buffers between > RAM > and VRAM using the 2D engine, and it's hooked up in the TTM. The function is > used on r100 up to r500. > > I believe switching between the 2D and 3D engine doesn't work as it should or > we don't flush some cache or something. Interesting theory - should this bug now include a title tag for r100-r500 DRM kernel modules? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #37 from Chris Rankin 2010-10-24 15:27:17 PDT --- (In reply to comment #36) > I wish I could enable S3TC on r300g without this library (as it could be done > with r300c) to check if the textures sent to the card without software > recoding > library will have simmilar effect. Have you tested whether the corruption happens with r300c too? It does with WoW (although r300g has fewer other bugs). Still, I'm glad you at least have a workaround available. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29389] [r300g] [bisected] hard locks with polling enabled in 2.6.35
https://bugs.freedesktop.org/show_bug.cgi?id=29389 --- Comment #7 from pj_beers at hotmail.com 2010-10-24 14:43:21 PDT --- Created an attachment (id=39745) --> (https://bugs.freedesktop.org/attachment.cgi?id=39745) dmesg 2.6.36-rc7 with disabled polling DACs patch, rv380 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29389] [r300g] [bisected] hard locks with polling enabled in 2.6.35
https://bugs.freedesktop.org/show_bug.cgi?id=29389 --- Comment #6 from pj_beers at hotmail.com 2010-10-24 14:40:13 PDT --- I reported the same bug (I think) over here: https://bugzilla.kernel.org/show_bug.cgi?id=20042 Your latest patch disabling polling DACs works for my, I applied it to 2.6.36-rc7 and then ran Penumbra Overture without any problem. I'm using rv380, not rv370 (according to dmesg). I've included dmesg output as an attachment. Thanks very much for this patch! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800 --- Comment #17 from Tomasz Czapiewski 2010-10-24 14:15:19 PDT --- (In reply to comment #16) > *** Bug 30960 has been marked as a duplicate of this bug. *** I've made some comments in this duplicate... Should I comment later here or in my duplicate? Considering that WoW is closed source and could not be easily debugged, Xonotic is open source game and it's developers might be helpful to give usefull information from game code, too. And now I know that there, the problem appears only with lightmaps+s3tc textures and without lightmaps the s3tc textures work just fine there (Xonotic). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #36 from Tomasz Czapiewski 2010-10-24 14:00:47 PDT --- So, the problematic textures are dxt1_rgb and/or dxt1_rgba. I've done some more testing and I've saw that when I have 60 FPS the problem is gone with S3TC+lightmaps (all textures are OK, no matter what I'm looking at on the map) but when the FPS gets dropped to 30 FPS the problem arrives or when the problem arrives I get FPS drop to 30(?). I wonder if the problem is with library or the S3TC handling by the driver itself. I wish I could enable S3TC on r300g without this library (as it could be done with r300c) to check if the textures sent to the card without software recoding library will have simmilar effect. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #35 from Tomasz Czapiewski 2010-10-24 13:50:49 PDT --- Created an attachment (id=39744) --> (https://bugs.freedesktop.org/attachment.cgi?id=39744) RADEON_DEBUG=tex log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #34 from Tomasz Czapiewski 2010-10-24 13:16:39 PDT --- I wonder why does S3TC with libtxc_dxtn.so in Xonotic works properly when lightmaps are disabled? I can use better quality DDS textures (without KWin desktop effects) just fine in Xonotic without lightmaps. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Tomasz Czapiewski changed: What|Removed |Added Summary|[r300g][glsl] Texture |[r300g][glsl][libtxc_dxtn] |corruption in Xonotic with |Texture corruption in |lightmaps |Xonotic with lightmaps -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #33 from Tomasz Czapiewski 2010-10-24 13:08:36 PDT --- Chris, yours suggestion was right! I've installed libtxc_dxtn.so some time ago as some apps (games) could use it. After removing this library the problem with rainbow colors/texture corruption in my case was resolved. The other workaround is to enable option 'Avoid loosy texture compression' in Xonotic menu which disables use of S3TC DDS textures. And that what Marek has suggested about texture corruption with high detail it was right, too but it didn't look like on those screenshots. I've found this problem when I've run Xonotic with KDE KWin desktop effects enabled and without libtxc_dxtn.so - not only the big FPS drop but there were many different problems with textures (black textures, black and white textures, black and white noise, screen smoothing with no textures, etc.). Disabling KWin desktop effects + using lower quality textures + removing libtxc_dxtn.so (so it disables GL_EXT_texture_compression_s3tc and GL_S3_s3tc extensions) altogether does make the problem disappear. And for texture formats that Xonotic needs - it uses JPG and TGA textures but DDS compressed textures, too and I'd like to use them as I could use better quality textures as I think it needs less RAM/VRAM(?) to handle them. And better quality textures compressed as DDS does not make any FPS drop. And most commercial games need S3TC. So IMO, it does look like it's a duplicate of 28800. Is there any chance to get this bug with libtxc_dxtn.so fixed to properly handle DDS compressed textures? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27744] atombios stuck in loop - during suspend
https://bugs.freedesktop.org/show_bug.cgi?id=27744 --- Comment #36 from peterle at hottemptation.org 2010-10-24 10:25:28 PDT --- Created an attachment (id=39742) --> (https://bugs.freedesktop.org/attachment.cgi?id=39742) resuspend after "fast resuspend without stuck" As you can see I got there twoxstuck messages and the resuspend takes 10 seconds, afters this resuspend switching between ttys is normal (fast) again. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27744] atombios stuck in loop - during suspend
https://bugs.freedesktop.org/show_bug.cgi?id=27744 --- Comment #35 from peterle at hottemptation.org 2010-10-24 10:23:53 PDT --- Created an attachment (id=39741) --> (https://bugs.freedesktop.org/attachment.cgi?id=39741) dmesg after a fast resuspend, without stuck, ttyswitch is slow after this -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31083] R600 misrenders irrlicht demo (01helloworld)
https://bugs.freedesktop.org/show_bug.cgi?id=31083 --- Comment #2 from Lauri Kasanen 2010-10-24 09:57:25 PDT --- Created an attachment (id=39740) --> (https://bugs.freedesktop.org/attachment.cgi?id=39740) Mentioned Irrlicht demo, source code -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31083] R600 misrenders irrlicht demo (01helloworld)
https://bugs.freedesktop.org/show_bug.cgi?id=31083 --- Comment #1 from Lauri Kasanen 2010-10-24 09:56:55 PDT --- Created an attachment (id=39739) --> (https://bugs.freedesktop.org/attachment.cgi?id=39739) R600 output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31083] New: R600 misrenders irrlicht demo (01helloworld)
https://bugs.freedesktop.org/show_bug.cgi?id=31083 Summary: R600 misrenders irrlicht demo (01helloworld) Product: Mesa Version: 7.9 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: curaga at operamail.com Created an attachment (id=39738) --> (https://bugs.freedesktop.org/attachment.cgi?id=39738) Software renderer (correct output) The R600 driver misrenders the first demo of Irrlicht (irrlicht.sourceforge.net) when edited to use OpenGL instead of irrlicht's software renderer. The demo loads an animated md2 model with a bmp texture. Tested on Mesa 7.8.2 and 7.9, r600 fails on both, software renderer works on both. Screenshots attached. HW: Radeon HD4350 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #32 from Marek Ol??k 2010-10-24 09:32:51 PDT --- I have noticed the corruption happens under extreme memory pressure (e.g. ETQW has corrupted textures with 64MB VRAM and the lowest graphics details, but if you have 256MB VRAM, you may see the corruption with the highest details only), so here is my theory. In the kernel, there is function r100_copy_blit for copying buffers between RAM and VRAM using the 2D engine, and it's hooked up in the TTM. The function is used on r100 up to r500. I believe switching between the 2D and 3D engine doesn't work as it should or we don't flush some cache or something. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29726] New CRTC ID query breaks Radeon DRM in Zaphod mode
https://bugs.freedesktop.org/show_bug.cgi?id=29726 --- Comment #5 from Alex Deucher 2010-10-24 08:33:15 PDT --- vblank synchronization apparently does not work correctly in zaphod mode. You can disable it by setting the env var vblank_mode=0. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29726] New CRTC ID query breaks Radeon DRM in Zaphod mode
https://bugs.freedesktop.org/show_bug.cgi?id=29726 Alex Deucher changed: What|Removed |Added CC||lvella at gmail.com --- Comment #4 from Alex Deucher 2010-10-24 08:31:13 PDT --- *** Bug 31066 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #87 from Da Fox 2010-10-24 07:23:01 PDT --- (In reply to comment #85) > Created an attachment (id=39651) View: https://bugs.freedesktop.org/attachment.cgi?id=39651 Review: https://bugs.freedesktop.org/review?bug=28402=39651 > Make sure MC vram map is >= pci aperture size > > Ok, I think I found the root cause in this bug. The vram map in the memory > controller needs to be >= the pci aperture size. For the systems here, the > vram size is 64 MB and the aperture size is 128 MB so the vram map in the mc > needs to be at least 128 MB. However, it's getting set to 64 MB. I've tested the patch from Comment 79 for over a week now, without any issues (as expected). The patch from Comment 82 is quite similar so I assume that would work too. I'm going to test this patch now on a fresh 2.6.36. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #31 from Chris Rankin 2010-10-24 05:50:23 PDT --- (In reply to comment #29) > It looks exactly like bug 28800 which we don't know how to fix. It's not *exactly* like bug 28800; I don't see anything like this in my dmesg log: [13255.216618] radeon :01:00.0: object_init failed for (1048576, 0x0006) [13255.216631] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (1048576, 6, 4096, -12) Also, I see from the glxinfo output that you have S3TC texturing enabled, which presumably implies that you have the libtxc_dxtn.so library installed. So assuming that Xonotic doesn't need S3TC texturing for anything, does uninstalling this library affect the corruption in any way, please? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin changed: What|Removed |Added Attachment #39539|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin changed: What|Removed |Added Attachment #39544|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin changed: What|Removed |Added Attachment #39532|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin changed: What|Removed |Added Attachment #39531|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin changed: What|Removed |Added Attachment #39524|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin changed: What|Removed |Added Attachment #39523|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #30 from Chris Rankin 2010-10-24 05:28:23 PDT --- (In reply to comment #29) > It looks exactly like bug 28800 which we don't know how to fix. Having said that, the corruption I observe with bug 28800 was much reduced by upgrading my kernel from 2.6.34.x to 2.6.35.x. I haven't tried with 2.6.36.x yet. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #86 from Manuel Lauss 2010-10-24 05:03:12 PDT --- (In reply to comment #85) > Created an attachment (id=39651) View: https://bugs.freedesktop.org/attachment.cgi?id=39651 Review: https://bugs.freedesktop.org/review?bug=28402=39651 > Make sure MC vram map is >= pci aperture size > > Ok, I think I found the root cause in this bug. The vram map in the memory > controller needs to be >= the pci aperture size. For the systems here, the > vram size is 64 MB and the aperture size is 128 MB so the vram map in the mc > needs to be at least 128 MB. However, it's getting set to 64 MB. The patch fixes this long-standing issue for me. System is rock-solid with 4xAGP and all sorts of firefox and 3d abuse didn't freeze it. Thank you! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #86 from Manuel Lauss manuel.la...@gmail.com 2010-10-24 05:03:12 PDT --- (In reply to comment #85) Created an attachment (id=39651) View: https://bugs.freedesktop.org/attachment.cgi?id=39651 Review: https://bugs.freedesktop.org/review?bug=28402attachment=39651 Make sure MC vram map is = pci aperture size Ok, I think I found the root cause in this bug. The vram map in the memory controller needs to be = the pci aperture size. For the systems here, the vram size is 64 MB and the aperture size is 128 MB so the vram map in the mc needs to be at least 128 MB. However, it's getting set to 64 MB. The patch fixes this long-standing issue for me. System is rock-solid with 4xAGP and all sorts of firefox and 3d abuse didn't freeze it. Thank you! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #30 from Chris Rankin ranki...@googlemail.com 2010-10-24 05:28:23 PDT --- (In reply to comment #29) It looks exactly like bug 28800 which we don't know how to fix. Having said that, the corruption I observe with bug 28800 was much reduced by upgrading my kernel from 2.6.34.x to 2.6.35.x. I haven't tried with 2.6.36.x yet. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin ranki...@googlemail.com changed: What|Removed |Added Attachment #39523|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin ranki...@googlemail.com changed: What|Removed |Added Attachment #39524|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin ranki...@googlemail.com changed: What|Removed |Added Attachment #39531|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin ranki...@googlemail.com changed: What|Removed |Added Attachment #39532|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin ranki...@googlemail.com changed: What|Removed |Added Attachment #39544|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Chris Rankin ranki...@googlemail.com changed: What|Removed |Added Attachment #39539|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #31 from Chris Rankin ranki...@googlemail.com 2010-10-24 05:50:23 PDT --- (In reply to comment #29) It looks exactly like bug 28800 which we don't know how to fix. It's not *exactly* like bug 28800; I don't see anything like this in my dmesg log: [13255.216618] radeon :01:00.0: object_init failed for (1048576, 0x0006) [13255.216631] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (1048576, 6, 4096, -12) Also, I see from the glxinfo output that you have S3TC texturing enabled, which presumably implies that you have the libtxc_dxtn.so library installed. So assuming that Xonotic doesn't need S3TC texturing for anything, does uninstalling this library affect the corruption in any way, please? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #87 from Da Fox da_...@mad.scientist.com 2010-10-24 07:23:01 PDT --- (In reply to comment #85) Created an attachment (id=39651) View: https://bugs.freedesktop.org/attachment.cgi?id=39651 Review: https://bugs.freedesktop.org/review?bug=28402attachment=39651 Make sure MC vram map is = pci aperture size Ok, I think I found the root cause in this bug. The vram map in the memory controller needs to be = the pci aperture size. For the systems here, the vram size is 64 MB and the aperture size is 128 MB so the vram map in the mc needs to be at least 128 MB. However, it's getting set to 64 MB. I've tested the patch from Comment 79 for over a week now, without any issues (as expected). The patch from Comment 82 is quite similar so I assume that would work too. I'm going to test this patch now on a fresh 2.6.36. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29726] New CRTC ID query breaks Radeon DRM in Zaphod mode
https://bugs.freedesktop.org/show_bug.cgi?id=29726 Alex Deucher ag...@yahoo.com changed: What|Removed |Added CC||lve...@gmail.com --- Comment #4 from Alex Deucher ag...@yahoo.com 2010-10-24 08:31:13 PDT --- *** Bug 31066 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #32 from Marek Olšák mar...@gmail.com 2010-10-24 09:32:51 PDT --- I have noticed the corruption happens under extreme memory pressure (e.g. ETQW has corrupted textures with 64MB VRAM and the lowest graphics details, but if you have 256MB VRAM, you may see the corruption with the highest details only), so here is my theory. In the kernel, there is function r100_copy_blit for copying buffers between RAM and VRAM using the 2D engine, and it's hooked up in the TTM. The function is used on r100 up to r500. I believe switching between the 2D and 3D engine doesn't work as it should or we don't flush some cache or something. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31083] New: R600 misrenders irrlicht demo (01helloworld)
https://bugs.freedesktop.org/show_bug.cgi?id=31083 Summary: R600 misrenders irrlicht demo (01helloworld) Product: Mesa Version: 7.9 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: cur...@operamail.com Created an attachment (id=39738) -- (https://bugs.freedesktop.org/attachment.cgi?id=39738) Software renderer (correct output) The R600 driver misrenders the first demo of Irrlicht (irrlicht.sourceforge.net) when edited to use OpenGL instead of irrlicht's software renderer. The demo loads an animated md2 model with a bmp texture. Tested on Mesa 7.8.2 and 7.9, r600 fails on both, software renderer works on both. Screenshots attached. HW: Radeon HD4350 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31083] R600 misrenders irrlicht demo (01helloworld)
https://bugs.freedesktop.org/show_bug.cgi?id=31083 --- Comment #1 from Lauri Kasanen cur...@operamail.com 2010-10-24 09:56:55 PDT --- Created an attachment (id=39739) -- (https://bugs.freedesktop.org/attachment.cgi?id=39739) R600 output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27744] atombios stuck in loop - during suspend
https://bugs.freedesktop.org/show_bug.cgi?id=27744 --- Comment #35 from pete...@hottemptation.org 2010-10-24 10:23:53 PDT --- Created an attachment (id=39741) -- (https://bugs.freedesktop.org/attachment.cgi?id=39741) dmesg after a fast resuspend, without stuck, ttyswitch is slow after this -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27744] atombios stuck in loop - during suspend
https://bugs.freedesktop.org/show_bug.cgi?id=27744 --- Comment #36 from pete...@hottemptation.org 2010-10-24 10:25:28 PDT --- Created an attachment (id=39742) -- (https://bugs.freedesktop.org/attachment.cgi?id=39742) resuspend after fast resuspend without stuck As you can see I got there twoxstuck messages and the resuspend takes 10 seconds, afters this resuspend switching between ttys is normal (fast) again. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
DRM Vblank timestamping patches. 1st Try.
Hi all, after obsessing over these for another month after xds 2010, this is the first version of my vblank timestamping patches that i'm not totally ashamed off. 1st patch modifies the drm vblank handling to maintain precise timestamps of when vblanks happen. It timestamps the end of each vblank interval (= start of active scanout of the following frame), as required by the OpenML OML_sync_control extension spec, so the DRI2 swap sync bits should return proper timestamps to gl clients. It also takes care of keeping timestamps and vblcounts consistent across vblank irq on/off and hopefully fixes a few off-by-one vblank counts due to race conditions in those on/off bits. There is still one small race condition between the vblank on/off bits and the gpu (updating its hardware vblank counter at the wrong moment) which can cause miscounting of vblanks across enable/disable. I have an idea how to fix that, based on these patches but will need to tinker around with it a bit more. After that we could reduce the vblankoffdelay from 5000 msecs to something smaller like 100 msecs to save more power on desktops with desktop composition enabled, where already a blinking cursor in a terminal window or a ticking clock in the menu bar can keep vblanks turned on all the time with a 5000 msecs timeout. All the timestamping inside the drmWaitVblank ioctl() and in vblank event handling now uses the timestamps calculated in this patch. 2nd and 3rd patches add the new timestamping and scanout position functions to the i915 and radeon drivers. Wrt. what i showed you at xds, i made the following changes: I've moved the actual timestamping routine as a helper function into the core. kms drivers now optionally export the crtc scanout position query function in addition to the vblank timestamping function to the drm core. Whenever the core has to recalculate timestamps it goes like: core - kmsdriver-timestamping() - core-timestampinghelper() - kmsdriver-getscanoutposition() The kms driver can implement its own version of the timestamping function, e.g., using special hardware timestamping registers in some more recent gpu's, or it can simply export a getscanoutposition() function with standardized behaviour across drivers and call the timestamping routine implemented in the core. The routine in the core works in non-interlaced, non-doublescan video modes, with or without panel scaling. It can compensate for any random delay up to 1 video refresh duration. For more robustness one would need to use a gpu specific hardware method. I also moved the calculation of the constants needed for timetamping into the drm_crtc_helper routine, so they only get recalculated after a mode switch, not at each vblank. At modeset time i cache the adjusted_mode after validation/adjustment by the crtc and encoders inside the drm_crtc struct. Needed to account for panel scaling, and i have a few other ideas that would require that cached value. More details in the different commit messages and the code, just some more remarks. @Jesse: I replaced the n extra dynamically allocated spin-locks for n crtc's by one statically allocated lock shared by all crtc's and renamed it. I think i also worked all your other suggestions into the patches. Thanks a lot for your first review of the earlier version. The intel driver uses the timestamps inside the finish pageflip function for timestamps of bufferswap completion. I've tested with an Atom Mini netbook with Intel 945 GME gpu and there it works perfect. I don't have any other intel test machines, so the finish pageflip and scanout query functions for ironlake, gen6 and g4x aren't tested, only coded based on some of the intel manuals at xorg. In the pageflip irq handlers there is this uncertainty if pageflip irq's get delivered before or after the vblank irq's for the vblank interval of swap completion. The i945 delivers pagflip irq's before handling the vblank irq's so the completion handler needs to account for that. I guessed from the code, which ones do deliver before/after vblank, but that guesses may be wrong, so this needs testing. @Alex: Thanks for your feedback at xds. I think the radeon part should be as we discussed. The radeon patch builds onto what you committed already into drm-radeon-testing for the reclocking fixes. It slightly changes the interface between the scanout query function and radeon_pm_in_vbl(), but doesn't change the implementation. Testing of the timestamps on the Intel 945GME, a Radeon R500 and a R600 against external measurement equipment shows that the timestamps are essentially perfect. Error wrt. to the external measurement is less than 20 microseconds (for the radeon's) and jitter is +/- 1 usec. The intel error is less than 0.5 msecs, but i can't test how much better because my photo-diode can't do better and my usec precise equipment only works with DVI, but the intel test machine only has a vga output. Now this swapbuffers timestamping is only trustworthy for
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #33 from Tomasz Czapiewski xe...@irc.pl 2010-10-24 13:08:36 PDT --- Chris, yours suggestion was right! I've installed libtxc_dxtn.so some time ago as some apps (games) could use it. After removing this library the problem with rainbow colors/texture corruption in my case was resolved. The other workaround is to enable option 'Avoid loosy texture compression' in Xonotic menu which disables use of S3TC DDS textures. And that what Marek has suggested about texture corruption with high detail it was right, too but it didn't look like on those screenshots. I've found this problem when I've run Xonotic with KDE KWin desktop effects enabled and without libtxc_dxtn.so - not only the big FPS drop but there were many different problems with textures (black textures, black and white textures, black and white noise, screen smoothing with no textures, etc.). Disabling KWin desktop effects + using lower quality textures + removing libtxc_dxtn.so (so it disables GL_EXT_texture_compression_s3tc and GL_S3_s3tc extensions) altogether does make the problem disappear. And for texture formats that Xonotic needs - it uses JPG and TGA textures but DDS compressed textures, too and I'd like to use them as I could use better quality textures as I think it needs less RAM/VRAM(?) to handle them. And better quality textures compressed as DDS does not make any FPS drop. And most commercial games need S3TC. So IMO, it does look like it's a duplicate of 28800. Is there any chance to get this bug with libtxc_dxtn.so fixed to properly handle DDS compressed textures? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Tomasz Czapiewski xe...@irc.pl changed: What|Removed |Added Summary|[r300g][glsl] Texture |[r300g][glsl][libtxc_dxtn] |corruption in Xonotic with |Texture corruption in |lightmaps |Xonotic with lightmaps -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #35 from Tomasz Czapiewski xe...@irc.pl 2010-10-24 13:50:49 PDT --- Created an attachment (id=39744) -- (https://bugs.freedesktop.org/attachment.cgi?id=39744) RADEON_DEBUG=tex log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #36 from Tomasz Czapiewski xe...@irc.pl 2010-10-24 14:00:47 PDT --- So, the problematic textures are dxt1_rgb and/or dxt1_rgba. I've done some more testing and I've saw that when I have 60 FPS the problem is gone with S3TC+lightmaps (all textures are OK, no matter what I'm looking at on the map) but when the FPS gets dropped to 30 FPS the problem arrives or when the problem arrives I get FPS drop to 30(?). I wonder if the problem is with library or the S3TC handling by the driver itself. I wish I could enable S3TC on r300g without this library (as it could be done with r300c) to check if the textures sent to the card without software recoding library will have simmilar effect. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29389] [r300g] [bisected] hard locks with polling enabled in 2.6.35
https://bugs.freedesktop.org/show_bug.cgi?id=29389 --- Comment #6 from pj_be...@hotmail.com 2010-10-24 14:40:13 PDT --- I reported the same bug (I think) over here: https://bugzilla.kernel.org/show_bug.cgi?id=20042 Your latest patch disabling polling DACs works for my, I applied it to 2.6.36-rc7 and then ran Penumbra Overture without any problem. I'm using rv380, not rv370 (according to dmesg). I've included dmesg output as an attachment. Thanks very much for this patch! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29389] [r300g] [bisected] hard locks with polling enabled in 2.6.35
https://bugs.freedesktop.org/show_bug.cgi?id=29389 --- Comment #7 from pj_be...@hotmail.com 2010-10-24 14:43:21 PDT --- Created an attachment (id=39745) -- (https://bugs.freedesktop.org/attachment.cgi?id=39745) dmesg 2.6.36-rc7 with disabled polling DACs patch, rv380 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #37 from Chris Rankin ranki...@googlemail.com 2010-10-24 15:27:17 PDT --- (In reply to comment #36) I wish I could enable S3TC on r300g without this library (as it could be done with r300c) to check if the textures sent to the card without software recoding library will have simmilar effect. Have you tested whether the corruption happens with r300c too? It does with WoW (although r300g has fewer other bugs). Still, I'm glad you at least have a workaround available. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #39 from Marek Olšák mar...@gmail.com 2010-10-24 15:38:54 PDT --- (In reply to comment #38) (In reply to comment #32) In the kernel, there is function r100_copy_blit for copying buffers between RAM and VRAM using the 2D engine, and it's hooked up in the TTM. The function is used on r100 up to r500. I believe switching between the 2D and 3D engine doesn't work as it should or we don't flush some cache or something. Interesting theory - should this bug now include a title tag for r100-r500 DRM kernel modules? Not necessary, it's just a theory. It would be interesting to rewrite that function to use the 3D engine on r300 and see if it fixes anything. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29726] New CRTC ID query breaks Radeon DRM in Zaphod mode
https://bugs.freedesktop.org/show_bug.cgi?id=29726 --- Comment #7 from Alex Deucher ag...@yahoo.com 2010-10-24 22:09:03 PDT --- (In reply to comment #6) I was thinking you actually meant the .drirc setting rather than an actual environment variable but you were right. Setting this in .drirc makes no difference but the environment variable does indeed make the problem go away. It's works in the .drirc as well, but it requires slightly different handling for dri2 drivers, e.g., driconf device screen=0 driver=dri2 application name=Default option name=vblank_mode value=0 / /application /device /driconf I quite like vsyncing so I'm a little sad if it's broken. I think it was working before? It wasn't supported before. KMS vsync support was added with the commit cited in this bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #40 from Tomasz Czapiewski xe...@irc.pl 2010-10-24 22:16:30 PDT --- I've done some more testing in spectate mode (so I can go closer to walls, even fly through them) and my theory about 60-30 FPS drop does not work everytime as there are walls which can look at (very close look) where I have 60 FPS and the problem is still there but it might be something with lightning with lightmaps on just s3tc textures. The textures which (always) are not broken (probably not s3tc) when s3tc+lightmaps are enabled on the same map have working lightmaps effect. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
