Bug 23585 - Textures in certain applications are only 1/2 visible on the diagonal in direct mode on r600
Textures in certain applications are only 1/2 visible on the diagonal in dire...
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R100
git
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-28 14:28 UTC by Kevin DeKorte
Modified: 2009-09-04 11:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Image showing the display erorr (4.74 KB, image/png)
2009-08-28 14:28 UTC, Kevin DeKorte
Details
clutter application that shows the problem. (3.96 KB, application/x-gzip)
2009-08-28 14:30 UTC, Kevin DeKorte
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin DeKorte 2009-08-28 14:28:53 UTC
Created attachment 28991 [details]
Image showing the display erorr

I have a clutter application (attached) that when run in direct mode, the texture is only 1/2 visible. This happens on an r635 (r600 mesa driver). I am running git of mesa as of 8/28/09, libdrm and agd5f's radeon kernel modules.

If I run this same app in indirect mode, everything is properly rendered. I see this same issue with the menus in quake3 as well. So it appears to affect multiple apps.

for my app the type of texture is MESA_FORMAT_RGBA8888_REV
Comment 1 Kevin DeKorte 2009-08-28 14:30:40 UTC
Created attachment 28992 [details]
clutter application that shows the problem.

To built this app you need gtk2 and clutter 0.8 development packages installed.

Run make

and then 

./mintest to run the minimal test case 

./clutterdesk to run the full application

use CTRL-C to exit both in the terminal you launched them from.
Comment 2 Alex Deucher 2009-08-31 16:02:07 UTC
Weird.  I built the tests and the icons render fine on my rs780 (I'll test with other chips later).  Richard did some investigating and found:

The glapi level profile for ppracer found lots of following inside:
Begin(GL_QUADS)
Begin(GL_QUADS)
TexCoord2f
TexCoord2f
Vertex2f(3f)
Vertex2f(3f)
TexCoord2f
Vertex2f(3f)
TexCoord2f
Vertex2f(3f)
TexCoord2f
Vertex2f(3f)
End
End 

While in indirect mode,
Begin(GL_QUADS)
TexCoord2f(3f)
Vertex2f
TexCoord2f(3f)
Vertex2f
TexCoord2f(3f)
Vertex2f
TexCoord2f(3f)
Vertex2f
End
 
The first vertex has been duplicated, so last vertex could be dropped.
The weird thing is that r300 runs ok with same glapi level profile showing above.
Comment 3 John Bridgman 2009-09-01 15:25:33 UTC
Not sure if it's the same problem, but mesa/progs/redbook/texsub also shows the same behaviour (works with indirect or software rendering, doesn't work with direct rendering) and may be easier to debug.
Comment 4 Kevin DeKorte 2009-09-02 05:50:27 UTC
I'm not sure the problem with texsub is the same. With that program in both direct and indirect modes it shows me the same image (which is two white squares, one direct on and one at an angle). The software version however has these same squares but with a checkerboard texture (might be a scaling issue like the one in projtex)

So that does not show the 1/2 texture on an angle issue. So I think that is another issue.
Comment 5 Alex Deucher 2009-09-02 08:07:59 UTC
a7f8b329aa75f9a34d31d01b5bf6094b764bd8a9
broke texbind and texsub.  I haven't sorted out the fix yet but it seems unrelated.
Comment 6 Kevin DeKorte 2009-09-02 08:20:40 UTC
(In reply to comment #5)
> a7f8b329aa75f9a34d31d01b5bf6094b764bd8a9
> broke texbind and texsub.  I haven't sorted out the fix yet but it seems
> unrelated.
> 

Alex, suokko and I worked on a fix for this scissor problem that was introduced by this patch. It went into commit..

4f644e58d455cbc70fe856576321f868e36b6346

Without this patch xmoto would not display the buttons on the main screen correctly when running in window mode. Worked fine in fullscreen mode because the drawable offset was 0,0, in a window the patch did not take into account the drawable and cropped them to the wrong places. Also ran piglet tests with this patch in place and all tests passed, prior to this lots of off by failures.
Comment 7 Alex Deucher 2009-09-02 08:33:07 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > a7f8b329aa75f9a34d31d01b5bf6094b764bd8a9
> > broke texbind and texsub.  I haven't sorted out the fix yet but it seems
> > unrelated.
> > 
> 
> Alex, suokko and I worked on a fix for this scissor problem that was introduced
> by this patch. It went into commit..
> 
> 4f644e58d455cbc70fe856576321f868e36b6346

Something still isn't quite right as texbind is still broken in master.  Although perhaps this was just hiding some other issue.
Comment 8 Alex Deucher 2009-09-02 10:59:07 UTC
looks like 4f644e58d455cbc70fe856576321f868e36b6346 was a red herring.  The real problem was: 956e6c3978abe918348377cf05e5c92971e50d3f which makes more sense.
Comment 9 Brian Paul 2009-09-02 14:16:17 UTC
Hmmm, I really don't see how commit 956e6c3978abe918348377cf05e5c92971e50d3f would cause half the quad to disappear in the attached image.  Are you sure that's the commit at fault?
Comment 10 John Bridgman 2009-09-02 14:29:09 UTC
The bug report forked a bit (my fault) - AFAIK the specified commit is the one that breaks redbook/texbind and texsub. I noticed that those tests were failing with direct rendering but failing with indirect rendering and was wondering if they might be a simpler test case for the "half texture" problem. 

Current thinking is that the two bugs are unrelated, so I messed up this bug report for nothing ;)
Comment 11 Alex Deucher 2009-09-02 14:40:34 UTC
(In reply to comment #9)
> Hmmm, I really don't see how commit 956e6c3978abe918348377cf05e5c92971e50d3f
> would cause half the quad to disappear in the attached image.  Are you sure
> that's the commit at fault?
> 

I've opened bug 23657 for the texbind/texsub issue.
Comment 12 Kevin DeKorte 2009-09-02 15:08:15 UTC
Yes, this bug has been present well before that change went into mesa. In fact it has been there pretty much from the beginning as R600 came up.
Comment 13 Alex Deucher 2009-09-04 08:42:07 UTC
This appears to be due to lack of proper support for GL_ARB_vertex_buffer_object in the driver.  Indirect works because the extension is not available in that case.
Comment 14 Michel Dänzer 2009-09-04 08:50:46 UTC
(In reply to comment #13)
> This appears to be due to lack of proper support for
> GL_ARB_vertex_buffer_object in the driver.

Seems to work just fine here with r300. Is there any reason to believe the problem isn't r600 specific?
Comment 15 Alex Deucher 2009-09-04 11:10:12 UTC
fixed in b13a553dd419cc6997725d4bce956daa7eb64806