mesa3d-dev

[Mesa3d-dev] [PATCH] fix cell build

[Marc D. <mar...@gm...>]

From: root <ro...@fb...>

compile fix for cell driver.
---
 src/gallium/drivers/cell/ppu/cell_screen.c  |    3 +++
 src/gallium/drivers/cell/ppu/cell_texture.c |    2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/src/gallium/drivers/cell/ppu/cell_screen.c b/src/gallium/drivers/cell/ppu/cell_screen.c
index 363d1e6..aaa1694 100644
--- a/src/gallium/drivers/cell/ppu/cell_screen.c
+++ b/src/gallium/drivers/cell/ppu/cell_screen.c
@@ -138,6 +138,9 @@ cell_is_format_supported( struct pipe_screen *screen,
                           unsigned tex_usage, 
                           unsigned geom_flags )
 {
+
+   struct sw_winsys *winsys = cell_screen(screen)->winsys;
+
    if (tex_usage & (PIPE_TEXTURE_USAGE_DISPLAY_TARGET |
                     PIPE_TEXTURE_USAGE_SCANOUT |
                     PIPE_TEXTURE_USAGE_SHARED)) {
diff --git a/src/gallium/drivers/cell/ppu/cell_texture.c b/src/gallium/drivers/cell/ppu/cell_texture.c
index 5b169af..6d746eb 100644
--- a/src/gallium/drivers/cell/ppu/cell_texture.c
+++ b/src/gallium/drivers/cell/ppu/cell_texture.c
@@ -105,7 +105,7 @@ cell_displaytarget_layout(struct pipe_screen *screen,
    /* Round up the surface size to a multiple of the tile size?
     */
    ct->dt = winsys->displaytarget_create(winsys,
-                                          ct->base->tex_usage,
+                                          ct->base.tex_usage,
                                           ct->base.format,
                                           ct->base.width0, 
                                           ct->base.height0,
-- 
1.6.4.2

Re: [Mesa3d-dev] [xserver patch v4 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.

[Jesse B. <jb...@vi...>]

On Mon,  8 Feb 2010 19:25:14 +0100
Francisco Jerez <cur...@ri...> wrote:

> The spec says (regarding glXCreateWindow): "If there is already a
> GLXFBConfig associated with win (as a result of a previous
> glXCreateWindow call), then a BadAlloc error is generated.". It will
> also come useful to implement DRI2InvalidateBuffers for the indirect
> case.
> 
> Signed-off-by: Francisco Jerez <cur...@ri...>
> ---
>  glx/glxcmds.c   |   51 +++++++++++++++++++++++++++++++++++++++++++++------
>  glx/glxserver.h |    1 +
>  2 files changed, 46 insertions(+), 6 deletions(-)
> 
> diff --git a/glx/glxcmds.c b/glx/glxcmds.c
> index 77afbf4..0e1c89c 100644
> --- a/glx/glxcmds.c
> +++ b/glx/glxcmds.c
> @@ -51,6 +51,15 @@
>  #include "indirect_table.h"
>  #include "indirect_util.h"
>  
> +static int glxWindowPrivateKeyIndex;
> +static DevPrivateKey glxWindowPrivateKey = &glxWindowPrivateKeyIndex;
> +
> +__GLXdrawable *
> +glxGetDrawableFromWindow(WindowPtr pWin)
> +{
> +	return dixLookupPrivate(&pWin->devPrivates, glxWindowPrivateKey);
> +}

Thanks for pointing this out.  Can we use this in
glxscreens.c:glxDestroyWindow() to invalidate the drawable pointer in
the glx drawable at window destroy time?  That would be a good way to
fix https://bugs.freedesktop.org/show_bug.cgi?id=26394; probably better
than trying to mix in (or totally switch to) XIDs for tracking things.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Mesa3d-dev] Mesa (master): egl_dri2: Flush before context switch and swap buffers.

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

2010/4/6 Michel Dänzer <mi...@da...>:
> On Tue, 2010-04-06 at 04:56 -0700, Chia-I Wu wrote:
>> Module: Mesa
>> Branch: master
>> Commit: d18d0fdcd8daa0d9979b72978795f0305d2db7c8
>> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=d18d0fdcd8daa0d9979b72978795f0305d2db7c8
>>
>> Author: Chia-I Wu <ol...@lu...>
>> Date:   Tue Apr  6 19:52:39 2010 +0800
>>
>> egl_dri2: Flush before context switch and swap buffers.
>>
>> DRI does not define any callback to flush the current context.  GLX
>> loader simply calls glFlush.  Follow the GLX loader here.
> Beware that the GLX loader doesn't follow the GLX spec for SwapBuffers
> (3.3.10):
>        *If* dpy and draw are the display and drawable for the calling
>        thread’s current context, glXSwapBuffers performs an implicit
>        glFlush.
> (emphasis mine)
Yes, the change follows EGL spec, which is equivalent to GLX here:

    If dpy and surface are the display and surface for the calling
thread’s current
context, eglSwapBuffers and eglCopyBuffers perform an implicit flush operation
on the context (glFlush for an OpenGL or OpenGL ES context, vgFlush for an
OpenVG context).

Thanks for reminding still.

-- 
ol...@Lu...

Re: [Mesa3d-dev] Mesa (master): egl_dri2: Flush before context switch and swap buffers.

[Michel D. <mi...@da...>]

On Tue, 2010-04-06 at 04:56 -0700, Chia-I Wu wrote: 
> Module: Mesa
> Branch: master
> Commit: d18d0fdcd8daa0d9979b72978795f0305d2db7c8
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=d18d0fdcd8daa0d9979b72978795f0305d2db7c8
> 
> Author: Chia-I Wu <ol...@lu...>
> Date:   Tue Apr  6 19:52:39 2010 +0800
> 
> egl_dri2: Flush before context switch and swap buffers.
> 
> DRI does not define any callback to flush the current context.  GLX
> loader simply calls glFlush.  Follow the GLX loader here.

Beware that the GLX loader doesn't follow the GLX spec for SwapBuffers
(3.3.10):

        *If* dpy and draw are the display and drawable for the calling
        thread’s current context, glXSwapBuffers performs an implicit
        glFlush.

(emphasis mine)


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

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

[Keith W. <ke...@vm...>]

On Fri, 2010-04-02 at 20:43 -0700, 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?
> 
> Dave.

This change makes sense & looks good to me.

Keith

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <ke...@vm...>]

On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote:
> There's something fishy in u_upload_mgr, could you please review the
> first two patches here?
> http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources
> 
> With this, r300g works again.

Hmm, I think the second of the patches (flush range relative to mapped
range vs whole buffer) may be addressing a regression that has creeped
into the -resources branch regarding this behaviour - ie. I think the
code you modified was actually correct, but that
pipe_flush_mapped_buffer_range() has changed to do the wrong thing.

I'll try and figure out what should be happening.

Keith

[Mesa3d-dev] [Bug 23494] Swrast regression has broken fog

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

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

Pauli <su...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

-- 
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] 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

Pauli <su...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|GLUT                        |Drivers/DRI/r200
         AssignedTo|mes...@li...urceforg |dri...@li...urceforge
                   |e.net                       |.net

--- Comment #2 from Pauli <su...@gm...> 2010-04-06 01:54:47 PDT ---
Sounds like 3D driver bug.

Please attach xorg.log.

Also testing with KMS enabled system would be nice.

-- 
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

Pauli <su...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |NEEDINFO
          Component|GLUT                        |Drivers/DRI/r200
         AssignedTo|mes...@li...urceforg |dri...@li...urceforge
                   |e.net                       |.net

--- Comment #2 from Pauli <su...@gm...> 2010-04-06 01:51:54 PDT ---
Sounds like 3D driver bug. Can you test 3D with kernel 2.6.33 and KMS enabled
libdrm, xf86-video-ati and mesa? http://www.x.org/wiki/radeonBuildHowTo is ood
source of information if you need to compile something.

Please attach your xorg.log.

-- 
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 27469] Mesa 7.8: Problems with two games, using OpenGL

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

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

Pauli <su...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID
          Component|Other                       |Drivers/DRI/r200
         AssignedTo|mes...@li...urceforg |dri...@li...urceforge
                   |e.net                       |.net

--- Comment #2 from Pauli <su...@gm...> 2010-04-06 01:47:39 PDT ---
Marking this invalid for 2 reasons

-Only one bug per report!
-There is no GLSL support with r200 card. You need at least r500 card for
shaders. Using shaders or any others gl2+ features with driver that only
reports version 1.3 is clear application bug.

-- 
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] Emergency Mesa 7.8.1 release coming this Monday.

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

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

Jesse Barnes wrote:
> 
> Sorry about that, now I know I shouldn't have edited that files.  For
> future reference those creating new extensions should:
>   - add temporary values to glx.h with an 'X' appended to indicate a
>     temporary value (e.g. INTELX_swap_event)
>   - never edit glxext.h
>   - remove the temp values once the updated glxext.h arrives from the
>     registry
> 
> Is that all Ian?

Right.  glxext.h and glext.h are not to be modified.  "In progress"
extensions should go into glx.h or gl.h.  If final enums have not been
set (i.e., while the extension is under development) "X" should be added
to the names.  This advertises that the extension is still experimental,
and it prevents apps from tripping up when the enums change to the final
values.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku6RK8ACgkQX1gOwKyEAw9WAwCgk1YAD0nSnSTtWaCfaMuRBBtq
flUAn1V/vcqvb4tjWw3ILfv31XIzsGJG
=Fn4A
-----END PGP SIGNATURE-----

[Mesa3d-dev] [Bug 27461] 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

--- Comment #1 from Ian Romanick <id...@fr...> 2010-04-05 13:09:26 PDT ---
Please don't submit zipped attachments.  Just submit the .c file and make sure
the mime type is text/plain.

-- 
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 27469] Mesa 7.8: Problems with two games, using OpenGL

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

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

Ian Romanick <id...@fr...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |NEEDINFO

--- Comment #1 from Ian Romanick <id...@fr...> 2010-04-05 13:07:55 PDT ---
(In reply to comment #0)

> 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.

I'm pretty sure the r200 driver does not implement GLSL.  Try running in GDB. 
Set a break point at _mesa_UseProgramObjectARB.  If that breakpoint is hit, the
app is trying to use functionality that is not supported.  That it doesn't
shouldn't surprise anyone. :)

-- 
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] Mesa 7.8.1 released

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

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

Mesa 7.8.1 has been released.  The primary purpose of this release is to
fix a significant error in Mesa's copy of glxext.h and the libGL code
that uses it.  The release also contains some other bug fixes.

The tag in the GIT repository for Mesa 7.8.1 is 'mesa-7.8.1'.

Mesa-7.8.1 is now available for download at
ftp://freedesktop.org/pub/mesa/7.8.1/

md5sums:

62e8e47cbd63741b4bbe634dcdc8a56a  MesaLib-7.8.1.tar.gz
25ec15f8e41fde6d206118cc786dbac4  MesaLib-7.8.1.tar.bz2
22b1153010ffdf513836ea9931159e80  MesaLib-7.8.1.zip
c9c0a830923d3820807a08c09d521b3e  MesaDemos-7.8.1.tar.gz
9ef47f911869657c6bf2f43ebce86b61  MesaDemos-7.8.1.tar.bz2
93720605eb3f784f9bcc289a4dd2ff52  MesaDemos-7.8.1.zip
ed1d0b1e960afe6a3768eab747cbdbd3  MesaGLUT-7.8.1.tar.gz
6bae516a44c6d26ff3152c960ab648e7  MesaGLUT-7.8.1.tar.bz2
ba306f603ea73c30ee0e7efa14dc5581  MesaGLUT-7.8.1.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku6QR4ACgkQX1gOwKyEAw+ZgQCgh7fRDzTY0v0Fefe7XbNmf7Y1
DqMAmgP7boN6YSCuMcXTiYdr9hhYKS1N
=Cqle
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Gallium: EXT_gpu_program_parameters

[Brian P. <br...@vm...>]

Marek Olšák wrote:
> 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;
> 

Looks good.  There's nothing driver-specific about this extension.

-Brian

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

[Brian P. <br...@vm...>]

Brian Paul wrote:
> 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?
> 
> The piglit test passes as-is with Mesa/swrast and NVIDIA.
> 
> It fails with gallium/softpipe both with and w/out your patch.
> 
> I think that your patch is on the right track.  But multiple render 
> targets are still a bit of an untested area in the st/mesa code.
> 
> One thing: the patch introduces a dependency on buffer state in the 
> texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag.
> 
> Otherwise, I'd like to debug the softpipe failure a bit further to see 
> what's going on.  Perhaps you could hold off on committing this for a 
> bit...

OK, I found/fixed the problem in softpipe.

I think your patch is good, but I think we should hold off on 
committing it to the 7.8 branch until it's tested a bit more (and not 
delay the 7.8.1 release).  Other people should apply it and give it a try.

-Brian

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

[Jesse B. <jb...@vi...>]

On Sun, 04 Apr 2010 16:54:45 -0700
Ian Romanick <id...@fr...> wrote:

> -----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.

Sorry about that, now I know I shouldn't have edited that files.  For
future reference those creating new extensions should:
  - add temporary values to glx.h with an 'X' appended to indicate a
    temporary value (e.g. INTELX_swap_event)
  - never edit glxext.h
  - remove the temp values once the updated glxext.h arrives from the
    registry

Is that all Ian?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

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

[Brian P. <br...@vm...>]

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?

The piglit test passes as-is with Mesa/swrast and NVIDIA.

It fails with gallium/softpipe both with and w/out your patch.

I think that your patch is on the right track.  But multiple render 
targets are still a bit of an untested area in the st/mesa code.

One thing: the patch introduces a dependency on buffer state in the 
texenvprogram code so in state.c we should check for the _NEW_BUFFERS 
flag.

Otherwise, I'd like to debug the softpipe failure a bit further to see 
what's going on.  Perhaps you could hold off on committing this for a 
bit...

-Brian

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

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

> This might depend on the target: R600+, for example, is quite
> scalar-oriented anyway (modulo a lot of subtle limitations), so just
> pretending that everything is scalar could work well there since
> revectorizing is almost unnecessary.

Interesting, nv50 is also almost fully scalar, and based on the
Gallium driver source, i965 seems to be scalar too.

So it seems it would really make sense to also have a scalar IR,
whether LLVM IR or something else.

Of course, "scalar" is usually actually SoA SIMD, but that's mostly
hidden, except for things like barriers, join points and nv50 "voting"
instructions.

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

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

On Mon, Apr 05, 2010 at 11:18:39AM -0400, Nicolai Haehnle wrote:
> Hi,
> 
> On Mon, Apr 5, 2010 at 1:58 AM, Tom Stellard <tst...@gm...> wrote:
> > 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.
> 
> You misspelled my name :P
> 
Oops. Sorry.  How do you spell your name?  Your git commits say Nicolai
Hähnle, but your email says Nicolai Haehnle.

> > 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.
> 
> It is certain that not all loops will be able to be unrolled
> successfully, if only due to limits on the number of instruction in a
> shader ;)
> 
> For loops with number of iterations determined at runtime, you should
> check (ask around) for real-life shaders where this is the case. The
> example you mention sounds unrealistic to me, but I could imagine that
> there are shaders with an *upper-bound* on the number of iterations
> known at compile time. Then loops can be unrolled to that upper-bound,
> and later iterations could be masked off somehow based on the actual
> desired number of iterations at runtime.
> 
> Also note that early GLSL revision actually have some very strict
> limits on the kinds of loops the shaders can contain there.
>
Ok, I'll look into this a little bit more, and see what I can find out.

> > 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.
> 
> I think you should highlight that the point of this exercise is that
> drivers for *other* hardware might want to use this functionality.
>

Thanks for you input.

-Tom Stellard

Re: [Mesa3d-dev] mesa: update_arrays() depends on program state.

[Brian P. <br...@vm...>]

Henri Verbeet wrote:
> It uses ctx->VertexProgram._Current.
> ---
>  src/mesa/main/state.c |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
> index 589029d..b971cc9 100644
> --- a/src/mesa/main/state.c
> +++ b/src/mesa/main/state.c
> @@ -582,9 +582,6 @@ _mesa_update_state_locked( GLcontext *ctx )
>     if (new_state & _DD_NEW_SEPARATE_SPECULAR)
>        update_separate_specular( ctx );
>  
> -   if (new_state & (_NEW_ARRAY | _NEW_PROGRAM | _NEW_BUFFER_OBJECT))
> -      update_arrays( ctx );
> -
>     if (new_state & (_NEW_BUFFERS | _NEW_VIEWPORT))
>        update_viewport_matrix(ctx);
>  
> @@ -620,6 +617,8 @@ _mesa_update_state_locked( GLcontext *ctx )
>        new_prog_state |= update_program( ctx );
>     }
>  
> +   if (new_state & (_NEW_ARRAY | _NEW_PROGRAM | _NEW_BUFFER_OBJECT))
> +      update_arrays( ctx );
>  
>   out:
>     new_prog_state |= update_program_constants(ctx);


Looks good.  I'll commit shortly.  Thanks.

-Brian

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

[Brian P. <br...@vm...>]

Nicolai Haehnle wrote:
> Hi,
> 
> On Mon, Apr 5, 2010 at 1:58 AM, Tom Stellard <tst...@gm...> wrote:
>> 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.
> 
> You misspelled my name :P
> 
>> 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.
> 
> It is certain that not all loops will be able to be unrolled
> successfully, if only due to limits on the number of instruction in a
> shader ;)
> 
> For loops with number of iterations determined at runtime, you should
> check (ask around) for real-life shaders where this is the case. The
> example you mention sounds unrealistic to me, but I could imagine that
> there are shaders with an *upper-bound* on the number of iterations
> known at compile time. Then loops can be unrolled to that upper-bound,
> and later iterations could be masked off somehow based on the actual
> desired number of iterations at runtime.

See progs/glsl/CH18-mandel.frag for an example:

     for (iter = 0.0; iter < 12.0 && r2 < 4.0; ++iter)

I believe the Phoronix Lightsmark demo also uses some loops in its 
shaders.

It's not feasible to unroll all loops but some common cases are doable.

-Brian

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

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

Hi,

On Mon, Apr 5, 2010 at 1:58 AM, Tom Stellard <tst...@gm...> wrote:
> 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.

You misspelled my name :P

> 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.

It is certain that not all loops will be able to be unrolled
successfully, if only due to limits on the number of instruction in a
shader ;)

For loops with number of iterations determined at runtime, you should
check (ask around) for real-life shaders where this is the case. The
example you mention sounds unrealistic to me, but I could imagine that
there are shaders with an *upper-bound* on the number of iterations
known at compile time. Then loops can be unrolled to that upper-bound,
and later iterations could be masked off somehow based on the actual
desired number of iterations at runtime.

Also note that early GLSL revision actually have some very strict
limits on the kinds of loops the shaders can contain there.

> 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.

I think you should highlight that the point of this exercise is that
drivers for *other* hardware might want to use this functionality.

cu,
Nicolai

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

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

On Sun, Apr 4, 2010 at 10:42 PM, Luca Barbieri <luc...@gm...> wrote:
>> 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).

Okay, that looks good.

> 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.

This might depend on the target: R600+, for example, is quite
scalar-oriented anyway (modulo a lot of subtle limitations), so just
pretending that everything is scalar could work well there since
revectorizing is almost unnecessary.

cu,
Nicolai

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

[Brian P. <br...@vm...>]

Chia-I Wu wrote:
> 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

Yeah, that's it.  I'll commit a fix.

-Brian