mesa3d-dev

[Mesa3d-dev] [PATCH-RFC] st/mesa: Add GL_OES_EGL_image support

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

Hi Jakob,

This patch series adds support for GL_OES_EGL_image to st/mesa.  The first
patch implements st_manager::get_egl_image in st/egl.  The hook is used to
check and return an st_egl_image, which describes an EGLImageKHR.  The second
patch implements GL_OES_EGL_image in st/mesa, and the last patch adds a demo
for the new functionality.  I've tested it with egl_x11_i915.so, but it should
work with other hardware drivers.

Do you mind having a look at the patches, especially the first one?  I'd like
to hear your opinions before merging the patches, and going on to work on
EGLImage support in st/dri.

-- 
ol...@Lu...

Re: [Mesa3d-dev] Mesa (master): llvmpipe: fix up some questionable fence code

[José F. <jfo...@vm...>]

Brian,

Your fix is right. The last_fence variable was a remnant of some state
tracker code I based the change on, and had no place here.

Jose

On Wed, 2010-03-24 at 19:50 -0700, Brian Paul wrote:
> Module: Mesa
> Branch: master
> Commit: 9a5241758231b2dd5ae757645158fa33051f5507
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=9a5241758231b2dd5ae757645158fa33051f5507
> 
> Author: Brian Paul <br...@vm...>
> Date:   Wed Mar 24 20:40:31 2010 -0600
> 
> llvmpipe: fix up some questionable fence code
> 
> Jose should probably review this since he wrote the original code.
> 
> ---
> 
>  src/gallium/drivers/llvmpipe/lp_flush.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/llvmpipe/lp_flush.c b/src/gallium/drivers/llvmpipe/lp_flush.c
> index 636d72a..782669a 100644
> --- a/src/gallium/drivers/llvmpipe/lp_flush.c
> +++ b/src/gallium/drivers/llvmpipe/lp_flush.c
> @@ -111,7 +111,6 @@ llvmpipe_flush_texture(struct pipe_context *pipe,
>                         boolean cpu_access,
>                         boolean do_not_flush)
>  {
> -   struct pipe_fence_handle *last_fence = NULL;
>     unsigned referenced;
>  
>     referenced = pipe->is_texture_referenced(pipe, texture, face, level);
> @@ -142,7 +141,7 @@ llvmpipe_flush_texture(struct pipe_context *pipe,
>  
>           pipe->flush(pipe, flush_flags, &fence);
>  
> -         if (last_fence) {
> +         if (fence) {
>              pipe->screen->fence_finish(pipe->screen, fence, 0);
>              pipe->screen->fence_reference(pipe->screen, &fence, NULL);
>           }
> 
> _______________________________________________
> mesa-commit mailing list
> mes...@li...
> http://lists.freedesktop.org/mailman/listinfo/mesa-commit

[Mesa3d-dev] [PATCH-RFC] st/mesa: Add GL_OES_EGL_image support

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

Hi Jakob,

This patch series adds support for GL_OES_EGL_image to st/mesa.  The first
patch implements st_manager::get_egl_image in st/egl.  The hook is used to
check and return an st_egl_image, which describes an EGLImageKHR.  The second
patch implements GL_OES_EGL_image in st/mesa, and the last patch adds a demo
for the new functionality.  I've tested it with egl_x11_i915.so, but it should
work with other hardware drivers.

Do you mind having a look at the patches, especially the first one?  I'd like
to hear your opinions before merging the patches, and going on to work on
EGLImage support in st/dri.

-- 
ol...@Lu...

[Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

[SpliFF <sp...@wa...>]

Hi radeonhd, nouveau, mesa3d developers,

Firstly, thank you all very much for all the important work you do.

I've been working as a part-time developer on the "Spring RTS" project
(open-source game engine) which runs on linux (and other os). Some time
ago I tried the engine on the open-source ATI radeonhd driver, which I
understand to be partly based on mesa 3d, and all textures were white. I
originally assumed it was an engine bug but after some investigation
tracked it down to s3tc texture (de)compression not being integrated in
the open driver for legal reasons. It seems the same issue applies to
Mesa3d and Nouveau - that is s3tc being patented and the patent owner
refusing to comment or provide cover for open-source projects
implementing the techniques discussed in US Patent 5956431
(http://v3.espacenet.com/publicationDetails/claims?DB=&locale=&FT=D&date=19990921&CC=US&NR=5956431A&KC=A&tree=true)

I recently took inspiration from an article/talk presented by Andrew
Trigell regarding patents where he claims developers often overestimate
the scope of patents
(http://news.swpat.org/2010/03/transcript-tridgell-patents/) because
they fixate on the title and summary instead of the actual claims.

The key point he was making is that in order to infringe a patent you
apparently have to infringe on ALL ELEMENTS of a PRIMARY claim. If you
don't do something in the primary claim then by definition you aren't
doing the things in secondary claims that reference it (ie, where the
claim reads "... in claim X ..."). In short if you workaround the
primary claims you probably aren't infringing. Wikipeadia, with some
jurisdictional hand-waving, appears to agree: "If all of the claim's
elements are found in the technology, the claim is said to "read on" the
technology; if a single element from the claim is missing from the
technology, the claim does not literally read on the technology and the
technology does not infringe the patent with respect to that claim."

So I took a look at the 4 primary claims that apply to DECODING s3tc
textures. All other claims either rely on these claims or involve
encoding, which Mesa 3D / Xorg drivers should not need to do. Finding a
workaround for these primary claims is necessary to avoid infringement
for an s3tc decoder. I'll break these into seperate elements because a
workaround (non-infringement) for ANY element is a workaround for the
ENTIRE claim itself. The elements are seperated by semicolons and I've
added line-breaks to make them clearer).

To avoid confusion I've removed the preamble from each claim, they don't
count as elements of the claim.

In short, if anyone on these lists can see a way to decompress an s3tc
image without doing just 1 of the items from EACH of the following 4
claims then a legal s3tc decoder should be possible.

================
5.
an encoded image decomposer,
coupled to receive encoded image data file having at least one
compressed image block,
for breaking the encoded image data file into individual compressed
image blocks,
each compressed image block having at least one associated codeword,
each codeword generated through selecting a block type for an original
image block comprising the compressed image block,
computing an analog curve for the block type,
selecting a partition along the analog curve for the computed analog curve,
and computing the set of codewords for the partition;

at least one block decoder,
coupled to the encoded image decomposer,
for decompressing the compressed image blocks;

and an image composer,
coupled to each block decoder,
for ordering the decompressed image blocks in an output file.

==================
16.
receiving the encoded image data;

decomposing the encoded image into the modified header and the
individual encoded image blocks;

reading the modified header to generate an output header;

decoding each individual encoded image block to generate a decoded image
block,
including receiving each individual encoded image block, including a
plurality of codewords,
and a bitmap of at least one pixel,
the plurality of codewords derived through selecting a block type for an
original image block of the encoded image block,
computing an analog curve for the block type,
selecting a partition along the analog curve for the computed analog curve,
and computing the plurality of codewords for the partition;

and composing the output header and the individual decoded image blocks
to generate an output file of the original image.

==================
21.
a block address computation module, coupled to receive each codeword
from the header information, for computing an address of an encoded
image block having the identified pixel;

a block fetching module, coupled to receive the encoded image block
portion and the computed address, for fetching the encoded image block
having the identified pixel;

and a block decoder, coupled to receive the fetched encoded image block,
for decoding the image block to generate a quantized color associated
with the identified pixel.

==================
22.
computing an address for an encoded image block having the identified
pixel,
the address computed from the at least one codeword for the encoded
image block;

fetching the encoded image block using the computed address;

computing quantized color levels for the fetched encoded image block;

and selecting a color of the identified pixel from the quantized color
levels to output.

===================


One thing that stands out to me are that none of the primary claims seem
to describe the technical format itself (ie, no algorithms, keywords,
block sizes, byte-alignment, etc..) This means the claims at issue seem
to be *methods* of data handling, (and not particularly inventive ones
in my opinion). That suggests to me that with a little thought it should
be possible to generate the same results via a method that doesn't
infringe one of the 4 specific claims listed above. To clarify, despite
all the technical mumbling in the abstract the claimed invention does
not appear to be a "format" as such, but a method of pulling "blocks"
and a "header" out of an undefined format and generating "color pixels".
Even the abstract claims all the presented examples of keywords, values
and structure for s3tc are not the actual invention being claimed.
Another important point is that some of the wording in the claims may
not mean what it appears to mean (ie, the generally accepted
definition), the full patent may redefine some common software terms in
the wrapper.

Some possible avenues of investigation, straight off the top of my head are:

* Determine the patents' definition of a "unit" and/or "module", and use
something else (ie, a monolithic function)
* Determine the patents' definition of a "block", and use something
else. (characters, a bytestream, ...)
* Determine the patents' definition of "compose / decompose", and do
something else.
* Do we need to "compose a header" as a seperate stage (use a footer,
temporary vars, registers)
* Does the curve have to be "analog"? What about a lookup table with
discreet points that approximate a curve?
* Can the algorithms work on groups of blocks or sub-blocks instead of
"individual blocks".

More for DRI projects than Mesa, but I'll ask anyway:
* Do we need to decode anything; could an X11 driver force-feed the raw
bytes to hardware instead?

Claim 22 seems like a pretty important step and possibly a hard one to
workaround but it also appears to be claiming the invention of using a
key lookup to fetch values with some vague notion of quantising them. Is
it just me or are they claiming to have invented indexed color?

PS. If some of the points above seem pedantic that's deliberate. My
understanding is that patent claims are actually intended or required to
be NARROW in scope as broad claims are usually rejected. That means a
workaround that doesn't do PRECISELY the things in each claim above is,
by definition, a new invention. I'm hoping an invention that members of
this community are capable of finding before someone else patents it.

I've CC'ed the EFF on this because I'd like to see it become a part of
their patent-busting efforts. Fear of this patent is blocking an
extremely important component of 3D gaming under linux (the use of DDS
textures under an open-source driver). Not that I'm a fan of DDS, just
that it's the format of choice for commercial and non-commercial games
until hardware supports something better, and even then still a
requirement for running many classic games under WINE +
radeonhd/mesa3d/nouveau. It seems absurd that I can buy a product with a
patent license granted (NVIDIA/ATI card) but then be denied the
protection of that license because I don't use part of the product (the
official driver). I really hope that as a community we can either invent
around this patent or bust it (at least in US / EU where it is most
problematic) without losing hardware support or requiring the
reformatting/conversion of digital assets.

Regards,
SpliFF

[Mesa3d-dev] llvmpipe autoconf attempt one

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

I'm not even sure if its fully working, and I've done some nasty stuff
in the autoconf.in that probably doesn't belong there,

also the dri makefile change to use g++ instead of cc, not sure if
there is a cleaner way to do that either.

Dave.

[Mesa3d-dev] [Bug 27312] glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB

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

http://bugs.freedesktop.org/show_bug.cgi?id=27312





--- Comment #8 from Chia-I Wu <ol...@gm...>  2010-03-28 01:51:22 PST ---
(In reply to comment #0)
> tmpBuf = (GLubyte *)malloc(4*sizeof(GLubyte));
> glReadPixels(12, 12, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, tmpBuf);  
> 
> /*##############################################################
> ##############################################################
> ##############################################################
> tmpBuf[0]=tmpBuf[1]=tmpBuf[2] = 143 //Expected
> tmpBuf[3] = 143 //Not expected - This should be 255 as we are not using this
> component. I have checked this with other vendors NVIDIA and ATI and they
> indeed report correct behavior (tmpBuf[3] = 255)
> ##############################################################
> ##############################################################
> ##############################################################*/
I've tested the demo with current git head, using egl_x11_swrast driver and
libGLESv2.  It has the correct behavior (tmpBuf[3] is 255).  Do you want to try
again with git head or the to-be-released 7.8?


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

Re: [Mesa3d-dev] Rationale of gallium-resources changes?

[Corbin S. <mos...@gm...>]

On Sat, Mar 27, 2010 at 5:34 PM, Luca Barbieri <lu...@lu...> wrote:
> Having drivers capable of doing "send-to-hardware-and-forget-about-it"
> on arbitrary state setting could be a nice thing instead, but
> unfortunately a lot of hardware fundamentally can't do this, since for
> instance:
> 1. Shaders need to be all seen to be linked, possibly modifying the
> shaders themselves (nv30)
> 2. Constants need to be written directly into the fragment program (nv30-nv40)
> 3. Fragment programs depend on the viewport to implement
> fragment.position (r300)
> 4. Fragment programs depend on bound textures to specify normalization
> type and emulate NPOT (r300, r600?, nv30)
> and so on...
> 5. Sometimes sampler state and textures must be seen together since
> the hardware mixes it

To be fair, this is all "old hardware sucks at new APIs." We're
stretching a bit with r300 and nv30, hardware never really meant for
this kind of generalized pluggable pipeline setup. r500 and nv40 are
better, but it's not until r600 and nv50 that we really are completely
unburdened from all of this old suckage. That's life, unfortunately.

Also, I'm sure there's always going to be hardware that has quirks,
regardless of the set of functionality we expose. We're just going to
have to aim for the biggest common subsets plus the least painful way
of adding the full pipeline features. Gallium thankfully no longer
resembles its original target too much, but it's become a reasonable
abstraction.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<Mos...@gm...>

Re: [Mesa3d-dev] Rationale of gallium-resources changes?

[Luca B. <lu...@lu...>]

> To me this speaks to another aspect of the gallium interface which is
> a bit odd -- in particular the way several of our interfaces basically
> copy their inputs into a structure and pass that back to the state
> tracker.  Why are we doing that?  The state tracker already knows what
> it asked us to do, and there is no reason to assume that it needs us
> to re-present that information back to it.

Yes, only the CSOs don't have this form of copying: all other
structures include the input parameters there.

As a random example pipe_sampler_view has the lots of parameters that
a driver would have converter into the hardware format and are thus
redundant, and unlikely to be read by state tracker.

Textures and buffers also have many visible data members that the
state tracker may or may not read.
In particular, the Mesa state tracker already keeps everything in the
Mesa internal structures, and so benefits little from such data

We may want to consider going toward making _all_ Gallium structures
opaque (and, by the way, using declared-only structs instead of void*
like we do for CSOs, which are not checkable by the compiler).


Another serious data duplication issue are drivers that just copy the
input state in internal structures and return, to then process
everything in draw calls.

This usually results in state being duplicated (and copied) 3 times:
in Mesa internal structures, in the state tracker structures and then
in the driver.
The draw module may also keep a 4th copy of the state.
Note that when reference counting is involved, copies are even more
expensive since they now need atomic operations.

Usually drivers do this because:
1. They need to pass data to the draw module in case of fallbacks, and
thus cannot send it to hardware and forget about it
2. They need to recreate the whole hardware context state in some cases
3. They multiplex multiple pipe_contexts on a single screen
4. They need a global view of state, rather than a single state change
at a time, to decide what to do

A possible solution is to remove all set_* and bind_* calls and
replace them with data members of pipe_context that the state tracker
would use instead of its own internal structures.

In addition, and a new "what's new" bitmask would be added, and the
driver would check it on draw calls.

Performance-wise, this replaces num_state_changes dynamic function
calls to the driver, with (log2(total_states) + num_state_changes)
branches to check the "what's new" bitmask.

Furthermore:
1. State is never copied, since the state tracker constructs it in place
2. There is no longer any need for "state save helper" in the blitter
module and similar
3. The draw module can potentially directly read state from
pipe_context instead of duplicating it yet a
4. Drivers no longer need to have all the functions that store the
parameters, set a dirty flag and return

Note that the Direct3D DDI does not do this, but they have to keep
binary compatibility, which is easier with Set* calls than this
scheme.

softpipe, nvfx, nv50, r300 and probably others already do this
internally, and having the state tracker itself construct the data
would remove a lot of redundant copying code and increase performance.

Having drivers capable of doing "send-to-hardware-and-forget-about-it"
on arbitrary state setting could be a nice thing instead, but
unfortunately a lot of hardware fundamentally can't do this, since for
instance:
1. Shaders need to be all seen to be linked, possibly modifying the
shaders themselves (nv30)
2. Constants need to be written directly into the fragment program (nv30-nv40)
3. Fragment programs depend on the viewport to implement
fragment.position (r300)
4. Fragment programs depend on bound textures to specify normalization
type and emulate NPOT (r300, r600?, nv30)
and so on...
5. Sometimes sampler state and textures must be seen together since
the hardware mixes it


> The only really new information provided by the driver to the state
> tracker by transfer_create + transfer_map is:
> - the pointer to the data
> - stride
> - slice stride

There is also the 3D box, unless transfers start covering the whole
resource, which seems really suboptimal for stuff like glTexSubImage.

This needs to be provided to the driver unless a buffer-specialized
interface is made (then a 1D box is enough).


> Thanks for the summary.  I'd add that there is also some information
> available publicly about the D3D10 DDI, which follows a slightly
> different interface to the API.  In that world, there is a single
> create resource function:

It is indeed extremely interesting, and it looks like it should be the
first place to look for inspiration for Gallium interface.

I added a comparison of the D3D11 DDI and Gallium to src/gallium/docs.

> There is however clearly concern about the possible need for
> specialized transfer mechanisms for particular buffer types.  It seems
> like they've taken an approach that leaves the choice to the driver
> whether to specialize or not -- basically there are a number of
> specialized map/unmap entrypoints, but all with the same function
> prototype so that a driver could if it wanted to point them all to a
> single generic implementation, or if it preferred, provide specialized
> implementations for some of them.  There is some discussion of these
> choices in the page below:

Yes, indeed; not sure why they do it though since the user-visible API
appears to be unified.

> I'm really keen to get gallium-resources merged - probably combined
> with the buffer_usage_cleanup branch.  I suspect there are some
> lingering bugs in -resources that are addressed by the cleanup branch.
>  Have you had a chance to do any testing of the changes I made on
> -resources or -cleanup?

I added a commit to fix nvfx and make nv50 compile on
gallium-resources; some of the remaining issues seem to be addressed
by buffer-usage-cleanup.
It may be useful to merge gallium-resources into -cleanup again so the
latest fixes there are picked up.

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[sean d. <sea...@gm...>]

Jesse Barnes wrote:
> On Thu, 4 Mar 2010 15:20:46 -0800
> Jesse Barnes <jb...@vi...> wrote:
> 
>> On Fri, 05 Mar 2010 00:16:45 +0100
>> Michel Dänzer <mi...@da...> wrote:
>>
>>> On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: 
>>>> Jesse Barnes wrote:
>>>>> Would anyone have objections if these lists moved to freedesktop.org?
>>>>> The recent thread with Linus about the drm pull request highlights the
>>>>> post lag and non-subscriber aspect of the current lists, and that
>>>>> leaves aside sf.net's horrible mail archive interface and poor
>>>>> performance.
>>>>>
>>>>> If spam is an issue, another option would be vger.kernel.org.  That
>>>>> team runs lkml and several other very high traffic, high profile lists
>>>>> and manages quite well; performance is always high and spam is nearly
>>>>> non-existent given the amount of traffic.
>>>> Jesse, can you set up the new lists?  Or does someone else need to do 
>>>> that?
>>>>
>>>> I can send you (or whoever) the current subscriber lists.
>>> Ditto for dri-devel.
>>>
>>>> BTW, I'm the current admin for the Mesa lists on SourceForge.  I 
>>>> manually unsubscribe people who can't figure it out for themselves, 
>>>> allow posts from non-members (sometimes), etc.  I'd gladly pass on 
>>>> that responsibility to someone else.  Would that automatically become 
>>>> the job of the current fd.o admins?
>>> Not really, the lists should still have their own admins.
>>>
>>> I've been going through the moderation queues for both lists on a daily
>>> basis and am volunteering to continue doing so, but other than that I'm
>>> not really keen on being a list admin.
>> I don't have access to create the new lists, but Daniel or Tollef
>> should.
>>
>> We may as well keep you guys as admins unless someone volunteers that
>> you're ok with; but hopefully FDO will make the admin job a little
>> easier/faster.
> 
> Brian and Michel, did you guys get what you need to move the lists?
> AFAIK Tollef created them, you just need to copy the subscriber lists
> over and announce it I think?
> 
> Thanks,

If you are going to move the lists, could someone remember to put them 
on gmane. At least some of us prefer the newsgroup format.

sean

[Mesa3d-dev] [Bug 27300] [r300g] Oolite fragment shaders are too big for r3xx

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

http://bugs.freedesktop.org/show_bug.cgi?id=27300


Corbin Simpson <Mos...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|r300_fs.c:209:              |[r300g] Oolite fragment
                   |r300_translate_fragment_shad|shaders are too big for r3xx
                   |er: Assertion `0' failed.   |




--- Comment #6 from Corbin Simpson <Mos...@gm...>  2010-03-27 14:08:20 PST ---
I won't be able to reproduce exactly, without finding one of my older cards.
Also oolite appears to refuse to enable fancy shaders. :T

Basically, the shader is too big for the hardware. There's no obvious
optimizations to be done, but I bet I could find some, if the shader is known
to work on fglrx.

I've pushed a patch to make it so that you get an error message instead of just
an empty assertion.


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

[Mesa3d-dev] [Bug 24942] r300g: R300 Gallium SW TCL

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

http://bugs.freedesktop.org/show_bug.cgi?id=24942


Corbin Simpson <Mos...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|mesa3d-                     |Mos...@gm...
                   |de...@li...   |
             Status|ASSIGNED                    |NEW




--- Comment #3 from Corbin Simpson <Mos...@gm...>  2010-03-27 13:19:12 PST ---
It technically runs, but any complex pipeline app (e.g. glxgears) misrenders.
Gonna keep hacking on it.


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

[Mesa3d-dev] [Bug 21997] [gallium-mesa-7.4] Add tex_transfer to pipe_screen in order to speed up glreadpixels

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

http://bugs.freedesktop.org/show_bug.cgi?id=21997


Corbin Simpson <Mos...@gm...> changed:

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




--- Comment #4 from Corbin Simpson <Mos...@gm...>  2010-03-27 12:52:51 PST ---
Closing. We've reworked transfers, and things seem to work well.


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

Re: [Mesa3d-dev] Rationale of gallium-resources changes?

[Keith W. <kei...@go...>]

On Wed, Mar 24, 2010 at 9:20 PM, Luca Barbieri <lu...@lu...> wrote:
> Thanks for providing a long insightful reply.
>
>>> Transfers can then be split in "texture transfers" and "buffer transfers".
>>> Note that they are often inherently different, since one often uses
>>> memcpy-like GPU functionality, and the other often uses 2D blitter or
>>> 3D engine functionality (and needs to worry about swizzling or tiling)
>>> Thus, they are probably better split and not unified.
>>
>> My experience is that there is more in common than different about the
>> paths.  There are the same set of constraints about not wanting to
>> stall the GPU by mapping the underlying storage directly if it is
>> still in flight, and allocating a dma buffer for the upload if it is.
>> There will always be some differences, but probably no more than the
>> differences between uploading to eg a constant buffer and a vertex
>> buffer, or uploading to a swizzled and linear texture.
>
> The considerations you mentioned are indeed common between buffers and
> textures, but the actual mechanisms for performing the copy are often
> significantly different.
>
> For instance, r300g ends up calling the 3D engine via
> surface_copy->util_blitter for texture transfers, which I suppose it
> wouldn't do for buffer transfers.
>
> nv30/nv40 don't have a single way to deal with swizzled textures, and
> the driver must choose between many paths depending on whether  the
> source/destination is swizzled or not, a 3D texture or not, and even
> its alignment or pitch (the current driver doesn't do fully that, and
> is partially broken for this reason).
> Buffers can instead be copied very simply with MEMORY_TO_MEMORY_FORMAT.
>
> nv50 does indeed have a common copy functionality that can handle all
> buffers and textures in a unified way (implemented as a revamped
> MEMORY_TO_MEMORY_FORMAT).
> However, an additional buffer-only path would surely be faster than
> going through the common texture path.
> In particular, for buffers tile_flags are always 0 and height is
> always 1, allowing to write a significantly simplified buffer-only
> version of nv50_transfer_rect_m2mf with no branches and no
> multiplications at all.
>
> In other words, I think most drivers would be better off implementing
> unified transfers with an "if" switching between a buffer and a
> texture path, so it may be worth using two interfaces.
>
> Also note that a buffer-only interface is significantly simplified
> since you don't need to specify:
> - face
> - level
> - zslice
> - y
> - height
> - z
> - depth
> - stride
> - slice stride
>
> While this may seem a micro-optimization, note that 3D applications
> often spend all the time running the OpenGL driver and Mesa/Gallium
> functions are already too heavy in profiles, so I think it's important
> to always keep CPU performance in mind.
>
> The code is also streamlined and easier to follow if it does not have
> to default-initialize a lot of stuff.
>
> An utility function calling the right interface can be created for
> state trackers that really need it (maybe Direct3D10, if the driver
> interface follows the user API).

I take your point, though I should point out you've double-counted z
and zslice, and face+level are one dword.

To me this speaks to another aspect of the gallium interface which is
a bit odd -- in particular the way several of our interfaces basically
copy their inputs into a structure and pass that back to the state
tracker.  Why are we doing that?  The state tracker already knows what
it asked us to do, and there is no reason to assume that it needs us
to re-present that information back to it.

The only really new information provided by the driver to the state
tracker by transfer_create + transfer_map is:
- the pointer to the data
- stride
- slice stride

If the transfer functions ended up just passing this data back, it
would reduce the overhead across the board.

Your point is still valid that the last two will be zero for buffer
transfers, though.

>
>> In DX they have
>> different nomenclature for this - the graphics API level entities are
>> resources and the underlying VMM buffers are labelled as allocations.
>> In gallium, we're exposing the resource concept, but allocations are
>> driver-internal entities, usually called winsys_buffers, or some
>> similar name.
>
> D3D10 uses buffers, sampler views and render target views as entities
> bindable to the pipeline, and the latter are constructed over either
> textures or buffers.
> Note however, that the "description structure" is actually different
> in the buffer and texture cases.
>
> For render target views, they are respectively D3D10_BUFFER_RTV and
> D3D10_TEX2D_RTV (and others for other texture types).
> The first specifies an offset and stride, while the second specifies a
> mipmap level.
> Other views have similar behavior.

> Buffers are directly used in the interfaces that allow binding
> vertex/index/constant buffers.
>
> Both buffers and textures are subclasses of ID3D10Resource, which is
> used by CopyResource, CopySubresourceRegion and UpdateSubresource,
> which provide a subset of the Gallium transfer functionality in
> gallium-resources.
>
> Note however that the two resources specified to CopyResource and
> CopySubresourceRegion must be of the same type.
>
> So in summary, D3D10 does indeed in some sense go in the
> buffer/texture unification, but with some important differences:
> 1. Buffers and textures still exists as separate types. Note that
> there is no "texture" type, but rather a separate interface for each
> texture type, which directly inherits from ID3D10Resource
> 2. Textures are never used directly by the pipeline, but rather
> through "views" which have texture-type-specific creation methods and
> have separate interfaces
> 3. Buffers are directly used by the pipeline for vertex, index and
> constant buffers
> 4. Resources are used in copying and transfer functionality
> 5. D3D10 has a more memory-centric view of resources, providing for
> instance a D3D10_USAGE_STAGING flag, for "A resource that supports
> data transfer (copy) from the GPU to the CPU."
>
> D3D11 seems to be unchanged in this respect.
>
> So, if we want to go on a DX10-like route, how about:
> 1. Keeping pipe_buffer and pipe_texture, perhaps with a "pipe_resource
> base;" field
> 2. Considering splitting pipe_texture into pipe_texture_2d,
> pipe_texture_3d, pipe_texture_2d_array, etc.
> 3. Adding render target views and depth/stencil views, and making
> those constructible over buffers
> 4. Having equivalent transfer mechanisms for buffers and textures, but
> not necessarily unified in a single function
> 5. Eliminating the concept of pipe_surface, in favor of render target
> views and explicit subresources in transfer functionality
>
> D3D10/11 do not provide a transfer concept, but rather only
> inline_write/copy mechanisms.
> They also provide D3D10_USAGE_STAGING resources, which can be used as
> transfers with explicit copy operations.
> Resource copying/updating functionality is indeed unified between
> buffers and textures (using a "box" structure like gallium-resources
> does).
>
> As for the transfer unification, it seems to me they are better kept
> split, following OpenGL, but it may indeed not be clear without more
> driver experience.
>
> A possible middle ground, given the current status of
> gallium-resources, could be to keep buffer-specific and
> texture-specific utility functions for state trackers calling a common
> interface, and using them where possible.
>
> If it turns out that we are very often communicating between a
> buffer/texture-specific state tracker interface and a
> buffer/texture-specific driver code (using the vtbl utilities), using
> an inefficient common interface, it is then easy to directly bridge
> them later by splitting the Gallium interface.
>
> Also, once we have drivers actually supporting efficient memory
> management (as opposed to the current situation where Radeon and
> GeForce drivers directly use kernel buffer objects, with terrible
> performance, and often not paying attention to uncached memory issues,
> especially for buffers), it may also be clearer whether transfers are
> a good interface, or should be replaced with user/"staging" buffers
> and user/"staging" textures with copies (like D3D10 does with
> D3D10_USAGE_STAGING)
>

Luca,

Thanks for the summary.  I'd add that there is also some information
available publicly about the D3D10 DDI, which follows a slightly
different interface to the API.  In that world, there is a single
create resource function:

http://msdn.microsoft.com/en-us/library/aa478785.aspx

and most functions with texture or buffer arguments are provided with
Resource handles, eg:

http://msdn.microsoft.com/en-us/library/aa478810.aspx

There is however clearly concern about the possible need for
specialized transfer mechanisms for particular buffer types.  It seems
like they've taken an approach that leaves the choice to the driver
whether to specialize or not -- basically there are a number of
specialized map/unmap entrypoints, but all with the same function
prototype so that a driver could if it wanted to point them all to a
single generic implementation, or if it preferred, provide specialized
implementations for some of them.  There is some discussion of these
choices in the page below:

http://msdn.microsoft.com/en-us/library/aa478736.aspx

In terms of moving forward, I think your proposed middle ground is a
valid approach.  I don't view gallium-resources as the final word on
the subject, but rather a big step in the right direction in
particular to clean up the confusion over what a pipe_buffer really is
and what it is not, and to nudge drivers towards thinking about
asynchronous transfers for buffers and textures as being variations on
a common theme, rather than fundamentally disjoint operations.

I'm really keen to get gallium-resources merged - probably combined
with the buffer_usage_cleanup branch.  I suspect there are some
lingering bugs in -resources that are addressed by the cleanup branch.
 Have you had a chance to do any testing of the changes I made on
-resources or -cleanup?

Keith

[Mesa3d-dev] [Bug 24226] libGL tries using direct mode when it should use indirect (only tries indirect if forced)

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

http://bugs.freedesktop.org/show_bug.cgi?id=24226





--- Comment #15 from George Sapountzis <gsa...@gm...>  2010-03-27 05:56:07 PST ---
(In reply to comment #14)
> The question is, when libGL.so is compiled with direct rendering support, how
> to decide if direct rendering is viable at runtime?  The connection to xserver
> may be remote or local.  The configs from xserver and dri driver may or may not
> match.  How do they affect the decision?
> 

I don't think there is a simple way to decide. One way to answer this is to
change glxext.c from:

   if (glx_direct)
      dpyPriv->driswDisplay = driswCreateDisplay(dpy);

to:

   if (glx_direct && !glx_accel)
      dpyPriv->driswDisplay = driswCreateDisplay(dpy);

and see if people complain :-(

It will mainly affect developers who usually explicitly set
LIBGL_ALWAYS_SOFTWARE. Also wiki's won't have to be updated because they
usually instruct people to set the envvar.


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

[Mesa3d-dev] [Bug 17659] driver_configs never deallocated

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

http://bugs.freedesktop.org/show_bug.cgi?id=17659





--- Comment #1 from George Sapountzis <gsa...@gm...>  2010-03-27 05:49:45 PST ---
(In reply to comment #0)
> Created an attachment (id=19010)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=19010) [details]
> half-hearted demo patch which makes valgrind shutup
> 
> in src/glx/x11/drisw_glx.c 
> 
> const __DRIconfig **driver_configs;
> 
> psc->swrast->createNewScreen(screen,
>     loader_extensions, &driver_configs, psc);
> 
> allocates space for the driver_configs which never get released afaics
> 

You are right that they are not freed. The problem exists for actual DRI
drivers also and for other loaders (xserver/glx ...).

So unless the configs are used by the loader after screen destruction time, I
think that they should be freed by the common dri code under
src/mesa/drivers/dri/common in the .DestroyScreen hook.


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

[Mesa3d-dev] [Bug 5840] Mesa does not remove no-op state changes occuring outside rendering commands

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

http://bugs.freedesktop.org/show_bug.cgi?id=5840


Corbin Simpson <Mos...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #4 from Corbin Simpson <Mos...@gm...>  2010-03-27 04:40:14 PST ---
Between Gallium and the planned GL 3.x support not depending on Mesa, I'd say
that this isn't really a serious problem anymore, but feel free to re-open if
you think I'm being a tool.


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

[Mesa3d-dev] [Bug 4860] Software rasterizer polygon offset problem

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

http://bugs.freedesktop.org/show_bug.cgi?id=4860


Corbin Simpson <Mos...@gm...> changed:

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




--- Comment #1 from Corbin Simpson <Mos...@gm...>  2010-03-27 04:29:57 PST ---
I think all the software rasterizers pass the relevant piglit tests, don't
they? If not, we can re-open and track from here.


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

[Mesa3d-dev] [PATCH] Fix deadlock: _mesa_HashFindFreeKeyBlock has already locked the table.

[Török E. <edw...@gm...>]

This fixes fdo bug 34502.

Signed-off-by: Török Edvin <edw...@gm...>
---
 src/mesa/main/hash.c |   19 +++++++++++++------
 1 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index 9757754..e9a9748 100644
--- a/src/mesa/main/hash.c
+++ b/src/mesa/main/hash.c
@@ -127,8 +127,8 @@ _mesa_DeleteHashTable(struct _mesa_HashTable *table)
  * 
  * \return pointer to user's data or NULL if key not in table
  */
-void *
-_mesa_HashLookup(struct _mesa_HashTable *table, GLuint key)
+static inline void *
+_mesa_HashLookup_unlocked(struct _mesa_HashTable *table, GLuint key)
 {
    GLuint pos;
    const struct HashEntry *entry;
@@ -137,19 +137,26 @@ _mesa_HashLookup(struct _mesa_HashTable *table, GLuint key)
    assert(key);
 
    pos = HASH_FUNC(key);
-   _glthread_LOCK_MUTEX(table->Mutex);
    entry = table->Table[pos];
    while (entry) {
       if (entry->Key == key) {
-         _glthread_UNLOCK_MUTEX(table->Mutex);
          return entry->Data;
       }
       entry = entry->Next;
    }
-   _glthread_UNLOCK_MUTEX(table->Mutex);
    return NULL;
 }
 
+void *
+_mesa_HashLookup(struct _mesa_HashTable *table, GLuint key)
+{
+   void *res;
+   assert(table);
+   _glthread_LOCK_MUTEX(table->Mutex);
+   res = _mesa_HashLookup_unlocked(table, key);
+   _glthread_UNLOCK_MUTEX(table->Mutex);
+   return res;
+}
 
 
 /**
@@ -447,7 +454,7 @@ _mesa_HashFindFreeKeyBlock(struct _mesa_HashTable *table, GLuint numKeys)
       GLuint freeStart = 1;
       GLuint key;
       for (key = 1; key != maxKey; key++) {
-	 if (_mesa_HashLookup(table, key)) {
+	 if (_mesa_HashLookup_unlocked(table, key)) {
 	    /* darn, this key is already in use */
 	    freeCount = 0;
 	    freeStart = key+1;
-- 
1.7.0

[Mesa3d-dev] [Bug 27017] swrast not working correctly - point-wide trivial

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

http://bugs.freedesktop.org/show_bug.cgi?id=27017


Andrew Randrianasulu <ra...@ma...> changed:

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




--- Comment #4 from Andrew Randrianasulu <ra...@ma...>  2010-03-27 02:07:56 PST ---
Fixed in current mesa, probably by commit
7996f0fc2c167c84552701be7a48d20a897e7978 ( dri/swrast: Fix frontbuffer
rendering )

Tested on x86 machine, i'll fire up my SGI O2 soon and test swrast there also.


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

[Mesa3d-dev] [Bug 27018] swrast not working correctly - samples/stencil

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

http://bugs.freedesktop.org/show_bug.cgi?id=27018


Andrew Randrianasulu <ra...@ma...> changed:

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




--- Comment #7 from Andrew Randrianasulu <ra...@ma...>  2010-03-27 02:05:23 PST ---
(In reply to comment #6)
> Looks like the issue is related to single buffer rendering.
> 
> Some of the tests take a -db flag to turn on double buffering.  point-wide
> looks OK with that flag.
> 
> Hopefully someone else can look into this.
> 

I think  this one is fixed, probably by 

commit 7996f0fc2c167c84552701be7a48d20a897e7978
    dri/swrast: Fix frontbuffer rendering.

-------

currently tested on x86, with mesa git master up to 
commit c8844c5549dec7e9c47ab49d6e229980f62da74d
    r300g: Make SWTCL clear work again.


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

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

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

On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
> 
> From the driver point of view, we don't have to work on the GLSL compiler
> itself. The Mesa state tracker compiles GLSL to an assembler-like language
> called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader
> representation. The more TGSI we handle, the more GLSL support we get.
> 
> So now the status. r300g GLSL is missing the following features:
> 
> 1) Branching and looping
> 
> This is the most important one and there are 3 things which need to be done.
> * Unrolling loops and converting conditionals to multiplications. This is
> crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases
> but should be fine for the most common ones. This is kind of a standard in
> all proprietary drivers supporting shaders 2.0. It would be nice have it
> work with pure TGSI shaders so that drivers like nvfx can reuse it too and I
> personally prefer to have this feature first before going on.
> * Teaching the R300 compiler loops and conditionals for R500 fragment
> shaders. Note that R500 supports the jump instruction so besides adding new
> opcodes, the compiler optimization passes should be updated too (I think
> they haven't been designed with loops in mind).
> * The same but for R500 vertex shaders. The difference is conditionals must
> be implemented using predication opcodes and predication writes (stuff gets
> masked out). I think this only affects the conversion to machine code at the
> end of the pipeline.
> 
> 2) Derivatives instructions fix
> 
> It's implemented but broken. From docs: "If src0 is computed in the previous
> instruction, then a NOP needs to be inserted between the two instructions.
> Do this by setting the NOP flag in the previous instruction. This is not
> required if the previous instruction is a texture lookup." .. and that
> should be the fix.
> 
> 3) Perspective, flat, and centroid varying modifiers, gl_FrontFacing
> 
> I think this is specific to the rasterizer (RS) block in hw ([3]).
> 
> [1] src/gallium/drivers/r300/r300_tgsi_to_rc.c
> [2] src/mesa/drivers/dri/r300/compiler/
> [3] src/gallium/drivers/r300/r300_state_derived.c
>

Thanks.  This is really helpful.

I am in the process of looking through the code and some of the
documentation.  I'll respond with some questions when I start writing
my proposal.

-Tom

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

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

On Tue, Mar 23, 2010 at 8:46 PM, Tom Stellard <tst...@gm...> wrote:

> On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote:
> > On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard <tst...@gm...>
> wrote:
> > >
> > > Thanks for the information.
> > >
> > > After spending some time learning about the Gallium driver
> architecture, I
> > > think it might be better to set a goal to implement or improve a
> specific
> > > feature of the Gallium R300 driver rather than trying to get a specific
> > > game or application to work.  Is there a feature that is currently
> missing
> > > from the R300 driver that might make a good project for the summer?
> >
> > Good question. There's a handful of things. Passing piglit might be a
> > good goal. Bumping the GL version further up, or solidifying the GLSL
> > support, might be good too.
> >
>
> I think the GLSL compiler would be an interesting project for me to work
> on.  What is the current status of GLSL on R300 cards?


>From the driver point of view, we don't have to work on the GLSL compiler
itself. The Mesa state tracker compiles GLSL to an assembler-like language
called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader
representation. The more TGSI we handle, the more GLSL support we get.

So now the status. r300g GLSL is missing the following features:

1) Branching and looping

This is the most important one and there are 3 things which need to be done.
* Unrolling loops and converting conditionals to multiplications. This is
crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases
but should be fine for the most common ones. This is kind of a standard in
all proprietary drivers supporting shaders 2.0. It would be nice have it
work with pure TGSI shaders so that drivers like nvfx can reuse it too and I
personally prefer to have this feature first before going on.
* Teaching the R300 compiler loops and conditionals for R500 fragment
shaders. Note that R500 supports the jump instruction so besides adding new
opcodes, the compiler optimization passes should be updated too (I think
they haven't been designed with loops in mind).
* The same but for R500 vertex shaders. The difference is conditionals must
be implemented using predication opcodes and predication writes (stuff gets
masked out). I think this only affects the conversion to machine code at the
end of the pipeline.

2) Derivatives instructions fix

It's implemented but broken. From docs: "If src0 is computed in the previous
instruction, then a NOP needs to be inserted between the two instructions.
Do this by setting the NOP flag in the previous instruction. This is not
required if the previous instruction is a texture lookup." .. and that
should be the fix.

3) Perspective, flat, and centroid varying modifiers, gl_FrontFacing

I think this is specific to the rasterizer (RS) block in hw ([3]).

[1] src/gallium/drivers/r300/r300_tgsi_to_rc.c
[2] src/mesa/drivers/dri/r300/compiler/
[3] src/gallium/drivers/r300/r300_state_derived.c


 Would something
> like passing a subset of the GLSL piglit tests, or being able to correctly
> handle a certain version of GLSL be a good goal for the summer?
>

I guess this question is for Corbin. ;)

-Marek

Re: [Mesa3d-dev] Build Error with Xorg State Tracker

[STEVE555 <ste...@ho...>]

Hi all,
        Sorry for the late reply.I've just tried Dan's trick and it works
very well,thank you very much for the tip.
Regards,
            STEVE555

Dan Nicholson-2 wrote:
> 
> On Wed, Mar 24, 2010 at 07:00:06AM -0700, STEVE555 wrote:
>> 
>> Dear Jakob,
>>                  I did a ./autogen.sh and Mesa builds fine now,sorry
>> about
>> that.I do run ./autogen.sh from time to time,I just thought ./configure
>> would be enough,oh well,I like to thank you for your help.
> 
> When someone makes a commit to configure.ac, the configure file has to
> be regenerated. Usually automake adds rules so that if configure.ac is
> newer than configure, it runs autoconf again. We can try to add some
> rules like that to the toplevel Makefile, but I'd like to take a look at
> the way automake does it before adding some half baked hack.
> 
> However, the takeaway is that if you're seeing build errors, you'll want
> to check that configure is up to date and that it's been run again.
> 
> Here's a handy trick for regenerating the autotools and keeping your
> configure arguments:
> 
> $ autoreconf -iv && ./config.status --recheck && ./config.status
> 
> That's pretty much a surefire way to ensure the autotools (whichever
> ones) are refreshed, and the second part runs configure again with your
> arguments you used before.
> 
> --
> Dan
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/Build-Error-with-Xorg-State-Tracker-tp28014534p28049154.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

[Mesa3d-dev] [Bug 27312] glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB

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

http://bugs.freedesktop.org/show_bug.cgi?id=27312





--- Comment #7 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-26 10:47:04 PST ---
(In reply to comment #2)
> Which driver are you using?  swrast or softpipe or other?
> 
> I could probably look into this as soon as you provide a (glut) test program.
> 

I have uploaded the source that uses egl. The LD_LIBRARY_PATH I have used is

<blah>Mesa-7.7/lib/gallium:<blah>/Mesa-7.7/lib.


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

[Mesa3d-dev] [Bug 27312] glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB

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

http://bugs.freedesktop.org/show_bug.cgi?id=27312





--- Comment #6 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-26 10:45:37 PST ---
Created an attachment (id=34496)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34496)
Makefile for building app


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