mesa3d-dev

[Mesa3d-dev] [Bug 27469] New: Mesa 7.8: Problems with two games, using OpenGL

[<bug...@fr...>]

https://bugs.freedesktop.org/show_bug.cgi?id=27469

           Summary: Mesa 7.8: Problems with two games, using OpenGL
           Product: Mesa
           Version: unspecified
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: zb...@ja...


Cannot describe this so precisely, as in my earlier reports - but maybe it can
be of some use to improve Mesa3D library:

I noticed problems with two games:

1. "Polynomial" (demo for Linux) http://dmytry.pandromeda.com/games/

After start (no graphics shown), there is crash. The last lines of its messages
are:

(3169) last ShapeMaker::Update()
(545) TestTextureFrameBuffer::TestTextureFrameBuffer
glGenTextures: success
glBindTexture: success
[ 0]:glTexImage2D: error invalid value
[ 0]:glTexImage2D, second try at low quality: error invalid value
destroying framebuffer and associated texture: success
(1092) Drawer3D::DrawInternal fail 1
GLMTexture::LoadFromFile($$data/nebulabrot_composite_final_8.png)
Shader '$$data/background_v.glsl' compiled successfully
Shader '$$data/background_f.glsl' compiled successfully
Program linked successfully.
Shader '$$data/test_v.glsl' compiled successfully
Shader '$$data/test_f.glsl' compiled successfully
Program linked successfully.
Backtrace:
./bin/Polynomial32 [0x80d44f3]
[0xffffe400]
/System/Links/Libraries/xorg/modules/dri/r200_dri.so [0xb6632450]
/System/Links/Libraries/xorg/modules/dri/r200_dri.so [0xb6632e89]
/System/Links/Libraries/xorg/modules/dri/r200_dri.so [0xb67101c5]
/System/Links/Libraries/xorg/modules/dri/r200_dri.so [0xb6710584]
/System/Links/Libraries/xorg/modules/dri/r200_dri.so [0xb670f211]
/System/Links/Libraries/xorg/modules/dri/r200_dri.so [0xb6632ba9]
/System/Links/Libraries/xorg/modules/dri/r200_dri.so [0xb6632e89]
/System/Links/Libraries/xorg/modules/dri/r200_dri.so [0xb662a4c1]
/System/Links/Libraries/xorg/modules/dri/r200_dri.so [0xb6620bc7]
./bin/Polynomial32 [0x813ad97]
./bin/Polynomial32 [0x8146ca0]
./bin/Polynomial32 [0x8146e01]
./bin/Polynomial32 [0x80875eb]
./bin/Polynomial32 [0x8089e3f]
./bin/Polynomial32 [0x808b3d0]
./bin/Polynomial32 [0x807eb81]
./bin/Polynomial32 [0x81a27ce]
./bin/Polynomial32 [0x81a52c5]
./bin/Polynomial32 [0x81a2e30]
./bin/Polynomial32 [0x819ad31]
./bin/Polynomial32 [0x8194f08]
./bin/Polynomial32 [0x8199cbe]
./bin/Polynomial32 [0x8197752]
./bin/Polynomial32 [0x80dbce9]
/System/Links/Libraries/libc.so.6(__libc_start_main+0xe6) [0xb6a49416]
./bin/Polynomial32 [0x80511b1]
./Polynomial32: line 2:  5646 Unicestwiony           
+LD_LIBRARY_PATH=./bin/lib32 ./bin/Polynomial32

I contacted the author, and he answered:

"Unfortunately I think it cannot be played on mesa dri drivers - those are beta
and it is very difficult to make opensource drivers for graphics hardware, even
with some hardware documentation available. Judging by stacktrace, the crash
happens outside my code, very little I can do."

2. CG Madness 1.2.2    http://cgmadness.sourceforge.net/

Compiled with just "make" it seems to be built properly, but right after start
(no graphics shown) it freezes the system for good (even "Magic SysReq" doesn't
work). On my hardware it's complaining (right before the lock-up) about lack of
"framebuffer", and that there's no "OpenGL 2.0 shader" - but I'm not sure, is
it related to following crash; in my opinion it should run with somewhat poorer
look.

AFAIR (but I'm not 100% sure) I was playing the game without problems when I
was using Mesa 7.5.1.


Like before: both games tested using Kernel 2.6.32.10, Glibc 2.10.1, Gobolinux
0.14 (32-bit), Mesa 7.8, Xorg 7.5, X-Server 1.7.6, IceWM 1.2.37, Pentium
III/750, old mobo Intel BX-based, ATI Technologies Inc RV280 [Radeon 9200 PRO]

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27464] Mesa 7.8: screen/keyboard frozen when using menus in GLUT application

[<bug...@fr...>]

https://bugs.freedesktop.org/show_bug.cgi?id=27464

--- Comment #1 from Zbigniew <zb...@ja...> 2010-04-05 05:47:15 PDT ---
Tested using Kernel 2.6.32.10, Glibc 2.10.1, Gobolinux 0.14 (32-bit), Mesa  
7.8, Xorg 7.5, X-Server 1.7.6, IceWM 1.2.37, Pentium III/750, old mobo Intel 
BX-based, ATI Technologies Inc RV280 [Radeon 9200 PRO]

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27464] New: Mesa 7.8: screen/keyboard frozen when using menus in GLUT application

[<bug...@fr...>]

https://bugs.freedesktop.org/show_bug.cgi?id=27464

           Summary: Mesa 7.8: screen/keyboard frozen when using menus in
                    GLUT application
           Product: Mesa
           Version: unspecified
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: GLUT
        AssignedTo: mes...@li...
        ReportedBy: zb...@ja...


Created an attachment (id=34670)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=34670)
Mesa 7.8: screen/keyboard frozen when using menus in GLUT application

The problem a bit similar to that formerly reported (Bug 27461) - use attached
code, that I've found in GLUT tutorial. After compilation it can be started
quite normally, so choose the corpse to draw (second menu point). After it'll
appear in the window, now (important!) having pressed right mouse button
traverse all three menu points "top-to-bottom" to highlight them all
one-by-one. After the last menu point ("Quit") will be highlighted and left by
mouse cursor, the corpse disappears, and the screen and keyboard will be
locked.

It's not my code, so I'm not sure about ev. errors in coding - but it's very
short, so it's easy to examine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27461] New: Mesa 7.8: Screen lock-ups, when drawing 3D built-in figures (probably GLUT?)

[<bug...@fr...>]

https://bugs.freedesktop.org/show_bug.cgi?id=27461

           Summary: Mesa 7.8: Screen lock-ups, when drawing 3D built-in
                    figures (probably GLUT?)
           Product: Mesa
           Version: unspecified
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: GLUT
        AssignedTo: mes...@li...
        ReportedBy: zb...@ja...


Created an attachment (id=34669)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=34669)
Code mentioned in bug-report

Noticed lock-ups (screen, keyboard "frozen") when using newest Mesa3D 7.8.
Fortunately, it's easy to repeat, using attached code. The problem appears,
when user wants to interact with his window manager's widgets, for example: if
there's a need to start another application using WM's menu, while having
window of application (the one utilizing Mesa/GLUT) still open.

How to repeat:

1. If you just compile the attached code, it'll work quite normally, and you
won't notice any problems.

2. The important thing is in the renderScene function: now try to remove all
the lines starting from glBegin, and ending on glEnd, then uncomment any of two
commented out lines: either glutWireIcosahedron, or glutWireCube.

3. After new compilation, the application will start and behave normally. But
now it's enough to click WM's "Menu" button - or workspace switching buttons on
taskbar - and the screen will be "frozen" completely, keyboard unusable
(fortunately, sometimes "Magis SysReq" still works), and the only way out is
reset.

Using the code you can check two more things, that I'm not sure about its
nature ("bug or feature?"):

4. If you choose glutWireTeapot as the corpse for displaying - instead of cube
or icosahedron - you'll notice from the very start heavy CPU load.

5. If you won't register glutTimerFunc function - and you'll choose to trigger
glutPostRedisplay() by placing it within any idle function, registered then
using glutIdleFunc - you'll notice lockup from the very start (being
GLUT-newbie I'm not sure, is it OK, maybe it's not good practice? But
redisplaying in the idle time shouldn't lock the WM completely, right?).

Tested using Kernel 2.6.32.10, Glibc 2.10.1, Gobolinux 0.14 (32-bit), Mesa 7.8,
Xorg 7.5, X-Server 1.7.6, IceWM 1.2.37, Pentium III/750, old mobo Intel
BX-based, ATI Technologies Inc RV280 [Radeon 9200 PRO]

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Dave A. <ai...@gm...>]

On Mon, Apr 5, 2010 at 6:06 PM, Chia-I Wu <ol...@gm...> wrote:
> On Mon, Apr 5, 2010 at 3:38 PM, Dave Airlie <ai...@gm...> wrote:
>> On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu <ol...@gm...> wrote:
>>> On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie <ai...@gm...> wrote:
>>>> On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu <ol...@gm...> wrote:
>>>>> On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie <ai...@gm...> wrote:
>>>>>>> The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
>>>>>>> passes the test with the patch?
>>>>>>> The teximage callback has an internal_format parameter that specifies how the
>>>>>>> pipe texture should be treated.  It can differ from the format of the texture.
>>>>>>> It seems to suffice for TFP.  I was lazy enough not to use it :(
>>>>>> That was my first attempt also, however it fails as the texture is
>>>>>> already created, and
>>>>>> in r300g we already have worked out the hw state assuming the texture
>>>>>> format won't
>>>>>> change. This seems to be what gallium expects. So in this case you end
>>>>>> up recreating
>>>>>> a new texture at finalise because the formats don't match and you lose
>>>>>> the pixmap.
>>>>> r300g does not see the texture before st_finalize_texture, right?  It seems to
>>>>> me that the patch should give the correct behavior but a (really bad)
>>>>> unnecessary texture copy in st_finalize_texture.  Could we avoid the copy by
>>>>> solely changing the sampler view?
>>>> It sees the texture via
>>>> dri_st_framebuffer_validate_att(drawable->stfb,
>>>> ST_ATTACHMENT_FRONT_LEFT)
>>>> which causes the texture to be creates from the dri2 buffer handle,
>>>> The thing is we need the exact buffer object we get from the X server,
>>>> we can't copy it to another texture later, as it destroys the shared texture
>>>> and just seems to create another private one.
>>> Suppose a PIPE_FORMAT_B8G8R8A8_UNORM GLXPixmap is created both for rendering,
>>> and t-f-p texturing with GLX_TEXTURE_FORMAT_RGB_EXT.  The front left buffer of
>>> the pixmap should be a single PIPE_FORMAT_B8G8R8A8_UNORM pipe_texture.  When
>>> glXBindTexImageEXT is called, st/mesa should "view" the pipe_texture as if
>>> there is no alpha channel.  It is hacky for st/dri to create another
>>> pipe_texture from the same dri2 buffer handle with a different format and pass
>>> the new pipe_texture to st/mesa.
>>>
>>> To achieve the "viewing" thing efficiently, st/mesa should create a
>>> PIPE_FORMAT_B8G8R8X8_UNORM sampler view for the pipe_texture (I suppose this is
>>> what a sampler view for?  No?).  This is contrary to performing an implicit
>>> copy on the pipe_texture only to ignore the alpha channel, which is what
>>> st_finalize_texture does.  IIRC, tfp allows an implementation to perform an
>>> implicit copy upon binding.  Both behaviors are correct in this sense, but the
>>> latter is obviously undesirable.
>>>
>>
>> Yes a sampler view seems the sanest. The latter behaviour might be
>> correct but doesn't
>> work here, at least with the equiv patch I tried originally the test
>> still failed, so it would be
>> correct if it worked though slower.
> The patch I sent earlier works here with i915g.  I am not sure where it goes
> wrong with r300g.  Do you mind have a look into it?

Yeah I suspect we have an issue in r300g alright, we use a stride override
when we get the texture from TFP, and this might not be propogated properly
when we copy it later.

Dave.

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Chia-I Wu <ol...@gm...>]

On Mon, Apr 5, 2010 at 3:38 PM, Dave Airlie <ai...@gm...> wrote:
> On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu <ol...@gm...> wrote:
>> On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie <ai...@gm...> wrote:
>>> On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu <ol...@gm...> wrote:
>>>> On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie <ai...@gm...> wrote:
>>>>>> The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
>>>>>> passes the test with the patch?
>>>>>> The teximage callback has an internal_format parameter that specifies how the
>>>>>> pipe texture should be treated.  It can differ from the format of the texture.
>>>>>> It seems to suffice for TFP.  I was lazy enough not to use it :(
>>>>> That was my first attempt also, however it fails as the texture is
>>>>> already created, and
>>>>> in r300g we already have worked out the hw state assuming the texture
>>>>> format won't
>>>>> change. This seems to be what gallium expects. So in this case you end
>>>>> up recreating
>>>>> a new texture at finalise because the formats don't match and you lose
>>>>> the pixmap.
>>>> r300g does not see the texture before st_finalize_texture, right?  It seems to
>>>> me that the patch should give the correct behavior but a (really bad)
>>>> unnecessary texture copy in st_finalize_texture.  Could we avoid the copy by
>>>> solely changing the sampler view?
>>> It sees the texture via
>>> dri_st_framebuffer_validate_att(drawable->stfb,
>>> ST_ATTACHMENT_FRONT_LEFT)
>>> which causes the texture to be creates from the dri2 buffer handle,
>>> The thing is we need the exact buffer object we get from the X server,
>>> we can't copy it to another texture later, as it destroys the shared texture
>>> and just seems to create another private one.
>> Suppose a PIPE_FORMAT_B8G8R8A8_UNORM GLXPixmap is created both for rendering,
>> and t-f-p texturing with GLX_TEXTURE_FORMAT_RGB_EXT.  The front left buffer of
>> the pixmap should be a single PIPE_FORMAT_B8G8R8A8_UNORM pipe_texture.  When
>> glXBindTexImageEXT is called, st/mesa should "view" the pipe_texture as if
>> there is no alpha channel.  It is hacky for st/dri to create another
>> pipe_texture from the same dri2 buffer handle with a different format and pass
>> the new pipe_texture to st/mesa.
>>
>> To achieve the "viewing" thing efficiently, st/mesa should create a
>> PIPE_FORMAT_B8G8R8X8_UNORM sampler view for the pipe_texture (I suppose this is
>> what a sampler view for?  No?).  This is contrary to performing an implicit
>> copy on the pipe_texture only to ignore the alpha channel, which is what
>> st_finalize_texture does.  IIRC, tfp allows an implementation to perform an
>> implicit copy upon binding.  Both behaviors are correct in this sense, but the
>> latter is obviously undesirable.
>>
>
> Yes a sampler view seems the sanest. The latter behaviour might be
> correct but doesn't
> work here, at least with the equiv patch I tried originally the test
> still failed, so it would be
> correct if it worked though slower.
The patch I sent earlier works here with i915g.  I am not sure where it goes
wrong with r300g.  Do you mind have a look into it?

-- 
ol...@Lu...

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Dave A. <ai...@gm...>]

On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu <ol...@gm...> wrote:
> On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie <ai...@gm...> wrote:
>> On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu <ol...@gm...> wrote:
>>> On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie <ai...@gm...> wrote:
>>>>> The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
>>>>> passes the test with the patch?
>>>>> The teximage callback has an internal_format parameter that specifies how the
>>>>> pipe texture should be treated.  It can differ from the format of the texture.
>>>>> It seems to suffice for TFP.  I was lazy enough not to use it :(
>>>> That was my first attempt also, however it fails as the texture is
>>>> already created, and
>>>> in r300g we already have worked out the hw state assuming the texture
>>>> format won't
>>>> change. This seems to be what gallium expects. So in this case you end
>>>> up recreating
>>>> a new texture at finalise because the formats don't match and you lose
>>>> the pixmap.
>>> r300g does not see the texture before st_finalize_texture, right?  It seems to
>>> me that the patch should give the correct behavior but a (really bad)
>>> unnecessary texture copy in st_finalize_texture.  Could we avoid the copy by
>>> solely changing the sampler view?
>> It sees the texture via
>> dri_st_framebuffer_validate_att(drawable->stfb,
>> ST_ATTACHMENT_FRONT_LEFT)
>> which causes the texture to be creates from the dri2 buffer handle,
>> The thing is we need the exact buffer object we get from the X server,
>> we can't copy it to another texture later, as it destroys the shared texture
>> and just seems to create another private one.
> Suppose a PIPE_FORMAT_B8G8R8A8_UNORM GLXPixmap is created both for rendering,
> and t-f-p texturing with GLX_TEXTURE_FORMAT_RGB_EXT.  The front left buffer of
> the pixmap should be a single PIPE_FORMAT_B8G8R8A8_UNORM pipe_texture.  When
> glXBindTexImageEXT is called, st/mesa should "view" the pipe_texture as if
> there is no alpha channel.  It is hacky for st/dri to create another
> pipe_texture from the same dri2 buffer handle with a different format and pass
> the new pipe_texture to st/mesa.
>
> To achieve the "viewing" thing efficiently, st/mesa should create a
> PIPE_FORMAT_B8G8R8X8_UNORM sampler view for the pipe_texture (I suppose this is
> what a sampler view for?  No?).  This is contrary to performing an implicit
> copy on the pipe_texture only to ignore the alpha channel, which is what
> st_finalize_texture does.  IIRC, tfp allows an implementation to perform an
> implicit copy upon binding.  Both behaviors are correct in this sense, but the
> latter is obviously undesirable.
>

Yes a sampler view seems the sanest. The latter behaviour might be
correct but doesn't
work here, at least with the equiv patch I tried originally the test
still failed, so it would be
correct if it worked though slower.

Dave.

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Chia-I Wu <ol...@gm...>]

On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie <ai...@gm...> wrote:
> On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu <ol...@gm...> wrote:
>> On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie <ai...@gm...> wrote:
>>>> The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
>>>> passes the test with the patch?
>>>> The teximage callback has an internal_format parameter that specifies how the
>>>> pipe texture should be treated.  It can differ from the format of the texture.
>>>> It seems to suffice for TFP.  I was lazy enough not to use it :(
>>> That was my first attempt also, however it fails as the texture is
>>> already created, and
>>> in r300g we already have worked out the hw state assuming the texture
>>> format won't
>>> change. This seems to be what gallium expects. So in this case you end
>>> up recreating
>>> a new texture at finalise because the formats don't match and you lose
>>> the pixmap.
>> r300g does not see the texture before st_finalize_texture, right?  It seems to
>> me that the patch should give the correct behavior but a (really bad)
>> unnecessary texture copy in st_finalize_texture.  Could we avoid the copy by
>> solely changing the sampler view?
> It sees the texture via
> dri_st_framebuffer_validate_att(drawable->stfb,
> ST_ATTACHMENT_FRONT_LEFT)
> which causes the texture to be creates from the dri2 buffer handle,
> The thing is we need the exact buffer object we get from the X server,
> we can't copy it to another texture later, as it destroys the shared texture
> and just seems to create another private one.
Suppose a PIPE_FORMAT_B8G8R8A8_UNORM GLXPixmap is created both for rendering,
and t-f-p texturing with GLX_TEXTURE_FORMAT_RGB_EXT.  The front left buffer of
the pixmap should be a single PIPE_FORMAT_B8G8R8A8_UNORM pipe_texture.  When
glXBindTexImageEXT is called, st/mesa should "view" the pipe_texture as if
there is no alpha channel.  It is hacky for st/dri to create another
pipe_texture from the same dri2 buffer handle with a different format and pass
the new pipe_texture to st/mesa.

To achieve the "viewing" thing efficiently, st/mesa should create a
PIPE_FORMAT_B8G8R8X8_UNORM sampler view for the pipe_texture (I suppose this is
what a sampler view for?  No?).  This is contrary to performing an implicit
copy on the pipe_texture only to ignore the alpha channel, which is what
st_finalize_texture does.  IIRC, tfp allows an implementation to perform an
implicit copy upon binding.  Both behaviors are correct in this sense, but the
latter is obviously undesirable.

-- 
ol...@Lu...

[Mesa3d-dev] RFC: GSOC Proposal: R300 GLSL Compiler - 2nd Draft

[Tom S. <tst...@gm...>]

Thanks to everyone who gave me feedback on my proposal.  I have made
some modifications to my proposal based on some of the suggestions I
received.  The main change to my proposal is that I am going to focus
on doing the branch emulation and loop unrolling in the r300 compiler
instead of doing it with TGSI.  I left some time at the end of the
project to explore doing a TGSI -> RC -> RC Branch Emulation -> TGSI
translation to expose the branch emulation done in the r300 compiler to
the rest of the Gallium drivers.  I also modified some of the time
estimates based on suggestions from Nicolai.  The full proposal is here:
http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/tstellar/t126997450856
The project plan is reproduced below:

Tasks:

1. Improve branch emulation in the r300 compiler:
The goal of this task will be to improve upon the work done by
Nicolai Häehnle in this branch:
http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glsl and fully support
branch emulation in the r300 compiler.  This first part of this task
will involve testing the current branch emulation code to determine what
works and what does not.  After this has been completed work can begin
on any part of the branch emulation that does not work correctly.

2. Unroll loops in the r300 compiler:
The goal of this task will be to unroll loops so that they can be executed
by hardware that does not support them.  The loop unrolling in this task
is not meant as a code optimization.  It is only being done to eliminate
branch instructions.  Loops where the number of iterations are known
at compile time will be unrolled and may have additional optimizations
applied.  Loops that have an unknown number of iterations, will have to
be studied to see if there is a way to replace the loop with a set of
instructions that produces the same output as the loop.  For example,
one solution might be to replace an ADD(src0, src0) instruction that
is supposed to execute n times with a MUL(src0, n). It is possible that
not all loops will be able to be unrolled successfully.

3. Loops and Conditionals for R500 fragment and vertex shaders: The
goal of this task will be to make use of the R500 hardware support for
branches and loops.  New radeon_compiler opcodes (RC_OPCODE_*) will need
to be added to represent loops, and the corresponding TGSI instructions
will need to be converted into these new opcodes during the TGSI_OPCODE_*
to RC_OPCODE_* phase.  Once this has been done, the code generator for
R500 vertex and fragment shaders will need to be modified to output the
correct hardware instructions for loops.

4. Optional Tasks:
Here is a list of things that could be explored if there is some extra
time left at the end of the project.

a) Using r300 compiler for branch emulation/loop unrolling in Gallium drivers:
The goal of this task would be to apply branch emulation and loop
unrolling to TGSI code.  This would be accomplished by creating a Gallium
util function that takes TGSI code, converts it to the r300 compiler
intermediate language(RC) and then uses the r300 compiler to do the
branch emulation and loop unrolling.  The RC would then be converted
back into TGSI and passed back to the driver calling the function.

b)More optimizations:
Revisit the work from previous tasks and explore doing some optimizations
that may have been outside the scope of the original task.

c) Other GLSL features for the r300 compiler:
	i)Adding support for the gl_FrontFacing variable.
	ii)Handling varying modifiers like perspective, flat, and centroid.

d)Improving the GLSL frontend to add support for more language features.

Schedule / Deliverables:
1. Improve branch emulation in the r300 compiler (2 - 3 weeks)
2. Unroll loops in the r300 compiler (4 weeks)
Midterm Evaluation
3. Loops and Conditionals for R500 fragment and vertex shaders (4 weeks)
4. Optional Tasks (2 weeks)

Tasks 1-3 will be required for this project.
Task 4 is optional.

Thanks.

-Tom

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Dave A. <ai...@gm...>]

On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu <ol...@gm...> wrote:
> On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie <ai...@gm...> wrote:
>>> The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
>>> passes the test with the patch?
>>> The teximage callback has an internal_format parameter that specifies how the
>>> pipe texture should be treated.  It can differ from the format of the texture.
>>> It seems to suffice for TFP.  I was lazy enough not to use it :(
>> That was my first attempt also, however it fails as the texture is
>> already created, and
>> in r300g we already have worked out the hw state assuming the texture
>> format won't
>> change. This seems to be what gallium expects. So in this case you end
>> up recreating
>> a new texture at finalise because the formats don't match and you lose
>> the pixmap.
> r300g does not see the texture before st_finalize_texture, right?  It seems to
> me that the patch should give the correct behavior but a (really bad)
> unnecessary texture copy in st_finalize_texture.  Could we avoid the copy by
> solely changing the sampler view?

It sees the texture via
dri_st_framebuffer_validate_att(drawable->stfb,
ST_ATTACHMENT_FRONT_LEFT)
which causes the texture to be creates from the dri2 buffer handle,

The thing is we need the exact buffer object we get from the X server,
we can't copy it to another texture later, as it destroys the shared texture
and just seems to create another private one.

Dave.

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Chia-I Wu <ol...@gm...>]

On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie <ai...@gm...> wrote:
>> The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
>> passes the test with the patch?
>> The teximage callback has an internal_format parameter that specifies how the
>> pipe texture should be treated.  It can differ from the format of the texture.
>> It seems to suffice for TFP.  I was lazy enough not to use it :(
> That was my first attempt also, however it fails as the texture is
> already created, and
> in r300g we already have worked out the hw state assuming the texture
> format won't
> change. This seems to be what gallium expects. So in this case you end
> up recreating
> a new texture at finalise because the formats don't match and you lose
> the pixmap.
r300g does not see the texture before st_finalize_texture, right?  It seems to
me that the patch should give the correct behavior but a (really bad)
unnecessary texture copy in st_finalize_texture.  Could we avoid the copy by
solely changing the sampler view?

-- 
ol...@Lu...

Re: [Mesa3d-dev] ARB draw buffers + texenv program

[Chia-I Wu <ol...@gm...>]

On Sat, Apr 03, 2010 at 01:43:04PM +1000, Dave Airlie wrote:
> Just going down the r300g piglit failures and noticed fbo-drawbuffers
> failed, I've no idea
> if this passes on Intel hw, but it appears the texenvprogram really
> needs to understand the
> draw buffers. The attached patch fixes it here for me on r300g anyone
> want to test this on Intel
> with the piglit test before/after?
i915g has MaxDrawBuffers == 1 and the test is skipped.

-- 
ol...@Lu...

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Dave A. <ai...@gm...>]

On Mon, Apr 5, 2010 at 12:49 PM, Chia-I Wu <ol...@gm...> wrote:
> On Sun, Apr 4, 2010 at 6:31 PM, Dave Airlie <ai...@gm...> wrote:
>> Hey,
>>
>> So I was trying to fix tfp test on r300g, and ran into an issue with
>> dri st I think.
>>
>> So the way TFP works we get dri2_set_tex_buffer, which then validates the
>> attachment, but ignores the format passed in. So r300g picks up the kernel
>> buffer from the handle and sets up the texture + texture state without
>> the format
>> information.
>>
>> Once we've validated, we call ctx->st->teximage and can give it a different
>> format however at no point does r300g get any place to change the texture format
>> and update its internal state.
>>
>> I'm not sure if either r300g should delay setting up its internal
>> state for emission
>> until later or whether we need to enhance the st interface.
>>
>> The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8
>> which triggers this.
> The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
> passes the test with the patch?
>
> The teximage callback has an internal_format parameter that specifies how the
> pipe texture should be treated.  It can differ from the format of the texture.
> It seems to suffice for TFP.  I was lazy enough not to use it :(
>

That was my first attempt also, however it fails as the texture is
already created, and
in r300g we already have worked out the hw state assuming the texture
format won't
change. This seems to be what gallium expects. So in this case you end
up recreating
a new texture at finalise because the formats don't match and you lose
the pixmap.

Dave.

Re: [Mesa3d-dev] segfault in readpix demo with GL_OES_read_format on r300g

[Chia-I Wu <ol...@gm...>]

On Mon, Apr 5, 2010 at 7:42 AM, Dave Airlie <ai...@gm...> wrote:
> Starting program: /home/airlied/mesa/progs/demos/readpix
> [Thread debugging using libthread_db enabled]
> GL_VERSION = 2.1 Mesa 7.9-devel
> GL_RENDERER = Gallium 0.4 on RV530
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38)
>    at main/framebuffer.c:1021
> 1021    }
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-8.fc12.i686 libICE-1.0.6-1.fc12.i686
> libSM-1.1.0-7.fc12.i686 libX11-1.3-1.fc12.i686
> libXdamage-1.1.2-1.fc12.i686 libXext-1.1-2.fc12.i686
> libXfixes-4.0.4-1.fc12.i686 libXi-1.3-2.fc12.i686
> libXmu-1.0.5-1.fc12.i686 libXt-1.0.7-1.fc12.i686
> libXxf86vm-1.1.0-1.fc12.i686 libgcc-4.4.3-4.fc12.i686
> libstdc++-4.4.3-4.fc12.i686 libuuid-2.16.2-5.fc12.i686
> libxcb-1.5-1.fc12.i686
> (gdb) bt
> #0  0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38)
>    at main/framebuffer.c:1021
> #1  0xb7d75758 in _mesa_GetIntegerv (pname=35738, params=0x804c41c)
>    at main/get.c:5576
> #2  0x080493ae in Init (argc=1, argv=0xbffff2b4) at readpix.c:354
> #3  main (argc=1, argv=0xbffff2b4) at readpix.c:396
> (gdb)
I have the segfault with i915g and non-gallium fakeglx.  It seems _mesa_Get*
should also validate the states before getting these state variables

 - GL_IMPLEMENTATION_COLOR_READ_TYPE_OES
 - GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES

-- 
ol...@Lu...

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Chia-I Wu <ol...@gm...>]

On Sun, Apr 4, 2010 at 6:31 PM, Dave Airlie <ai...@gm...> wrote:
> Hey,
>
> So I was trying to fix tfp test on r300g, and ran into an issue with
> dri st I think.
>
> So the way TFP works we get dri2_set_tex_buffer, which then validates the
> attachment, but ignores the format passed in. So r300g picks up the kernel
> buffer from the handle and sets up the texture + texture state without
> the format
> information.
>
> Once we've validated, we call ctx->st->teximage and can give it a different
> format however at no point does r300g get any place to change the texture format
> and update its internal state.
>
> I'm not sure if either r300g should delay setting up its internal
> state for emission
> until later or whether we need to enhance the st interface.
>
> The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8
> which triggers this.
The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
passes the test with the patch?

The teximage callback has an internal_format parameter that specifies how the
pipe texture should be treated.  It can differ from the format of the texture.
It seems to suffice for TFP.  I was lazy enough not to use it :(

-- 
ol...@Lu...

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

[Luca B. <luc...@gm...>]

> Way back I actually looked into LLVM for R300. I was totally
> unconvinced by their vector support back then, but that may well have
> changed. In particular, I'm curious about how LLVM deals with
> writemasks. Writing to only a select subsets of components of a vector
> is something I've seen in a lot of shaders, but it doesn't seem to be
> too popular in CPU-bound SSE code, which is probably why LLVM didn't
> support it well. Has that improved?
>
> The trouble with writemasks is that it's not something you can just
> implement one module for. All your optimization passes, from simple
> peephole to the smartest loop modifications need to understand the
> meaning of writemasks.

You should be able to just use
shufflevector/insertelement/extractelement to mix the new computed
values with the previous values in the vector register (as well as
doing swizzles).

There is also the option of immediately scalarizing, optimizing the
scalar code, and then revectorizing.
This risks pessimizing the input code, but might turn out to work well.

> I agree, though if I were to start an LLVM-based compilation project,
> I would do it for R600+, not for R300. That would be a very different
> kind of project.

> A LLVM->TGSI conversion is not the best way to go because TGSI doesn't
> match the hardware all that well, at least in the Radeon family.
> R300-R500 fragment programs have the weird RGB/A split, and R600+ is
> yet another beast that looks quite different from TGSI. So at least
> for Radeon, I believe it would be best to generate hardware-level
> instructions directly from LLVM, possibly via some Radeon-family
> specific intermediate representation.

The advantage of LLVM->TGSI would be that it works with all drivers
without any driver specific code, so it probably makes sense as an
initial step.
nv30/nv40 fragment programs map almost directly to TGSI (with the
addition of condition codes, and half float precision, and a few other
things).
Things that end up using an existing graphics API like vmware svga, or
using the llvm optimizer for game development, also need tgsi-like
output.
Thus, even if TGSI itself becomes irrelevant at some point, any
nontrivial parts of the LLVM->TGSI code should be needed anyway for
those cases.

[Mesa3d-dev] Emergency Mesa 7.8.1 release coming this Monday.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

Over the weekend I was alerted that some values in Mesa's glxext.h do
not match the values in the OpenGL registry.  Specifically, the value of
GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK is wrong both in name and in value.
 I am going to fix this by syncing the official version of glxext.h from
the Khronos website.  In the mean time please do not distribute or use
the copy of glxext.h in Mesa.  Use version 27 or later from the
OpenGL.org website:

http://www.opengl.org/registry/api/glxext.h

I won't have time to make the release until Monday morning PDT.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku5JsMACgkQX1gOwKyEAw+CNwCfeFQFIK25HPAlfh+g/nFtLUno
AMAAn2500k2DwL9JvNgCybl8pOiqrTrS
=kRJm
-----END PGP SIGNATURE-----

[Mesa3d-dev] segfault in readpix demo with GL_OES_read_format on r300g

[Dave A. <ai...@gm...>]

Starting program: /home/airlied/mesa/progs/demos/readpix
[Thread debugging using libthread_db enabled]
GL_VERSION = 2.1 Mesa 7.9-devel
GL_RENDERER = Gallium 0.4 on RV530

Program received signal SIGSEGV, Segmentation fault.
0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38)
    at main/framebuffer.c:1021
1021	}
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-8.fc12.i686 libICE-1.0.6-1.fc12.i686
libSM-1.1.0-7.fc12.i686 libX11-1.3-1.fc12.i686
libXdamage-1.1.2-1.fc12.i686 libXext-1.1-2.fc12.i686
libXfixes-4.0.4-1.fc12.i686 libXi-1.3-2.fc12.i686
libXmu-1.0.5-1.fc12.i686 libXt-1.0.7-1.fc12.i686
libXxf86vm-1.1.0-1.fc12.i686 libgcc-4.4.3-4.fc12.i686
libstdc++-4.4.3-4.fc12.i686 libuuid-2.16.2-5.fc12.i686
libxcb-1.5-1.fc12.i686
(gdb) bt
#0  0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38)
    at main/framebuffer.c:1021
#1  0xb7d75758 in _mesa_GetIntegerv (pname=35738, params=0x804c41c)
    at main/get.c:5576
#2  0x080493ae in Init (argc=1, argv=0xbffff2b4) at readpix.c:354
#3  main (argc=1, argv=0xbffff2b4) at readpix.c:396
(gdb)


Dave.

[Mesa3d-dev] Gallium: EXT_gpu_program_parameters

[Marek O. <ma...@gm...>]

Hi devs,

this extensions is extensively used in Wine for obvious performance reasons
and is quite popular in the GL community, therefore we should advertise it.
All needed code seems to be already in mesa/main, so unless I overlooked
something, the patch below is sufficient. Any comments, please?

-Marek

diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 0118c60..ae5e62b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -183,6 +183,7 @@ void st_init_extensions(struct st_context *st)
    ctx->Extensions.EXT_framebuffer_object = GL_TRUE;
    ctx->Extensions.EXT_framebuffer_multisample = GL_TRUE;
    ctx->Extensions.EXT_fog_coord = GL_TRUE;
+   ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
    ctx->Extensions.EXT_multi_draw_arrays = GL_TRUE;
    ctx->Extensions.EXT_pixel_buffer_object = GL_TRUE;
    ctx->Extensions.EXT_point_parameters = GL_TRUE;

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Dave A. <ai...@gm...>]

>
> Here's a hacky patch to demonstrate the issue, though it doesn't fix the problem
> I'm seeing with the test, just one less thing wrong.
>

Here's a second patch that actually fixes the piglit tfp test for me on r300g.

Dave.

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

[Nicolai H. <nha...@gm...>]

On Sat, Apr 3, 2010 at 2:37 PM, Luca Barbieri <luc...@gm...> wrote:
> Note all "X compiler is bad for VLIW or whatever GPU architecture"
> objections are irrelevant, since almost all optimizations are totally
> architecture independent.

Way back I actually looked into LLVM for R300. I was totally
unconvinced by their vector support back then, but that may well have
changed. In particular, I'm curious about how LLVM deals with
writemasks. Writing to only a select subsets of components of a vector
is something I've seen in a lot of shaders, but it doesn't seem to be
too popular in CPU-bound SSE code, which is probably why LLVM didn't
support it well. Has that improved?

The trouble with writemasks is that it's not something you can just
implement one module for. All your optimization passes, from simple
peephole to the smartest loop modifications need to understand the
meaning of writemasks.


> This is obviously not achievable if Mesa/Gallium contributors are
> supposed to write the compiler optimization themselves, since clearly
> there is not even enough manpower to support a relatively up-to-date
> version of OpenGL or, say, to have drivers that can allocate and fence
> GPU memory in a sensible and fast way, or implement hierarchical Z
> buffers, or any of the other things expected from a decent driver,
> that the Mesa drivers don't do.

I agree, though if I were to start an LLVM-based compilation project,
I would do it for R600+, not for R300. That would be a very different
kind of project.


> So, for a GSoC project, I'd kind of suggest:
> (1) Adapt the gallivm/llvmpipe TGSI->LLVM converter to also generate
> AoS code (i.e. RGBA vectors as opposed to RRRR, GGGG, etc.) if
> possible or write one from scratch otherwise
> (2) Write a LLVM->TGSI backend, restricted to programs without any control flow
> (3) Make LLVM->TGSI always work (even with control flow and DDX/DDY)
> (4) Hook up all useful LLVM optimizations

A LLVM->TGSI conversion is not the best way to go because TGSI doesn't
match the hardware all that well, at least in the Radeon family.
R300-R500 fragment programs have the weird RGB/A split, and R600+ is
yet another beast that looks quite different from TGSI. So at least
for Radeon, I believe it would be best to generate hardware-level
instructions directly from LLVM, possibly via some Radeon-family
specific intermediate representation.

The thing is, a lot of the optimizations in the r300 compiler are
actually there *because* TGSI (and Mesa instructions) are not a good
match for what the hardware looks like. So replacing those
optimizations by an LLVM pass which then becomes useless due to a drop
to TGSI seems a bit silly.

In a way, this is rather frustrating when dealing with the assembly
produced by the Mesa GLSL compiler. That compiler is rather
well-meaning and tries to deal well with scalar values, but then those
"optimizations" are actually counterproductive for Radeon, because
they end up e.g. using instructions like RCP and RSQ on one of the RGB
components, which happens to be a really bad idea. It would be nice if
we could feed e.g. LLVM IR into the Gallium driver instead of TGSI,
and let the Gallium driver worry about all optimizations.

Anyway, I'm convinced that LLVM (or something like it) is necessary
for the future. However, for this particular GSoC proposal, it's off
the mark.

cu,
Nicolai

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

[Nicolai H. <nha...@gm...>]

Hi,

On Sat, Apr 3, 2010 at 3:31 AM, Tom Stellard <tst...@gm...> wrote:
> I have completed a first draft of my Google Summer of Code
> proposal, and I would appreciate feedback from some of the
> Mesa developers.  I have included the project plan from my
> proposal in this email, and you can also view my full proposal here:
> http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/tstellar/t126997450856
> However, I think you will need a google login to view it.

I like your proposal, and I believe it's quite workable as a GSoC
project as far as scope is concerned. The LLVM points mentioned are
valid, but since you seem to be interested in focusing on R300, I
believe you are absolutely on the right track, since if you complete
the tasks outlined in your project, it will be a very tangible step
forward *right now*.

<snip>
> Schedule / Deliverables:
> 1. Enable branch emulation for Gallium drivers (4 weeks)
> 2. Unroll loops for Gallium drivers (2 - 3 weeks)

I believe your time estimate for loop unrolling should be longer, and
for branch emulation probably shorter, particularly since there is
existing work. So branch emulation should go much quicker; I don't
think the part about re-translating to TGSI is too difficult.

> Midterm Evaluation
> 3. Loops and Conditionals for R500 fragment and vertex shaders (4 weeks)

This part is in some ways the most interesting one, and even if we do
go to LLVM eventually (but I doubt it's going to happen any time
soon), this part will still be needed.

It would definitely be great to see this project come to fruition!

cu,
Nicolai

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

[Dave A. <ai...@gm...>]

On Sun, Apr 4, 2010 at 8:31 PM, Dave Airlie <ai...@gm...> wrote:
> Hey,
>
> So I was trying to fix tfp test on r300g, and ran into an issue with
> dri st I think.
>
> So the way TFP works we get dri2_set_tex_buffer, which then validates the
> attachment, but ignores the format passed in. So r300g picks up the kernel
> buffer from the handle and sets up the texture + texture state without
> the format
> information.
>
> Once we've validated, we call ctx->st->teximage and can give it a different
> format however at no point does r300g get any place to change the texture format
> and update its internal state.
>
> I'm not sure if either r300g should delay setting up its internal
> state for emission
> until later or whether we need to enhance the st interface.
>
> The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8
> which triggers this.
>

Here's a hacky patch to demonstrate the issue, though it doesn't fix the problem
I'm seeing with the test, just one less thing wrong.

Dave.

Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex

[Luca B. <luc...@gm...>]

>> If you mean that r300 doesn't support R16G16B16, I suppose you can
>> just use R16G16B16A16 and ignore the extra fetched w element (the
>> vertex buffer stride will make this work properly).
>
> I've tried to do it this way, it locks up (unless I am missing something).

Shouldn't there be official ATI hardware documentation for r300
describing such things? (just curious)

Otherwise, I guess you could trace the ATI binary driver and see what it does...

Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex

[Marek O. <ma...@gm...>]

On Sun, Apr 4, 2010 at 10:28 PM, Luca Barbieri <luc...@gm...>wrote:

> > Does it mean there will be format fallbacks? Because dword-unaligned but
> > still pretty common (i.e. GL1.1) vertex formats aren't supported by r300,
> > most often we hit R16G16B16. What will happen when is_format_supported
> says
> > NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3,
> which
> > every in-tree state tracker ignores.
>
> I'm not sure I understand correctly what you are saying.
>
> The idea is to do like you did in your patch, but instead of calling
> screen->get_param(screen, PIPE_CAP_HALF_FLOAT_VERTEX), calling
> screen->is_format_supported(screen, PIPE_FORMAT_R16G16B16G16,
> PIPE_BUFFER, ..., ...).
>
> The PIPE_BUFFER target is supported in gallium-resources, but I'm not
> sure whether this way of querying vertex formats is supported; it
> would probably need to be added first.
>
> If you mean that r300 doesn't support R16G16B16, I suppose you can
> just use R16G16B16A16 and ignore the extra fetched w element (the
> vertex buffer stride will make this work properly).
>

I've tried to do it this way, it locks up (unless I am missing something).

However, if non-dword-aligned vertex buffer strides or vertex element
> offsets are not supported, I think you have a serious problem, which
> is however independent of half float vertices since I don't think
> OpenGL places any alignment constraints on those values (correct me if
> I'm wrong).
>

You're right.

-Marek