Bug 33728 - 5_5_5_1 texture garbled
5_5_5_1 texture garbled
Product: Red Hat Linux
Classification: Retired
Component: Mesa (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-03-28 19:55 EST by Philip Nemec
Modified: 2007-04-18 12:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-28 07:42:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Philip Nemec 2001-03-28 19:55:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-0.1.28 i686)

I've got an OpenGL application that reads tries to make a texture with the
internal format and external format the same (GL_RGB5_A1 and
GL_UNSIGNED_SHORT_5_5_5_1 respectively).  The result is a garbled texture -
it looks like random memory (not just mis-formatted).

Using a non-packed format (like RGBA8) image (converting to RGB5_A1) seems
to work fine.

Reproducible: Always
Steps to Reproduce:
1.  make a solid color texture array (like 0x5959)
2.  make a texture with above params
3.  display it

Actual Results:  As a bonus it sometimes kills X - although I'm guessing
this problem will go away once it is rendered correctly.
Comment 1 Bernhard Rosenkraenzer 2001-05-17 16:44:37 EDT
Which graphics card are you using?
Are you using DRI or software rendering?
Which application is causing this?
Comment 2 Philip Nemec 2001-05-17 20:52:13 EDT
Unfortunately I no longer work for the company where I produced the problem, so
that complicates things a bit.

The corruption was with Mesa on a NeoMagic chipset - software rendering.  The
problem was reproducable with OpenGL calls, so the original application should
not be needed.

A simple test app that creates a 5551 texture (as describe in the original bug
report) and draws a polygon using it should exhibit the problem (although it may
be fixed in newer versions of Mesa/X).
Comment 3 Jim Wray 2001-06-08 15:45:24 EDT
I was unsure whether to classify this a new bug or not... perhaps someone 
could direct me whether or not to do so.

I am an administrator for an educational research lab... we are having similar 
problems with X restarting when running our opengl apps.  We have also been 
successful at almost always getting X to restart when closing down a java3d 
app.  We develop numerous opengl applications, and while they are less 
consistent, one of our developers has an app that restarts X _almost_ every 
time he runs it.  The same behavior does not occur on RedHat 6.2.  It _does_ 
occur on any machines we have tried it on regardless of the hardware.  We even 
have a couple of boxes with NVIDIA cards/drivers on them, and it is 
reproducible.  I have also tried on our Universities open labs with RedHat 7.1 
and reproduced the bug (they have different hardware and monitors settings, 

One thing I tried was upgrading to X 4.1.0 (from rawhide, along with the 
updated Mesa and glibc 2.2.3).  The problem persisted.

Comment 4 Mike A. Harris 2001-08-28 12:53:42 EDT
Without an attached small standalone test case, I cannot do very
much about this.  If you attach a small application source that
is just enough code to trigger the bug, then it can be looked into
more easily.  If you do so, please REOPEN the bug report,
otherwise, please report the bug upstream to the Mesa development
team on http://mesa3d.sourceforge.net

Note You need to log in before you can comment on or make changes to this bug.