[2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7)
On Thu, 12 May 2011 18:49:08 +0200, Melchior FRANZ wrote: > * Linus Torvalds -- Tuesday 10 May 2011: > > But please do test, just to make sure that 39-final is good. > > > Chris Wilson (4): > > drm/i915: Only enable the plane after setting the fb base (pre-ILK) > > This patch introduces a bug on my infamous "Acer Travelmate > 5735Z-452G32Mnss": when KMS takes over, the frame buffer contents > get completely garbled up on screen, with colored stripes and > unreadable text (photo on request). Only when X11 is started, the > screen gets restored again. Closing and re-opening the lid partly > cures the mess, too: it makes the font readable, though horizontally > stretched. So we think that enabling the plane at this point is masking a bug in our modeset, or that some side-effect of writing those registers or waiting for that vblank has a vital latching or delay that we have not accounted for. Can you please grab intel_reg_dumper from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools and attach its output after passing nomodeset on your kernel boot parameters (without starting X). That should capture the registers as they were left by the BIOS. Alternatively, if you load i915.ko as a module, you can run intel_reg_dumper before loading the module. Then can you attach the output from intel_reg_dumper from the VT before starting X (whilst the display is skewiff) and then after (when the display has recovered). That may help, unless we are right in that it is in the timing of the register writes. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm/radeon/kms: add some evergreen/ni safe regs
need to programmed from the userspace drivers. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/reg_srcs/cayman|1 + drivers/gpu/drm/radeon/reg_srcs/evergreen |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman b/drivers/gpu/drm/radeon/reg_srcs/cayman index 6334f8a..0aa8e85 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/cayman +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman @@ -33,6 +33,7 @@ cayman 0x9400 0x8E48 SQ_EX_ALLOC_TABLE_SLOTS 0x9100 SPI_CONFIG_CNTL 0x913C SPI_CONFIG_CNTL_1 +0x9508 TA_CNTL_AUX 0x9830 DB_DEBUG 0x9834 DB_DEBUG2 0x9838 DB_DEBUG3 diff --git a/drivers/gpu/drm/radeon/reg_srcs/evergreen b/drivers/gpu/drm/radeon/reg_srcs/evergreen index 7e16371..0e28cae 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/evergreen +++ b/drivers/gpu/drm/radeon/reg_srcs/evergreen @@ -46,6 +46,7 @@ evergreen 0x9400 0x8E48 SQ_EX_ALLOC_TABLE_SLOTS 0x9100 SPI_CONFIG_CNTL 0x913C SPI_CONFIG_CNTL_1 +0x9508 TA_CNTL_AUX 0x9700 VC_CNTL 0x9714 VC_ENHANCE 0x9830 DB_DEBUG -- 1.7.1.1
[Bug 37157] [bisected] KDE KWin crashes on start with delayed BO mapping
https://bugs.freedesktop.org/show_bug.cgi?id=37157 --- Comment #4 from Dave Airlie 2011-05-12 21:05:51 PDT --- please re-test with master. thanks for the bug report. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37157] [bisected] KDE KWin crashes on start with delayed BO mapping
https://bugs.freedesktop.org/show_bug.cgi?id=37157 --- Comment #3 from Mathieu Belanger 2011-05-12 20:47:50 PDT --- Same commit cause problem there. Using EVE-Online game. The game crash between "login" and "characters selection" after I have updated to the latest git drivers. Bisecting pointed out this commit as the problem! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37157] [bisected] KDE KWin crashes on start with delayed BO mapping
https://bugs.freedesktop.org/show_bug.cgi?id=37157 --- Comment #2 from Jure Repinc 2011-05-12 18:57:04 PDT --- Created an attachment (id=46655) --> (https://bugs.freedesktop.org/attachment.cgi?id=46655) Xorg.0.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 37157] [bisected] KDE KWin crashes on start with delayed BO mapping
https://bugs.freedesktop.org/show_bug.cgi?id=37157 --- Comment #1 from Jure Repinc 2011-05-12 18:56:24 PDT --- Created an attachment (id=46654) --> (https://bugs.freedesktop.org/attachment.cgi?id=46654) lspci -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37157] New: [bisected] KDE KWin crashes on start with delayed BO mapping
https://bugs.freedesktop.org/show_bug.cgi?id=37157 Summary: [bisected] KDE KWin crashes on start with delayed BO mapping Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: jlp.bugs at gmail.com After updating the mesa today KWin started to crash/segfault on start. I've bisected and the first commmit that causes the crash is: 5e15497452cf3e4d2fc76fdc6ed8113d0891b467 r600g: delay mapping until first map request. (v2) This is with KDE KWin 4.6.3 and on a laptop with integrated ATI Mobility Radeon HD 5470. Later I've also tried with glxgears, which appears to work fine if in window and crashes if started with -fullscreen option. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7)
* Linus Torvalds -- Tuesday 10 May 2011: > But please do test, just to make sure that 39-final is good. > Chris Wilson (4): > drm/i915: Only enable the plane after setting the fb base (pre-ILK) This patch introduces a bug on my infamous "Acer Travelmate 5735Z-452G32Mnss": when KMS takes over, the frame buffer contents get completely garbled up on screen, with colored stripes and unreadable text (photo on request). Only when X11 is started, the screen gets restored again. Closing and re-opening the lid partly cures the mess, too: it makes the font readable, though horizontally stretched. Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the bug. m. drm.debug=0x02 [2.604831] [drm] Initialized drm 1.1.0 20060810 [2.648409] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [2.648415] i915 :00:02.0: setting latency timer to 64 [2.708949] [drm:intel_opregion_setup], graphic opregion physical addr: 0x7ba8c018 [2.708987] [drm:intel_opregion_setup], Public ACPI methods supported [2.708989] [drm:intel_opregion_setup], SWSCI supported [2.708991] [drm:intel_opregion_setup], ASLE supported [2.709047] i915 :00:02.0: irq 44 for MSI/MSI-X [2.709053] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.709054] [drm] Driver supports precise vblank timestamp query. [2.735626] [drm:init_status_page], render ring hws offset: 0x [2.735747] [drm:init_status_page], bsd ring hws offset: 0x00021000 [2.735852] [drm:intel_parse_bios], Using VBT from OpRegion: $VBT CANTIGA d [2.779279] [drm:intel_panel_get_backlight], get backlight PWM = 0 [2.779287] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [2.779616] [drm:intel_panel_set_backlight], set backlight PWM = 0 [2.779619] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [2.779626] [drm:intel_opregion_asle_intr], non asle set request?? [3.022059] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe A [3.022065] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe A [3.074270] checking generic (8000 3ff) vs hw (8000 1000) [3.074274] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver [3.074293] Console: switching to colour dummy device 80x25 [3.074806] fbcon: inteldrmfb (fb0) is primary device [3.109085] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [3.109087] [drm:intel_panel_set_backlight], set backlight PWM = 736950 [3.109090] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [3.109098] [drm:intel_opregion_asle_intr], non asle set request?? [3.109111] Console: switching to colour frame buffer device 170x48 [3.111779] fb0: inteldrmfb frame buffer device [3.111780] drm: registered panic notifier [3.158015] scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS [3.413081] acpi device:07: registered as cooling_device2 [3.413431] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input6 [3.413532] ACPI: Video Device [OVGA] (multi-head: yes rom: no post: no) [3.413982] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [4.059019] sd 4:0:0:0: [sdb] 15720448 512-byte logical blocks: (8.04 GB/7.49 GiB) [4.059746] sd 4:0:0:0: [sdb] Write Protect is off [4.059750] sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00 [4.059752] sd 4:0:0:0: [sdb] Assuming drive cache: write through [4.061879] sd 4:0:0:0: [sdb] Assuming drive cache: write through [4.066269] sdb: sdb1 [4.067995] sd 4:0:0:0: [sdb] Assuming drive cache: write through [4.068056] sd 4:0:0:0: [sdb] Attached SCSI removable disk [5.016884] md: linear personality registered for level -1 [ 94.800469] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 94.800473] [drm:intel_panel_set_backlight], set backlight PWM = 72250 [ 94.800477] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 94.800482] [drm:intel_opregion_asle_intr], non asle set request?? [ 94.800485] [drm:intel_opregion_asle_intr], non asle set request??
[PATCH] drm/radeon: Make atom_debug a module parameter
If we're going to build atom debugging all the time anyway, we might as
well make it easy to get at.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/radeon/atom.c |1 -
drivers/gpu/drm/radeon/radeon_drv.c |4
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 258fa5e..ec01112 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -61,7 +61,6 @@ typedef struct {
bool abort;
} atom_exec_context;
-int atom_debug = 0;
static int atom_execute_table_locked(struct atom_context *ctx, int index,
uint32_t * params);
int atom_execute_table(struct atom_context *ctx, int index, uint32_t * params);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 63d2de8..f7b6aae 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -116,6 +116,7 @@ int radeon_audio = 1;
int radeon_disp_priority = 0;
int radeon_hw_i2c = 0;
int radeon_pcie_gen2 = 0;
+int atom_debug = 0;
MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
module_param_named(no_wb, radeon_no_wb, int, 0444);
@@ -162,6 +163,9 @@ module_param_named(hw_i2c, radeon_hw_i2c, int, 0444);
MODULE_PARM_DESC(pcie_gen2, "PCIE Gen2 mode (1 = enable)");
module_param_named(pcie_gen2, radeon_pcie_gen2, int, 0444);
+MODULE_PARM_DESC(atom_debug, "Debug atombios execution (1 = enable)");
+module_param_named(atom_debug, atom_debug, int, 0444);
+
static int radeon_suspend(struct drm_device *dev, pm_message_t state)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
--
1.7.4.4
[PATCH 2/2] drm/i915: TVDAC_STATE_CHG does not indicate successful load-detect
Do not use this bit to indicate that load detection has completed,
instead just wait for vblank, at which point the load registers will
have been updated.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_tv.c | 40 +++---
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 876064c..b371863 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1283,26 +1283,26 @@ intel_tv_detect_type (struct intel_tv *intel_tv,
to_intel_crtc(intel_tv->base.base.crtc)->pipe);
type = -1;
- if (wait_for((tv_dac = I915_READ(TV_DAC)) & TVDAC_STATE_CHG, 20) == 0) {
- DRM_DEBUG_KMS("TV detected: %x, %x\n", tv_ctl, tv_dac);
- /*
-* A B C
-* 0 1 1 Composite
-* 1 0 X svideo
-* 0 0 0 Component
-*/
- if ((tv_dac & TVDAC_SENSE_MASK) == (TVDAC_B_SENSE |
TVDAC_C_SENSE)) {
- DRM_DEBUG_KMS("Detected Composite TV connection\n");
- type = DRM_MODE_CONNECTOR_Composite;
- } else if ((tv_dac & (TVDAC_A_SENSE|TVDAC_B_SENSE)) ==
TVDAC_A_SENSE) {
- DRM_DEBUG_KMS("Detected S-Video TV connection\n");
- type = DRM_MODE_CONNECTOR_SVIDEO;
- } else if ((tv_dac & TVDAC_SENSE_MASK) == 0) {
- DRM_DEBUG_KMS("Detected Component TV connection\n");
- type = DRM_MODE_CONNECTOR_Component;
- } else {
- DRM_DEBUG_KMS("Unrecognised TV connection\n");
- }
+ tv_dac = I915_READ(TV_DAC);
+ DRM_DEBUG_KMS("TV detected: %x, %x\n", tv_ctl, tv_dac);
+ /*
+* A B C
+* 0 1 1 Composite
+* 1 0 X svideo
+* 0 0 0 Component
+*/
+ if ((tv_dac & TVDAC_SENSE_MASK) == (TVDAC_B_SENSE | TVDAC_C_SENSE)) {
+ DRM_DEBUG_KMS("Detected Composite TV connection\n");
+ type = DRM_MODE_CONNECTOR_Composite;
+ } else if ((tv_dac & (TVDAC_A_SENSE|TVDAC_B_SENSE)) == TVDAC_A_SENSE) {
+ DRM_DEBUG_KMS("Detected S-Video TV connection\n");
+ type = DRM_MODE_CONNECTOR_SVIDEO;
+ } else if ((tv_dac & TVDAC_SENSE_MASK) == 0) {
+ DRM_DEBUG_KMS("Detected Component TV connection\n");
+ type = DRM_MODE_CONNECTOR_Component;
+ } else {
+ DRM_DEBUG_KMS("Unrecognised TV connection\n");
+ type = -1;
}
I915_WRITE(TV_DAC, save_tv_dac & ~TVDAC_STATE_CHG_EN);
--
1.7.5.1
[PATCH 1/2] drm/i915: Select correct pipe during TV detect
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_tv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 6b22c1d..876064c 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1236,6 +1236,8 @@ intel_tv_detect_type (struct intel_tv *intel_tv,
struct drm_connector *connector)
{
struct drm_encoder *encoder = _tv->base.base;
+ struct drm_crtc *crtc = encoder->crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned long irqflags;
@@ -1258,6 +1260,10 @@ intel_tv_detect_type (struct intel_tv *intel_tv,
/* Poll for TV detection */
tv_ctl &= ~(TV_ENC_ENABLE | TV_TEST_MODE_MASK);
tv_ctl |= TV_TEST_MODE_MONITOR_DETECT;
+ if (intel_crtc->pipe == 1)
+ tv_ctl |= TV_ENC_PIPEB_SELECT;
+ else
+ tv_ctl &= ~TV_ENC_PIPEB_SELECT;
tv_dac &= ~(TVDAC_SENSE_MASK | DAC_A_MASK | DAC_B_MASK | DAC_C_MASK);
tv_dac |= (TVDAC_STATE_CHG_EN |
--
1.7.5.1
[Bug 37151] Random GPU Resets on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=37151 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Alex Deucher 2011-05-12 14:23:28 PDT --- *** This bug has been marked as a duplicate of bug 36542 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)
https://bugs.freedesktop.org/show_bug.cgi?id=36542 Alex Deucher changed: What|Removed |Added CC||spamjunkeater at gmail.com --- Comment #3 from Alex Deucher 2011-05-12 14:23:28 PDT --- *** Bug 37151 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 37151] Random GPU Resets on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=37151 Alex Deucher changed: What|Removed |Added Attachment #46648|application/octet-stream|text/plain mime type|| Attachment #46648|0 |1 is 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 37151] New: Random GPU Resets on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=37151 Summary: Random GPU Resets on HD6850-NI Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: spamjunkeater at gmail.com Created an attachment (id=46648) --> (https://bugs.freedesktop.org/attachment.cgi?id=46648) Kernel messages about resets... I got random GPU resets on my HD6850 using mesa r600g/xf86-video-ati/drm git trunk. Sometimes GPU has multiple resets following each other. Using Linux Kernel Vanilla 2.6.38. Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken (glean/texture_srgb broken too)
https://bugs.freedesktop.org/show_bug.cgi?id=36965 --- Comment #5 from Pavel Ondra?ka 2011-05-12 14:07:59 PDT --- (In reply to comment #4) > There is a lot of other code which plays role in handling sRGB textures. I > don't think getteximage.c is relevant to this issue(s). > > Nevertheless, it looks like Pavel's and Martin's issues are different bugs. > > Pavel reported that GL_EXT_texture_sRGB_decode, which is only in 7.11, is > broken specifically on r300g, but other drivers might be affected as well and > it definitely looks like a Mesa core bug. Pavel, could you please add it as a > new bug against Mesa core? > Reported against mesa core as bug 37150. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34252] Unexpected behaviour when switching video cards with vga_switcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=34252 --- Comment #10 from Florian Mickler 2011-05-12 14:04:20 --- Created an attachment (id=57582) --> (https://bugzilla.kernel.org/attachment.cgi?id=57582) Proposed fix Can you test this patch? I don't have any switcheroo setup, but it makes sense and compiles. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 36386] Amnesia game crashes on RV570 (r300g)
https://bugs.freedesktop.org/show_bug.cgi?id=36386 Sven Arvidsson changed: What|Removed |Added CC||sa at whiz.se --- Comment #3 from Sven Arvidsson 2011-05-12 13:38:06 PDT --- Amnesia is working fine on my RV570, both with 7.10.2 and with git master. Keep in mind that the game is multithreaded, so you might need to do "thread apply all bt full" to get a meaningful backtrace. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 --- Comment #4 from Pierre-Eric Pelloux-Prayer 2011-05-12 13:27:09 PDT --- (In reply to comment #2) > (In reply to comment #0) > > What do you think ? > > You can't optimize the uploads because the sizes of all buffers are not known > when glLockArraysEXT is called. The only things you've got are pointers to the > buffers. Sure, but I was thinking to something more like : - glLockArraysEXT does nothing more than curently - uploading a vertex buffer is done as before except in one case : when trying to upload the same buffer AND glLock is enabled => the uploading is skipped as data is already in GPU memory (which is the case shown in the attached trace file) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 --- Comment #3 from Pierre-Eric Pelloux-Prayer 2011-05-12 13:19:13 PDT --- > EXT_compiled_vertex_array is dead. It has been dead for almost 10 years. No > new applications should use it, and old applications that use it should be > fast > enough on modern hardware. I really don't think we should add any code to > Mesa > to make this case fast. We'd be better off submitting patches to openarena to > use VBOs instead. That's why I asked for external opinions. I still feel that IF it can brings significant enough performance improvement, it could be useful - mainly because openarena and all games using quake3 based engine are used in every open-source drivers benchmarks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36527] [wine] Wolfenstein: Failed to translate rgb instruction.
https://bugs.freedesktop.org/show_bug.cgi?id=36527 --- Comment #14 from Sven Arvidsson 2011-05-12 13:08:43 PDT --- (In reply to comment #13) > Created an attachment (id=46461) View: https://bugs.freedesktop.org/attachment.cgi?id=46461 Review: https://bugs.freedesktop.org/review?bug=36527=46461 > Fix v4 > > I found a bug in the previous patch (v3). Can you try this new one and make > sure it still works. Yep, still works! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 --- Comment #2 from Marek Ol??k 2011-05-12 12:55:38 PDT --- (In reply to comment #0) > What do you think ? You can't optimize the uploads because the sizes of all buffers are not known when glLockArraysEXT is called. The only things you've got are pointers to the buffers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken (glean/texture_srgb broken too)
https://bugs.freedesktop.org/show_bug.cgi?id=36965 Marek Ol??k changed: What|Removed |Added Summary|GL_EXT_texture_sRGB |GL_EXT_texture_sRGB |(included in OpenGL 2.1) is |(included in OpenGL 2.1) is |broken |broken (glean/texture_srgb ||broken too) --- Comment #4 from Marek Ol??k 2011-05-12 12:50:02 PDT --- There is a lot of other code which plays role in handling sRGB textures. I don't think getteximage.c is relevant to this issue(s). Nevertheless, it looks like Pavel's and Martin's issues are different bugs. Pavel reported that GL_EXT_texture_sRGB_decode, which is only in 7.11, is broken specifically on r300g, but other drivers might be affected as well and it definitely looks like a Mesa core bug. Pavel, could you please add it as a new bug against Mesa core? Martin's issue is likely related to the fact that piglit/glean/texture_srgb fails on r600g. Taking a look at it might be a good start. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] Revert "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"
This reverts commit 49183b2818de6899383bb82bc032f9344d6791ff. Franz Melchior: This patch introduces a bug on my infamous "Acer Travelmate 5735Z-452G32Mnss": when KMS takes over, the frame buffer contents get completely garbled up on screen, with colored stripes and unreadable text (photo on request). Only when X11 is started, the screen gets restored again. Closing and re-opening the lid partly cures the mess, too: it makes the font readable, though horizontally stretched. --- On Thu, 12 May 2011 18:49:08 +0200, Melchior FRANZ wrote: > * Linus Torvalds -- Tuesday 10 May 2011: > > But please do test, just to make sure that 39-final is good. > > > Chris Wilson (4): > > drm/i915: Only enable the plane after setting the fb base (pre-ILK) > > This patch introduces a bug on my infamous "Acer Travelmate > 5735Z-452G32Mnss": when KMS takes over, the frame buffer contents > get completely garbled up on screen, with colored stripes and > unreadable text (photo on request). Only when X11 is started, the > screen gets restored again. Closing and re-opening the lid partly > cures the mess, too: it makes the font readable, though horizontally > stretched. > > Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the > bug. It's Whack-a-Mole time! Fix one laptop, break another. We'll pick 'no regressions' over 'fixes existing bug' today. drivers/gpu/drm/i915/intel_display.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 373c2a0..2166ee0 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5154,6 +5154,8 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); + if (!HAS_PCH_SPLIT(dev)) + intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); -- 1.7.5.1 -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110512/76b4707b/attachment.pgp>
[Bug 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 --- Comment #1 from Ian Romanick 2011-05-12 10:55:30 PDT --- (In reply to comment #0) > Created an attachment (id=46638) --> (https://bugs.freedesktop.org/attachment.cgi?id=46638) > openarena + verbose vertex buffer upload logs > > Test case : openarena + anholt benchmark + r600g > > I added several fprintf debug trace to mesa code around Vertex buffer > uploading. > Basically, openarena render things using : > glVertexPointeer() > glLockArraysEXT() > several glDrawElements() > glUnlockArraysEXT() > > It seems that each call to glDrawElements implies a reupload of the vertex > buffers, even if it has not changed (as glLock/Unlock calls tell, at least for > part of the buffer). EXT_compiled_vertex_array is dead. It has been dead for almost 10 years. No new applications should use it, and old applications that use it should be fast enough on modern hardware. I really don't think we should add any code to Mesa to make this case fast. We'd be better off submitting patches to openarena to use VBOs instead. > Another related bug (it seems) is in : cso_set_vertex_buffers() which does a > test before calling : util_copy_vertex_buffers and pipe->set_vertex_buffers > This test always return true, thus the 2 above functions are always called. > The > test is always true because it memcmp all pipe_vertex_buffer, which contains a > 'buffer' pointer, which changes at each frame (see st_draw.c:349). > > I'm trying to build a patch which fix the cso_set_vertex_buffers problem and > then, taking advantage of glLock/Unlock calls to fix the upload issue. > > What do you think ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 Ian Romanick changed: What|Removed |Added Attachment #46638|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 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken
https://bugs.freedesktop.org/show_bug.cgi?id=36965 --- Comment #3 from Martin Lambers 2011-05-12 10:20:51 PDT --- (In reply to comment #2) > BTW this should be probably a mesa core bug, right? There is code in Mesa to handle SRGB textures correctly, see http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/texgetimage.c lines 223-301. I guess drivers can override this, but I don't know the internal structure of Mesa. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken
https://bugs.freedesktop.org/show_bug.cgi?id=36965 --- Comment #2 from Pavel Ondra?ka 2011-05-12 09:18:11 PDT --- BTW this should be probably a mesa core bug, right? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken
https://bugs.freedesktop.org/show_bug.cgi?id=36965 --- Comment #1 from Pavel Ondra?ka 2011-05-12 09:11:08 PDT --- I see similar problems in Starcraft 2, there are also over bright textures which go away when MESA_EXTENSION_OVERRIDE="-GL_EXT_texture_sRGB_decode" is set. OpenGL renderer string: Gallium 0.4 on ATI RV530 OpenGL version string: 2.1 Mesa 7.11-devel (git-32a95cb) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 Michel D?nzer changed: What|Removed |Added Product|DRI |Mesa Version|DRI CVS |git Component|DRM/Radeon |Drivers/Gallium/r600 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37142] New: Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 Summary: Too much vertex buffers uploads Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: pelloux at gmail.com Created an attachment (id=46638) --> (https://bugs.freedesktop.org/attachment.cgi?id=46638) openarena + verbose vertex buffer upload logs Test case : openarena + anholt benchmark + r600g I added several fprintf debug trace to mesa code around Vertex buffer uploading. Basically, openarena render things using : glVertexPointeer() glLockArraysEXT() several glDrawElements() glUnlockArraysEXT() It seems that each call to glDrawElements implies a reupload of the vertex buffers, even if it has not changed (as glLock/Unlock calls tell, at least for part of the buffer). Another related bug (it seems) is in : cso_set_vertex_buffers() which does a test before calling : util_copy_vertex_buffers and pipe->set_vertex_buffers This test always return true, thus the 2 above functions are always called. The test is always true because it memcmp all pipe_vertex_buffer, which contains a 'buffer' pointer, which changes at each frame (see st_draw.c:349). I'm trying to build a patch which fix the cso_set_vertex_buffers problem and then, taking advantage of glLock/Unlock calls to fix the upload issue. What do you think ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26891] Radeon KMS on Macs with EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #2 from shirk at bitspin.org 2011-05-12 05:06:39 PDT --- Hi, since I'm triple booting my MBP for some time now (using mostly grub2 at efi) I integrated your patch im my local git tree and can confirm it works as intended. Without using radeon-ucode binaries I'm able to run X in full resolution without any trouble (no direct rendering however). I was even able to compile the radeon kms driver directly into the kernel by including the vbios / ucode binaries as blobs or placing them in my intramfs. However when trying to enable direct rendering (by loading radion-ucodes) I get some serious display flicker and sometimes a wrong display placement. Looks like some timings are horribly wrong.. I really love to be able to boot my kernel in pure EFI mode without fakebios etc. If I can be of any help to improve the situation let me know. I'm not unexperienced in kernel/driver coding and I'm a happy guinea pig ;) -- my hardware specs -- MacBookPro8,2 (early 2011) - Intel Core I7 (2,2Ghz, quad) - ATI Radeon HD 6750m (the 1Gb model) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26891] Radeon KMS on Macs with EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #2 from sh...@bitspin.org 2011-05-12 05:06:39 PDT --- Hi, since I'm triple booting my MBP for some time now (using mostly grub2@efi) I integrated your patch im my local git tree and can confirm it works as intended. Without using radeon-ucode binaries I'm able to run X in full resolution without any trouble (no direct rendering however). I was even able to compile the radeon kms driver directly into the kernel by including the vbios / ucode binaries as blobs or placing them in my intramfs. However when trying to enable direct rendering (by loading radion-ucodes) I get some serious display flicker and sometimes a wrong display placement. Looks like some timings are horribly wrong.. I really love to be able to boot my kernel in pure EFI mode without fakebios etc. If I can be of any help to improve the situation let me know. I'm not unexperienced in kernel/driver coding and I'm a happy guinea pig ;) -- my hardware specs -- MacBookPro8,2 (early 2011) - Intel Core I7 (2,2Ghz, quad) - ATI Radeon HD 6750m (the 1Gb model) -- 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 34252] Unexpected behaviour when switching video cards with vga_switcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=34252 --- Comment #10 from Florian Mickler flor...@mickler.org 2011-05-12 14:04:20 --- Created an attachment (id=57582) -- (https://bugzilla.kernel.org/attachment.cgi?id=57582) Proposed fix Can you test this patch? I don't have any switcheroo setup, but it makes sense and compiles. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37142] New: Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 Summary: Too much vertex buffers uploads Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pell...@gmail.com Created an attachment (id=46638) -- (https://bugs.freedesktop.org/attachment.cgi?id=46638) openarena + verbose vertex buffer upload logs Test case : openarena + anholt benchmark + r600g I added several fprintf debug trace to mesa code around Vertex buffer uploading. Basically, openarena render things using : glVertexPointeer() glLockArraysEXT() several glDrawElements() glUnlockArraysEXT() It seems that each call to glDrawElements implies a reupload of the vertex buffers, even if it has not changed (as glLock/Unlock calls tell, at least for part of the buffer). Another related bug (it seems) is in : cso_set_vertex_buffers() which does a test before calling : util_copy_vertex_buffers and pipe-set_vertex_buffers This test always return true, thus the 2 above functions are always called. The test is always true because it memcmp all pipe_vertex_buffer, which contains a 'buffer' pointer, which changes at each frame (see st_draw.c:349). I'm trying to build a patch which fix the cso_set_vertex_buffers problem and then, taking advantage of glLock/Unlock calls to fix the upload issue. What do you think ? -- 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 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken
https://bugs.freedesktop.org/show_bug.cgi?id=36965 --- Comment #1 from Pavel Ondračka pavel.ondra...@email.cz 2011-05-12 09:11:08 PDT --- I see similar problems in Starcraft 2, there are also over bright textures which go away when MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_sRGB_decode is set. OpenGL renderer string: Gallium 0.4 on ATI RV530 OpenGL version string: 2.1 Mesa 7.11-devel (git-32a95cb) -- 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 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken
https://bugs.freedesktop.org/show_bug.cgi?id=36965 --- Comment #2 from Pavel Ondračka pavel.ondra...@email.cz 2011-05-12 09:18:11 PDT --- BTW this should be probably a mesa core bug, right? -- 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
[2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7)
* Linus Torvalds -- Tuesday 10 May 2011: But please do test, just to make sure that 39-final is good. Chris Wilson (4): drm/i915: Only enable the plane after setting the fb base (pre-ILK) This patch introduces a bug on my infamous Acer Travelmate 5735Z-452G32Mnss: when KMS takes over, the frame buffer contents get completely garbled up on screen, with colored stripes and unreadable text (photo on request). Only when X11 is started, the screen gets restored again. Closing and re-opening the lid partly cures the mess, too: it makes the font readable, though horizontally stretched. Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the bug. m. drm.debug=0x02 [2.604831] [drm] Initialized drm 1.1.0 20060810 [2.648409] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [2.648415] i915 :00:02.0: setting latency timer to 64 [2.708949] [drm:intel_opregion_setup], graphic opregion physical addr: 0x7ba8c018 [2.708987] [drm:intel_opregion_setup], Public ACPI methods supported [2.708989] [drm:intel_opregion_setup], SWSCI supported [2.708991] [drm:intel_opregion_setup], ASLE supported [2.709047] i915 :00:02.0: irq 44 for MSI/MSI-X [2.709053] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.709054] [drm] Driver supports precise vblank timestamp query. [2.735626] [drm:init_status_page], render ring hws offset: 0x [2.735747] [drm:init_status_page], bsd ring hws offset: 0x00021000 [2.735852] [drm:intel_parse_bios], Using VBT from OpRegion: $VBT CANTIGA d [2.779279] [drm:intel_panel_get_backlight], get backlight PWM = 0 [2.779287] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [2.779616] [drm:intel_panel_set_backlight], set backlight PWM = 0 [2.779619] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [2.779626] [drm:intel_opregion_asle_intr], non asle set request?? [3.022059] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe A [3.022065] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe A [3.074270] checking generic (8000 3ff) vs hw (8000 1000) [3.074274] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver [3.074293] Console: switching to colour dummy device 80x25 [3.074806] fbcon: inteldrmfb (fb0) is primary device [3.109085] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [3.109087] [drm:intel_panel_set_backlight], set backlight PWM = 736950 [3.109090] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [3.109098] [drm:intel_opregion_asle_intr], non asle set request?? [3.109111] Console: switching to colour frame buffer device 170x48 [3.111779] fb0: inteldrmfb frame buffer device [3.111780] drm: registered panic notifier [3.158015] scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS [3.413081] acpi device:07: registered as cooling_device2 [3.413431] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input6 [3.413532] ACPI: Video Device [OVGA] (multi-head: yes rom: no post: no) [3.413982] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [4.059019] sd 4:0:0:0: [sdb] 15720448 512-byte logical blocks: (8.04 GB/7.49 GiB) [4.059746] sd 4:0:0:0: [sdb] Write Protect is off [4.059750] sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00 [4.059752] sd 4:0:0:0: [sdb] Assuming drive cache: write through [4.061879] sd 4:0:0:0: [sdb] Assuming drive cache: write through [4.066269] sdb: sdb1 [4.067995] sd 4:0:0:0: [sdb] Assuming drive cache: write through [4.068056] sd 4:0:0:0: [sdb] Attached SCSI removable disk [5.016884] md: linear personality registered for level -1 [ 94.800469] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 94.800473] [drm:intel_panel_set_backlight], set backlight PWM = 72250 [ 94.800477] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 94.800482] [drm:intel_opregion_asle_intr], non asle set request?? [ 94.800485] [drm:intel_opregion_asle_intr], non asle set request?? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken
https://bugs.freedesktop.org/show_bug.cgi?id=36965 --- Comment #3 from Martin Lambers mar...@marlam.de 2011-05-12 10:20:51 PDT --- (In reply to comment #2) BTW this should be probably a mesa core bug, right? There is code in Mesa to handle SRGB textures correctly, see http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/texgetimage.c lines 223-301. I guess drivers can override this, but I don't know the internal structure of Mesa. -- 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 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 Ian Romanick i...@freedesktop.org changed: What|Removed |Added Attachment #46638|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 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 --- Comment #1 from Ian Romanick i...@freedesktop.org 2011-05-12 10:55:30 PDT --- (In reply to comment #0) Created an attachment (id=46638) -- (https://bugs.freedesktop.org/attachment.cgi?id=46638) openarena + verbose vertex buffer upload logs Test case : openarena + anholt benchmark + r600g I added several fprintf debug trace to mesa code around Vertex buffer uploading. Basically, openarena render things using : glVertexPointeer() glLockArraysEXT() several glDrawElements() glUnlockArraysEXT() It seems that each call to glDrawElements implies a reupload of the vertex buffers, even if it has not changed (as glLock/Unlock calls tell, at least for part of the buffer). EXT_compiled_vertex_array is dead. It has been dead for almost 10 years. No new applications should use it, and old applications that use it should be fast enough on modern hardware. I really don't think we should add any code to Mesa to make this case fast. We'd be better off submitting patches to openarena to use VBOs instead. Another related bug (it seems) is in : cso_set_vertex_buffers() which does a test before calling : util_copy_vertex_buffers and pipe-set_vertex_buffers This test always return true, thus the 2 above functions are always called. The test is always true because it memcmp all pipe_vertex_buffer, which contains a 'buffer' pointer, which changes at each frame (see st_draw.c:349). I'm trying to build a patch which fix the cso_set_vertex_buffers problem and then, taking advantage of glLock/Unlock calls to fix the upload issue. What do you think ? -- 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
[PATCH] Revert drm/i915: Only enable the plane after setting the fb base (pre-ILK)
This reverts commit 49183b2818de6899383bb82bc032f9344d6791ff. Franz Melchior: This patch introduces a bug on my infamous Acer Travelmate 5735Z-452G32Mnss: when KMS takes over, the frame buffer contents get completely garbled up on screen, with colored stripes and unreadable text (photo on request). Only when X11 is started, the screen gets restored again. Closing and re-opening the lid partly cures the mess, too: it makes the font readable, though horizontally stretched. --- On Thu, 12 May 2011 18:49:08 +0200, Melchior FRANZ melchior.fr...@gmail.com wrote: * Linus Torvalds -- Tuesday 10 May 2011: But please do test, just to make sure that 39-final is good. Chris Wilson (4): drm/i915: Only enable the plane after setting the fb base (pre-ILK) This patch introduces a bug on my infamous Acer Travelmate 5735Z-452G32Mnss: when KMS takes over, the frame buffer contents get completely garbled up on screen, with colored stripes and unreadable text (photo on request). Only when X11 is started, the screen gets restored again. Closing and re-opening the lid partly cures the mess, too: it makes the font readable, though horizontally stretched. Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the bug. It's Whack-a-Mole time! Fix one laptop, break another. We'll pick 'no regressions' over 'fixes existing bug' today. drivers/gpu/drm/i915/intel_display.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 373c2a0..2166ee0 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5154,6 +5154,8 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); + if (!HAS_PCH_SPLIT(dev)) + intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); -- 1.7.5.1 pgp7iw3faVEDB.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken (glean/texture_srgb broken too)
https://bugs.freedesktop.org/show_bug.cgi?id=36965 Marek Olšák mar...@gmail.com changed: What|Removed |Added Summary|GL_EXT_texture_sRGB |GL_EXT_texture_sRGB |(included in OpenGL 2.1) is |(included in OpenGL 2.1) is |broken |broken (glean/texture_srgb ||broken too) --- Comment #4 from Marek Olšák mar...@gmail.com 2011-05-12 12:50:02 PDT --- There is a lot of other code which plays role in handling sRGB textures. I don't think getteximage.c is relevant to this issue(s). Nevertheless, it looks like Pavel's and Martin's issues are different bugs. Pavel reported that GL_EXT_texture_sRGB_decode, which is only in 7.11, is broken specifically on r300g, but other drivers might be affected as well and it definitely looks like a Mesa core bug. Pavel, could you please add it as a new bug against Mesa core? Martin's issue is likely related to the fact that piglit/glean/texture_srgb fails on r600g. Taking a look at it might be a good start. -- 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 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 --- Comment #2 from Marek Olšák mar...@gmail.com 2011-05-12 12:55:38 PDT --- (In reply to comment #0) What do you think ? You can't optimize the uploads because the sizes of all buffers are not known when glLockArraysEXT is called. The only things you've got are pointers to the buffers. -- 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 36527] [wine] Wolfenstein: Failed to translate rgb instruction.
https://bugs.freedesktop.org/show_bug.cgi?id=36527 --- Comment #14 from Sven Arvidsson s...@whiz.se 2011-05-12 13:08:43 PDT --- (In reply to comment #13) Created an attachment (id=46461) View: https://bugs.freedesktop.org/attachment.cgi?id=46461 Review: https://bugs.freedesktop.org/review?bug=36527attachment=46461 Fix v4 I found a bug in the previous patch (v3). Can you try this new one and make sure it still works. Yep, still works! -- 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 36386] Amnesia game crashes on RV570 (r300g)
https://bugs.freedesktop.org/show_bug.cgi?id=36386 Sven Arvidsson s...@whiz.se changed: What|Removed |Added CC||s...@whiz.se --- Comment #3 from Sven Arvidsson s...@whiz.se 2011-05-12 13:38:06 PDT --- Amnesia is working fine on my RV570, both with 7.10.2 and with git master. Keep in mind that the game is multithreaded, so you might need to do thread apply all bt full to get a meaningful backtrace. -- 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 37151] Random GPU Resets on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=37151 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #46648|application/octet-stream|text/plain mime type|| Attachment #46648|0 |1 is 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 37151] Random GPU Resets on HD6850-NI
https://bugs.freedesktop.org/show_bug.cgi?id=37151 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Alex Deucher ag...@yahoo.com 2011-05-12 14:23:28 PDT --- *** This bug has been marked as a duplicate of bug 36542 *** -- 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 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)
https://bugs.freedesktop.org/show_bug.cgi?id=36542 Alex Deucher ag...@yahoo.com changed: What|Removed |Added CC||spamjunkea...@gmail.com --- Comment #3 from Alex Deucher ag...@yahoo.com 2011-05-12 14:23:28 PDT --- *** Bug 37151 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
Re: [2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7)
On Thu, 12 May 2011 18:49:08 +0200, Melchior FRANZ melchior.fr...@gmail.com wrote: * Linus Torvalds -- Tuesday 10 May 2011: But please do test, just to make sure that 39-final is good. Chris Wilson (4): drm/i915: Only enable the plane after setting the fb base (pre-ILK) This patch introduces a bug on my infamous Acer Travelmate 5735Z-452G32Mnss: when KMS takes over, the frame buffer contents get completely garbled up on screen, with colored stripes and unreadable text (photo on request). Only when X11 is started, the screen gets restored again. Closing and re-opening the lid partly cures the mess, too: it makes the font readable, though horizontally stretched. So we think that enabling the plane at this point is masking a bug in our modeset, or that some side-effect of writing those registers or waiting for that vblank has a vital latching or delay that we have not accounted for. Can you please grab intel_reg_dumper from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools and attach its output after passing nomodeset on your kernel boot parameters (without starting X). That should capture the registers as they were left by the BIOS. Alternatively, if you load i915.ko as a module, you can run intel_reg_dumper before loading the module. Then can you attach the output from intel_reg_dumper from the VT before starting X (whilst the display is skewiff) and then after (when the display has recovered). That may help, unless we are right in that it is in the timing of the register writes. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/i915: Select correct pipe during TV detect
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_tv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 6b22c1d..876064c 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1236,6 +1236,8 @@ intel_tv_detect_type (struct intel_tv *intel_tv,
struct drm_connector *connector)
{
struct drm_encoder *encoder = intel_tv-base.base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long irqflags;
@@ -1258,6 +1260,10 @@ intel_tv_detect_type (struct intel_tv *intel_tv,
/* Poll for TV detection */
tv_ctl = ~(TV_ENC_ENABLE | TV_TEST_MODE_MASK);
tv_ctl |= TV_TEST_MODE_MONITOR_DETECT;
+ if (intel_crtc-pipe == 1)
+ tv_ctl |= TV_ENC_PIPEB_SELECT;
+ else
+ tv_ctl = ~TV_ENC_PIPEB_SELECT;
tv_dac = ~(TVDAC_SENSE_MASK | DAC_A_MASK | DAC_B_MASK | DAC_C_MASK);
tv_dac |= (TVDAC_STATE_CHG_EN |
--
1.7.5.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915: TVDAC_STATE_CHG does not indicate successful load-detect
Do not use this bit to indicate that load detection has completed,
instead just wait for vblank, at which point the load registers will
have been updated.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_tv.c | 40 +++---
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 876064c..b371863 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1283,26 +1283,26 @@ intel_tv_detect_type (struct intel_tv *intel_tv,
to_intel_crtc(intel_tv-base.base.crtc)-pipe);
type = -1;
- if (wait_for((tv_dac = I915_READ(TV_DAC)) TVDAC_STATE_CHG, 20) == 0) {
- DRM_DEBUG_KMS(TV detected: %x, %x\n, tv_ctl, tv_dac);
- /*
-* A B C
-* 0 1 1 Composite
-* 1 0 X svideo
-* 0 0 0 Component
-*/
- if ((tv_dac TVDAC_SENSE_MASK) == (TVDAC_B_SENSE |
TVDAC_C_SENSE)) {
- DRM_DEBUG_KMS(Detected Composite TV connection\n);
- type = DRM_MODE_CONNECTOR_Composite;
- } else if ((tv_dac (TVDAC_A_SENSE|TVDAC_B_SENSE)) ==
TVDAC_A_SENSE) {
- DRM_DEBUG_KMS(Detected S-Video TV connection\n);
- type = DRM_MODE_CONNECTOR_SVIDEO;
- } else if ((tv_dac TVDAC_SENSE_MASK) == 0) {
- DRM_DEBUG_KMS(Detected Component TV connection\n);
- type = DRM_MODE_CONNECTOR_Component;
- } else {
- DRM_DEBUG_KMS(Unrecognised TV connection\n);
- }
+ tv_dac = I915_READ(TV_DAC);
+ DRM_DEBUG_KMS(TV detected: %x, %x\n, tv_ctl, tv_dac);
+ /*
+* A B C
+* 0 1 1 Composite
+* 1 0 X svideo
+* 0 0 0 Component
+*/
+ if ((tv_dac TVDAC_SENSE_MASK) == (TVDAC_B_SENSE | TVDAC_C_SENSE)) {
+ DRM_DEBUG_KMS(Detected Composite TV connection\n);
+ type = DRM_MODE_CONNECTOR_Composite;
+ } else if ((tv_dac (TVDAC_A_SENSE|TVDAC_B_SENSE)) == TVDAC_A_SENSE) {
+ DRM_DEBUG_KMS(Detected S-Video TV connection\n);
+ type = DRM_MODE_CONNECTOR_SVIDEO;
+ } else if ((tv_dac TVDAC_SENSE_MASK) == 0) {
+ DRM_DEBUG_KMS(Detected Component TV connection\n);
+ type = DRM_MODE_CONNECTOR_Component;
+ } else {
+ DRM_DEBUG_KMS(Unrecognised TV connection\n);
+ type = -1;
}
I915_WRITE(TV_DAC, save_tv_dac ~TVDAC_STATE_CHG_EN);
--
1.7.5.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: add some evergreen/ni safe regs
need to programmed from the userspace drivers. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/reg_srcs/cayman|1 + drivers/gpu/drm/radeon/reg_srcs/evergreen |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman b/drivers/gpu/drm/radeon/reg_srcs/cayman index 6334f8a..0aa8e85 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/cayman +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman @@ -33,6 +33,7 @@ cayman 0x9400 0x8E48 SQ_EX_ALLOC_TABLE_SLOTS 0x9100 SPI_CONFIG_CNTL 0x913C SPI_CONFIG_CNTL_1 +0x9508 TA_CNTL_AUX 0x9830 DB_DEBUG 0x9834 DB_DEBUG2 0x9838 DB_DEBUG3 diff --git a/drivers/gpu/drm/radeon/reg_srcs/evergreen b/drivers/gpu/drm/radeon/reg_srcs/evergreen index 7e16371..0e28cae 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/evergreen +++ b/drivers/gpu/drm/radeon/reg_srcs/evergreen @@ -46,6 +46,7 @@ evergreen 0x9400 0x8E48 SQ_EX_ALLOC_TABLE_SLOTS 0x9100 SPI_CONFIG_CNTL 0x913C SPI_CONFIG_CNTL_1 +0x9508 TA_CNTL_AUX 0x9700 VC_CNTL 0x9714 VC_ENHANCE 0x9830 DB_DEBUG -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37157] New: [bisected] KDE KWin crashes on start with delayed BO mapping
https://bugs.freedesktop.org/show_bug.cgi?id=37157 Summary: [bisected] KDE KWin crashes on start with delayed BO mapping Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: jlp.b...@gmail.com After updating the mesa today KWin started to crash/segfault on start. I've bisected and the first commmit that causes the crash is: 5e15497452cf3e4d2fc76fdc6ed8113d0891b467 r600g: delay mapping until first map request. (v2) This is with KDE KWin 4.6.3 and on a laptop with integrated ATI Mobility Radeon HD 5470. Later I've also tried with glxgears, which appears to work fine if in window and crashes if started with -fullscreen option. -- 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 37157] [bisected] KDE KWin crashes on start with delayed BO mapping
https://bugs.freedesktop.org/show_bug.cgi?id=37157 --- Comment #1 from Jure Repinc jlp.b...@gmail.com 2011-05-12 18:56:24 PDT --- Created an attachment (id=46654) -- (https://bugs.freedesktop.org/attachment.cgi?id=46654) lspci -- 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 37157] [bisected] KDE KWin crashes on start with delayed BO mapping
https://bugs.freedesktop.org/show_bug.cgi?id=37157 --- Comment #2 from Jure Repinc jlp.b...@gmail.com 2011-05-12 18:57:04 PDT --- Created an attachment (id=46655) -- (https://bugs.freedesktop.org/attachment.cgi?id=46655) Xorg.0.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 37157] [bisected] KDE KWin crashes on start with delayed BO mapping
https://bugs.freedesktop.org/show_bug.cgi?id=37157 --- Comment #4 from Dave Airlie airl...@freedesktop.org 2011-05-12 21:05:51 PDT --- please re-test with master. thanks for the bug report. -- 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
