Subject: Bug#628680: sludge-engine: Nothing is displayed (black screen) with antialias=1

From: Rogier <[email-masked]>
Date: Tue, 31 May 2011 11:49:38 +0200

Package: sludge-engine
Version: 2.1.1-1
Severity: normal

When starting a game (e.g. out-of-order) with antialias set to 1,
nothing is displayed (i.e. just a black screen / window).
There is also a message about an unknown opcode 'DDY' while
compiling.

With antialias=0 or antialias=-1, the two  games I tried seemed OK
(i.e. the intro / initial screen displays fine).

I'm attaching a debug log of out-of-order.

Regards,

Rogier.

-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sludge-engine depends on:
ii  libalure1                   1.1-2        AL Utilities REtooled (shared libr
ii  libc6                       2.13-4       Embedded GNU C Library: Shared lib
ii  libgcc1                     1:4.6.0-2    GCC support library
ii  libgl1-mesa-glx [libgl1]    7.10.2-2     free implementation of the OpenGL 
ii  libglee0d1                  5.4.0-1      extension loading library for Open
ii  libglu1-mesa [libglu1]      7.10.2-2     The OpenGL utility library (GLU)
ii  libogg0                     1.2.2~dfsg-1 Ogg bitstream library
ii  libopenal1                  1:1.13-2     Software implementation of the Ope
ii  libpng12-0                  1.2.44-2     PNG library - runtime
ii  libsdl1.2debian             1.2.14-6.3   Simple DirectMedia Layer
ii  libstdc++6                  4.6.0-2      The GNU Standard C++ Library v3
ii  libvorbis0a                 1.3.2-1      The Vorbis General Audio Compressi
ii  libvpx0                     0.9.6-1      VP8 video codec (shared library)

sludge-engine recommends no packages.

Versions of packages sludge-engine suggests:
pn  sludge-devkit                 <none>     (no description available)

-- no debconf information

---

From: Tobias Hansen <[email-masked]>
Date: Tue, 31 May 2011 19:58:40 +0200

Am 31.05.2011 11:49, schrieb Rogier:
> Unknown opcode DDY
Looks like this one: 
http://lists.freedesktop.org/archives/dri-devel/2010-August/002805.html
There the answer is that the hardware doesn't support something. What 
graphics card do you have? Is everything displayed correctly when 
disabling antialiasing? The log you posted was with antialiasing 
disabled, would you send one with enabled antialiasing?

Best regards,
Tobias Hansen

---

From: Rogier <[email-masked]>
Date: Wed, 1 Jun 2011 10:00:50 +0200

Hi Tobias,

Thanks for your reply.

> http://lists.freedesktop.org/archives/dri-devel/2010-August/002805.html
It seems like it.

> There the answer is that the hardware doesn't support something.
Wouldn't that be 'mesa doesn't support something' ? (something that would be 
in hardware, if only I had a better graphics card ?)

In that case, I would expect either mesa to return a failure somewhere, and 
then sludge to fail or maybe even to take corrective action (if possible at 
all), or mesa (knowing it can't support DDY) to do something that at least 
preserves the output.

> What graphics card do you have?
ATI Technologies Inc RS690M [Radeon X1200 Series]

> Is everything displayed correctly when disabling antialiasing?
Yes.
And it is also when using linear interpolation (-a-1).
Just using antialiasing (-a1) it doesn't work.

> The log you posted was with antialiasing
> disabled, would you send one with enabled antialiasing
Hmmm...
The command-line has a '-a 0' indeed, but the log _does_ include the 'DDY' 
message, as well as 'Built shader program: 3 (smartScaler)', which puzzles me, 
as they are unique to antialiasing...
I suspect, I made a typo while sanitizing the /usr/bin/script log file.

I created a new log with antialiasing, and except for the first line, it is 
identical to the one I included in the report. It seems redundant to include 
it here ...

Regards,

Rogier.

---

From: Tobias Hansen <[email-masked]>
Date: Wed, 01 Jun 2011 19:12:19 +0200

> all), or mesa (knowing it can't support DDY) to do something that at least
I asked the other developer (the one who wrote the OpenGL code) and he 
says the driver reports success wrongly so we can't do anything about it:

http://www.adventuredevelopers.com/forum/index.php?topic=3507.0
> ATI Technologies Inc RS690M [Radeon X1200 Series]
Aren't there multiple drivers for ATI cards? Could you try another one?

Regards, Tobias

---

From: Rogier <[email-masked]>
Date: Fri, 3 Jun 2011 09:22:59 +0200

Hi Tobias,

On 2011-06-01 08:33, Tobias Hansen <[email-masked]> wrote:
> > In that case, I would expect either mesa to return a failure somewhere,
> > and then sludge to fail or maybe even to take corrective action (if
> > possible at all), or mesa (knowing it can't support DDY) to do something
> > that at least preserves the output.
> 
OK.

> Aren't there multiple drivers for ATI cards? Could you try another one?
Personally, I'll do without AA, and assume it will get fixed in Mesa, somwehere 
in the future.
However, if it is useful to you in any way, I'll gladly try another driver and 
report the results.

Rogier.

---

From: Tobias Hansen <[email-masked]>
Date: Sat, 04 Jun 2011 00:20:37 +0200

> However, if it is useful to you in any way, I'll gladly try another driver and

Would be interesting, but it's not important.

---

From: Tobias Hansen <[email-masked]>
Date: Mon, 06 Jun 2011 09:56:44 +0200

Seems like you just have to install the package libgl1-mesa-dri when 
using the mesa driver.

See http://bugs.debian.org/628808

---

From: Rogier <[email-masked]>
Date: Sat, 11 Jun 2011 18:08:57 +0200

Hi Tobias,

> See http://bugs.debian.org/628808

I have been away, and I still need to check bug 628808, but liblg1-mesa-dri 
was/is already installed on my system.

Rogier.

---

From: Tobias Hansen <[email-masked]>
Date: Mon, 01 Aug 2011 01:40:32 +0200

I'm attaching another mail from Rogier. (Please keep attaching to the 
bug report.):

Am 30.07.2011 17:52, schrieb Rogier:
> Hi Tobias,
>
>> Actually it would be quite good to know, because then we could reassign
>> the bug to the driver package. Which driver are you using now?
> I've been away a few weeks, and busy with other things, but I finally got
> around to trying out-of-order with other drivers.
>
> The driver I am using is the xorg radeon driver.
> I don't know if it's relevant, but fglxrinfo prints the following:
>      display: :0  screen: 0
>      OpenGL vendor string: X.Org R300 Project
>      OpenGL renderer string: Gallium 0.4 on ATI RS690
>      OpenGL version string: 2.1 Mesa 7.10.3
>
> The radeonhd driver is not available on my system (debian testing)
>
> I tested with the fbdev driver, and it works fine with and without AA, except
> that sludge-engine consumes>  80% CPU, and the game is extremely slow.
> fglrxinfo output:
>      display: :1  screen: 0
>      OpenGL vendor string: Mesa Project
>      OpenGL renderer string: Software Rasterizer
>      OpenGL version string: 2.1 Mesa 7.10.3
>
> I tried to install the fglrx driver, but apparently my card is not supported.
>
> If you need more information, let me know.
>
> Kind regards,
>
> Rogier

Hi Rogier,

thanks for having another look at this. I have searched the web a bit on 
how well the RS690 is supported by the drivers and found out that it 
seems to belong to the latest graphics cards without support for vertex 
shaders that were sold. sludge-engine uses shaders, so any way you can 
make it work involves shader code being processed on the cpu and thus 
slowness.

Here is the table stating that the ship doesn't support shaders:
http://xorg.freedesktop.org/wiki/RadeonFeature

Best regards,
Tobias