Bug 62578

Summary: r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
Product: Mesa Reporter: Orion Poplawski <orion>
Component: Drivers/Gallium/r300Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: major    
Priority: medium    
Version: 9.1   
Hardware: x86 (IA32)   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Xorg.0.log

Description Orion Poplawski 2013-03-20 21:12:28 UTC
Created attachment 76846 [details]
Xorg.0.log

Running KDE 4.10.1 on Fedora 18.  After login, screen flickers a bit but nothing is displayed other than the background image.

.xsession-errors contains:
OpenGL vendor string:                   X.Org R300 Project
OpenGL renderer string:                 Gallium 0.4 on ATI RV370
OpenGL version string:                  2.1 Mesa 9.1
OpenGL shading language version string: 1.20
Driver:                                 R300G
GPU class:                              R300
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           9.1
Linux kernel version:                   3.8.3
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           limited
Texture NPOT support:                   limited
Virtual Machine:                        no
r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!

this r300 messages keeps repeating.

kernel 3.8.3-203.fc18.i686.PAE

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]

Just updated from Fedora 16 where this system was working fine.
Comment 1 Orion Poplawski 2013-03-20 21:23:10 UTC
Downgrading from llvm-libs-3.2-2.fc18 and mesa 9.1-1.fc18 to llvm-libs-3.1-11.fc18 and mesa 9.0.1-1.fc18 appears to fix the issue.
Comment 2 Orion Poplawski 2013-03-20 21:49:36 UTC
The problem is also present in mesa 9.0.3.  With that I also get the following in dmesg:

Mar 20 13:51:28 aspen kernel: [162904.454217] [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
Mar 20 13:51:28 aspen kernel: [162904.454224] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

But I don't seem to get that with 9.1.
Comment 3 Marek Olšák 2013-03-21 13:36:01 UTC
What's your screen resolution?
Comment 4 Orion Poplawski 2013-03-21 14:12:25 UTC
[    23.308] (II) RADEON(0): Output VGA-0 using initial mode 1600x1200 +0+0
[    23.308] (II) RADEON(0): Output DVI-0 using initial mode 1600x1200 +1600+0
Comment 5 Orion Poplawski 2013-03-21 14:28:46 UTC
Well, still reproducible with a different user with 9.0.1.
Comment 6 Marek Olšák 2013-03-21 15:10:55 UTC
The issue seems to be that kwin or DDX allocates a texture of the size 2*1600x1200 and your hardware only supports 2560x2560 for rendering and 2048x2048 for texturing. Unfortunately I'm not an expert on X server internals.
Comment 7 Orion Poplawski 2013-03-21 21:15:32 UTC
I filed a bug against kwin.  Looks like they will have checks in place in 4.11 to not use OpenGL on this hardware.  Not sure if anything should still be done on the mesa side or not to help with this.
Comment 8 Alex Deucher 2013-03-21 21:20:51 UTC
(In reply to comment #7)
> I filed a bug against kwin.  Looks like they will have checks in place in
> 4.11 to not use OpenGL on this hardware.  Not sure if anything should still
> be done on the mesa side or not to help with this.

Depending on what features they are using, it should be fine to use GL on this hardware.  They just have to respect the hw limits.
Comment 9 GitLab Migration User 2019-09-18 18:51:57 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/355.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.