mesa3d-dev

Re: [Mesa3d-dev] Separate demos repository

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

Eric Anholt wrote:
> People that hang out on IRC have probably heard about my build system
> work.  One of the first steps I've been working on finishing is
> splitting out the demos repository.  We're currently distributing the
> Mesa progs/ separately from the main Mesa distribution, and most people
> aren't installing it, so from a distribution perspective it doesn't make
> sense to be in the same repository.  On the other hand, for driver
> developers that are having to make clean on a regular basis, wiping out
> the programs (if you even use them) doesn't help since the programs
> aren't really changing.  And if they are, when you're bisecting around
> trying an app, you don't want the app changing at the same time.
> 
> So, I've made a branch in my Mesa repository for a split of the progs/
>>From Mesa.
> 
> git://people.freedesktop.org/~anholt/mesa on the mesa-demos branch
> 
> Open issues:
> 
> Right now they don't install in general, but it would be easy to change
> if people are interested in a package that does.  I've tested a bunch of
> them in tree and they seem fine.
> 
> I've only tested the build on Linux with GL.  The GLES stuff needs to
> get hooked up (I don't see a GLES implementation to test against or I
> would have).
> 
> I don't know what to do about the progs/gallium.  progs/gallium/unit
> looks like it should probably live in the Mesa tree next to the code
> that it's unit testing.  progs/gallium/python/ though?
> 
> None of the GLEW or GLUT is brought along with the apps.  It looks to me
> like all OSes should have libGLEW and libfreeglut reasonably available.
> 
> I'm not sure if we want the repository to contain all of previous Mesa
> history.  Right now that history costs 145MB on disk for a deep
> checkout.  If that's a problem for people, we could use the same tool
> that xcb did whose name I forget to to construct a history of just
> progs/
> 
> Where to go from here:
> 
> If there isn't violent objection to this, I want to get this into place
> in /git/mesa/demos in a couple of weeks, and then remove those
> components from the main Mesa repository, plus the things that are only
> in there because progs depend on them (GLUT, GLEW).

In general I'm ok with putting the demos in a separate repo.

I probably won't have time to look at your branch for a week or two 
though.

I definitely want to keep the Mesa/Kilgard version of GLUT around. 
freeglut behaves differently than Mesa's GLUT in a few ways.  I still 
don't trust the former as much as the later.  It only takes a 
miniscule amount of space and builds in 2-3 seconds.

We need to go through the progs/tests and see which are unit tests 
better suited to living with Mesa rather than a separate demo repo.

Maybe Chia-I Wu can help out with the OpenGL ES / Open VG programs.

I'd appreciate it if you'd hold off on any changes for a little while 
longer.  Thanks.

-Brian

Re: [Mesa3d-dev] [RFC] Draw module patch and BGRA fix for i915g

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

Jakob Bornecrantz wrote:
> Hi Brian, Keith, Zack et al.
> 
> So I tried to get i915g running again and it looks like there is a
> RGBA vs BGRA bug in the draw module. I have attached two patches that
> I would like to have some comments on before commit.
> 
> Patch 1 removes a bunch of switch cases that was strew all over the
> draw module that all pretty much did exactly the same thing. Which
> made it hard to fix the RGBA issue for i915g. In draw_pipe_vbuf and
> draw_pt_emit the format for EMIT_4UB was one thing and in
> draw_pt_fetch_emit it was another. In light of the format clean up I
> standardized on following the same as the float formats for EMIT_4UB.
> 
> Patch 2 then introduces EMIT_4UB_BGRA and is used by i915g to make the
> colors look correct again.
> 
> Comments please.
> 
> Cheers Jakob.
> 


The new translsation function:

static INLINE unsigned draw_translate_vinfo_format_size(unsigned format)

and the existing:

static INLINE unsigned draw_translate_vinfo_format(unsigned format )

should probably both take a 'enum attrib_emit' instead of unsigned int.

Also, the default switch cases should probably have an assert(0 && 
"unexpected format") in case someone were to add a new format value 
but forget to update the helper functions.

Looks good otherwise.

-Brian

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

[George S. <gsa...@gm...>]

On Thu, Mar 25, 2010 at 9:49 PM, Jakob Bornecrantz <wal...@gm...> wrote:
> On Thu, Mar 25, 2010 at 7:00 PM, George Sapountzis
> <gsa...@gm...> wrote:
>> On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz <wal...@gm...> wrote:
>>> 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet
>>> again for clarity.
>>>
>>> 0004 moves the common files into a common directory.
>>>
>>
>> I think that it may be better to just consolidate dri_screen.c /
>> dri_context.c / dri_drawable.c / dri_extension.c in a single file
>> named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib
>> state_tracker. There is not much left in the above files after
>> splitting out version-specific code.
>>
>> Then you will have:
>> dri_api.c or dri_driver_api.c for the DRI "window system" binding
>> dri_st_api.c
>> and
>> dri1.c dri2.c drisw.c for the different versions
>>
>> the only outlier is dri1_helper which I agree may have a better name.
>>
>> But then I looked at this a lot lately and your suggestion may be
>> better for someone looking at it after some time.
>
> I think you can do both, the moving of the files is more for making it
> blatantly clear what is going on. The common files live in the common
> directory and the rest are in their own directory. This mirrors what
> is done in egl.
>
> I'm ambivalent about grouping the files together. And I don't think
> that moving them it a common directory stops us from doing either one.
> Then again dri_extension.c is quite useless, and should probably be
> moved into dri_screen either way.
>
> Are you strongly against the layout that I suggested? I have no real
> problem with doing both?
>

Ah ok, then the suggested layout serves well its purpose. Wrt to
consilidating in dri_driver_api.c (dri_util.c is effectively
dri_api.c), it depends on what your plans are for st/dri and if it
involves adding more common code, I don't have other plans for st/dri
:-)

I'll add a comment about the ifdef's (srceen / swap_buffers in
dri_screen.c, flush_front / alloc_buffers in dri_st_api.c) and to
drisw_util.h about its relationship to dri_util.h .

>>
>>> One thing that could be done to reduce the amount of #ifdefs would be
>>> to move the tables from dri_screen.c into drisw.c and dri2.c.
>>
>> yes, this could be done unless the suggestion above is adopted, in
>> which case I thinks it's probably better to keep all the dri_
>> functions static and the _DriverAPI tables in the common file.
>
> There is only one function that is static that is used in the tables,
> or are you meaning that we should make them static as we move all of
> them into a single file?
>

yes, if we move them all to dri_driver_api.c then it makes more sense
to make them static and keep _DriverAPI in dri_driver_api.c with an
ifdef.

Re: [Mesa3d-dev] [PATCH] Re: master: undef/unmangled EGL functions are part of libOSMesa

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

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

tom fogal wrote:
> Brian Paul <br...@vm...> writes:
>> Tom wrote:
>>>> tom fogal wrote:
>>>>>   $ lib nm libOSMesa.so | grep "EGL"
>>>>>                    U glEGLImageTargetRenderbufferStorageOES
>>>>>                    U glEGLImageTargetTexture2DOES
>>>>>
>>>>> this prevents using libOSMesa, since one gets link errors about the
>>>>> symbol.
>>> Regenerating gl_mangle.h was all that was needed.  Thanks for the hint,
>> I've committed the regenerated file.
> 
> This needed application to 7.8 as well.  I generated the patch again on
> top of 7.8's HEAD, though I think it's the same.
> 
> My commit bit went through.  Symbol mangling updates seem trivial and
> recurring; can I just commit them?

That should be fine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkur6jkACgkQX1gOwKyEAw949gCeLAmCk6eQLPRMz2XFgD3JRHxW
igcAnjBmI3WTsdpU1DUv/95R/iGc8u95
=pYK9
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [PATCH] Re: master: undef/unmangled EGL functions are part of libOSMesa

[tom f. <tf...@al...>]

Brian Paul <br...@vm...> writes:
> Tom wrote:
> > > tom fogal wrote:
> > > >   $ lib nm libOSMesa.so | grep "EGL"
> > > >                    U glEGLImageTargetRenderbufferStorageOES
> > > >                    U glEGLImageTargetTexture2DOES
> > > >
> > > > this prevents using libOSMesa, since one gets link errors about the
> > > > symbol.
> > 
> > Regenerating gl_mangle.h was all that was needed.  Thanks for the hint,
> 
> I've committed the regenerated file.

This needed application to 7.8 as well.  I generated the patch again on
top of 7.8's HEAD, though I think it's the same.

My commit bit went through.  Symbol mangling updates seem trivial and
recurring; can I just commit them?

-tom

[Mesa3d-dev] [RFC] Draw module patch and BGRA fix for i915g

[Jakob B. <wal...@gm...>]

Hi Brian, Keith, Zack et al.

So I tried to get i915g running again and it looks like there is a
RGBA vs BGRA bug in the draw module. I have attached two patches that
I would like to have some comments on before commit.

Patch 1 removes a bunch of switch cases that was strew all over the
draw module that all pretty much did exactly the same thing. Which
made it hard to fix the RGBA issue for i915g. In draw_pipe_vbuf and
draw_pt_emit the format for EMIT_4UB was one thing and in
draw_pt_fetch_emit it was another. In light of the format clean up I
standardized on following the same as the float formats for EMIT_4UB.

Patch 2 then introduces EMIT_4UB_BGRA and is used by i915g to make the
colors look correct again.

Comments please.

Cheers Jakob.

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

[Jakob B. <wal...@gm...>]

On Thu, Mar 25, 2010 at 7:00 PM, George Sapountzis
<gsa...@gm...> wrote:
> On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz <wal...@gm...> wrote:
>> On Thu, Mar 25, 2010 at 3:12 PM, George Sapountzis
>> <gsa...@gm...> wrote:
>>> I pushed this to master, swrastg_dri was added to the autoconf build
>>> system only.
>>>
>>> I also did a merge with gallium-resources for st/dri at
>>> ~gsap7/gallium-resources-merge-drisw, it basically reverts the old
>>> conversion, merges and redoes the conversion because there were a lot
>>> of conflicts, hope this is ok.
>>
>> Hi George,
>>
>> Let me first of say that despite my negative tone in the following
>> text I do really like what you have done, thanks for figuring it out
>> and doing the work.
>>
>> I really don't like the way you reuse the dri state tracker file to
>> produce two different o file form the same c file. Magic defines on
>> the build line that make the c file take different paths make the code
>> harder to read and there is a big chance that some paths just bit rot.
>> However to does seems to be very limited. And I also realize that the
>> is no way around it due to the fact that you have to work against two
>> different dri_util.h files and as such two different dri interfaces.
>>
>
> I agree it's not pretty either. It's basically like having different
> CFLAGS for multiple .la's in automake. It's "limited" to init_screen,
> flush_front/swap_buffers/alloc_buffers which is exactly where the DRI
> versions are pretty different.
>

Yeah its not as bad as it could be, and there really isn't any way
around it with regard to that drisw_util.h vs dri_util.h.

>
>> I have attached 4 patches that I like to run by you before pushing.
>> 0001 is rather trivial and is just a code cleanup that adds dri2
>> prefix for functions that are in the dri2.c file. 0002 just removes
>> the drisw.h from the drm build and dri[1|2].h from the sw build, just
>> to be extra sure we don't use the wrong functions in the wrong place
>> (you get a build time warning plus a link error, instead of just a
>> link error).
>>
>
> These look good.

Cool I'll push those.

>
>> 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet
>> again for clarity.
>>
>> 0004 moves the common files into a common directory.
>>
>
> I think that it may be better to just consolidate dri_screen.c /
> dri_context.c / dri_drawable.c / dri_extension.c in a single file
> named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib
> state_tracker. There is not much left in the above files after
> splitting out version-specific code.
>
> Then you will have:
> dri_api.c or dri_driver_api.c for the DRI "window system" binding
> dri_st_api.c
> and
> dri1.c dri2.c drisw.c for the different versions
>
> the only outlier is dri1_helper which I agree may have a better name.
>
> But then I looked at this a lot lately and your suggestion may be
> better for someone looking at it after some time.

I think you can do both, the moving of the files is more for making it
blatantly clear what is going on. The common files live in the common
directory and the rest are in their own directory. This mirrors what
is done in egl.

I'm ambivalent about grouping the files together. And I don't think
that moving them it a common directory stops us from doing either one.
Then again dri_extension.c is quite useless, and should probably be
moved into dri_screen either way.

Are you strongly against the layout that I suggested? I have no real
problem with doing both?

>
>> One thing that could be done to reduce the amount of #ifdefs would be
>> to move the tables from dri_screen.c into drisw.c and dri2.c.
>
> yes, this could be done unless the suggestion above is adopted, in
> which case I thinks it's probably better to keep all the dri_
> functions static and the _DriverAPI tables in the common file.

There is only one function that is static that is used in the tables,
or are you meaning that we should make them static as we move all of
them into a single file?

>
>> And
>> create a "virtual" function on the screen for flush_frontbuffer
>> alloc_texture and so on.
>>
>
> This vtbl already exists, it's the st_framebuffer_iface. However you
> implement this, I think you would end up with either an ifdef or
> having the same symbol in the different DRI version files, I don't
> know which is better.

Ah yes double vtable, hmm, well anyways its not that invasive.

>
> Thanks for looking at the patches,

No problems, thanks for looking at mine :)

Cheers Jakob.

Re: [Mesa3d-dev] [RFC] gallium-targets merge

[Jakob B. <wal...@gm...>]

On Thu, Mar 25, 2010 at 7:06 PM, Xavier Chantry
<cha...@gm...> wrote:
> On Thu, Mar 25, 2010 at 6:35 PM, Jakob Bornecrantz <wal...@gm...> wrote:
>>
>> Thanks for testing...
>>
>> Hmm I currently only checking for if the --enable-egl switch has been
>> thrown when selecting so if you throw in --disable-egl in there it
>> should work again. I'll look into it.
>>
>
> Interestingly enough, the drisw work that happened right after the
> merge fails in the same way.
>
> Anyway, I already have two working options :
> 1) add egl and drisw to --with-state-trackers=glx,dri
> 2) add --disable-egl --enable-gallium-swrast=no
>
> The handling of with_state_trackers option does not seem optimal :
> - yes case :
> mesa_driver=dri -> glx state tracker
> mesa_driver=xlib -> dri state tracker
>
> so there is apparently no way to get both glx and dri
>
> - * case :
> does not check whether egl state tracker is enabled when egl is enabled
> does not check whether drisw state tracker is enabled when drisw is enabled
>
>
> But there is nothing inherently broken. So we can just assume the user
> is not stupid and will select configure options that are consistent.
> I will just go with 2), and possibly update nouveau wiki accordingly.
>

Thanks again for testing.

Okay, this could be solved by just checking if the state trackers are
built where we enable the the targets instead of the subsystem or
driver. The xorg drivers is the only one doing this correctly, by
checking HAVE_XORG.

I'll get to that later today.

Cheers Jakob.

Re: [Mesa3d-dev] [RFC] gallium-targets merge

[Xavier C. <cha...@gm...>]

On Thu, Mar 25, 2010 at 6:35 PM, Jakob Bornecrantz <wal...@gm...> wrote:
>
> Thanks for testing...
>
> Hmm I currently only checking for if the --enable-egl switch has been
> thrown when selecting so if you throw in --disable-egl in there it
> should work again. I'll look into it.
>

Interestingly enough, the drisw work that happened right after the
merge fails in the same way.

Anyway, I already have two working options :
1) add egl and drisw to --with-state-trackers=glx,dri
2) add --disable-egl --enable-gallium-swrast=no

The handling of with_state_trackers option does not seem optimal :
- yes case :
mesa_driver=dri -> glx state tracker
mesa_driver=xlib -> dri state tracker

so there is apparently no way to get both glx and dri

- * case :
does not check whether egl state tracker is enabled when egl is enabled
does not check whether drisw state tracker is enabled when drisw is enabled


But there is nothing inherently broken. So we can just assume the user
is not stupid and will select configure options that are consistent.
I will just go with 2), and possibly update nouveau wiki accordingly.

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

[George S. <gsa...@gm...>]

On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz <wal...@gm...> wrote:
> On Thu, Mar 25, 2010 at 3:12 PM, George Sapountzis
> <gsa...@gm...> wrote:
>> I pushed this to master, swrastg_dri was added to the autoconf build
>> system only.
>>
>> I also did a merge with gallium-resources for st/dri at
>> ~gsap7/gallium-resources-merge-drisw, it basically reverts the old
>> conversion, merges and redoes the conversion because there were a lot
>> of conflicts, hope this is ok.
>
> Hi George,
>
> Let me first of say that despite my negative tone in the following
> text I do really like what you have done, thanks for figuring it out
> and doing the work.
>
> I really don't like the way you reuse the dri state tracker file to
> produce two different o file form the same c file. Magic defines on
> the build line that make the c file take different paths make the code
> harder to read and there is a big chance that some paths just bit rot.
> However to does seems to be very limited. And I also realize that the
> is no way around it due to the fact that you have to work against two
> different dri_util.h files and as such two different dri interfaces.
>

I agree it's not pretty either. It's basically like having different
CFLAGS for multiple .la's in automake. It's "limited" to init_screen,
flush_front/swap_buffers/alloc_buffers which is exactly where the DRI
versions are pretty different.


> I have attached 4 patches that I like to run by you before pushing.
> 0001 is rather trivial and is just a code cleanup that adds dri2
> prefix for functions that are in the dri2.c file. 0002 just removes
> the drisw.h from the drm build and dri[1|2].h from the sw build, just
> to be extra sure we don't use the wrong functions in the wrong place
> (you get a build time warning plus a link error, instead of just a
> link error).
>

These look good.

> 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet
> again for clarity.
>
> 0004 moves the common files into a common directory.
>

I think that it may be better to just consolidate dri_screen.c /
dri_context.c / dri_drawable.c / dri_extension.c in a single file
named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib
state_tracker. There is not much left in the above files after
splitting out version-specific code.

Then you will have:
dri_api.c or dri_driver_api.c for the DRI "window system" binding
dri_st_api.c
and
dri1.c dri2.c drisw.c for the different versions

the only outlier is dri1_helper which I agree may have a better name.

But then I looked at this a lot lately and your suggestion may be
better for someone looking at it after some time.

> One thing that could be done to reduce the amount of #ifdefs would be
> to move the tables from dri_screen.c into drisw.c and dri2.c.

yes, this could be done unless the suggestion above is adopted, in
which case I thinks it's probably better to keep all the dri_
functions static and the _DriverAPI tables in the common file.

> And
> create a "virtual" function on the screen for flush_frontbuffer
> alloc_texture and so on.
>

This vtbl already exists, it's the st_framebuffer_iface. However you
implement this, I think you would end up with either an ifdef or
having the same symbol in the different DRI version files, I don't
know which is better.

Thanks for looking at the patches,
George

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

[Jakob B. <wal...@gm...>]

On Thu, Mar 25, 2010 at 3:12 PM, George Sapountzis
<gsa...@gm...> wrote:
> I pushed this to master, swrastg_dri was added to the autoconf build
> system only.
>
> I also did a merge with gallium-resources for st/dri at
> ~gsap7/gallium-resources-merge-drisw, it basically reverts the old
> conversion, merges and redoes the conversion because there were a lot
> of conflicts, hope this is ok.

Hi George,

Let me first of say that despite my negative tone in the following
text I do really like what you have done, thanks for figuring it out
and doing the work.

I really don't like the way you reuse the dri state tracker file to
produce two different o file form the same c file. Magic defines on
the build line that make the c file take different paths make the code
harder to read and there is a big chance that some paths just bit rot.
However to does seems to be very limited. And I also realize that the
is no way around it due to the fact that you have to work against two
different dri_util.h files and as such two different dri interfaces.

I have attached 4 patches that I like to run by you before pushing.
0001 is rather trivial and is just a code cleanup that adds dri2
prefix for functions that are in the dri2.c file. 0002 just removes
the drisw.h from the drm build and dri[1|2].h from the sw build, just
to be extra sure we don't use the wrong functions in the wrong place
(you get a build time warning plus a link error, instead of just a
link error).

0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet
again for clarity.

0004 moves the common files into a common directory.

One thing that could be done to reduce the amount of #ifdefs would be
to move the tables from dri_screen.c into drisw.c and dri2.c. And
create a "virtual" function on the screen for flush_frontbuffer
alloc_texture and so on.

Comments please?

Cheers Jakob.

PS: I hope I didn't sound to negative...

Re: [Mesa3d-dev] [RFC] gallium-targets merge

[Jakob B. <wal...@gm...>]

On Thu, Mar 25, 2010 at 5:30 PM, Xavier Chantry
<cha...@gm...> wrote:
> I've been using the configure line from nouveau wiki for a while now :
> http://nouveau.freedesktop.org/wiki/GalliumHowto
>
> ./configure --enable-debug --enable-glx-tls --disable-asm
> --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel
> --disable-gallium-radeon --disable-gallium-svga
> --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests
>
>        Gallium:         yes
>        Gallium dirs:    auxiliary drivers state_trackers
>        Target dirs:      dri-nouveau egl-nouveau dri-swrast egl-swrast
>        Winsys dirs:     sw sw/xlib sw/dri sw/drm nouveau/drm
>        Driver dirs:     softpipe failover trace identity nouveau nvfx nv50
>        Trackers dirs:   glx dri
>
>        Shared libs:     yes
>        Static libs:     no
>        EGL:             glx dri2
>        GLU:             yes
>        GLw:             yes (Motif: no)
>        glut:            yes
>        Demos:           no
>
> This setup broke after that last merge I think :
>
> make[3]: Entering directory
> `/home/xavier/app/mesa/src/gallium/targets/egl-nouveau'
> gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
> -fvisibility=hidden -fno-strict-aliasing -g  -fPIC   -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -D_GNU_SOURCE -DPTHREADS -DDEBUG
> -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o
> make[3]: *** No rule to make target
> `../../../../src/gallium/state_trackers/egl/libeglx11.a', needed by
> `egl_x11_nouveau.so'.  Stop.
>
> It seems egl is enabled by default, but manually specifying
> state-trackers without egl disables egl state tracker, and build
> fails.
> I am not sure why it worked before.
>
> I don't know if configure.ac should handle the above configure line
> somehow, either reporting it as invalid or enabling egl state tracker
> anyway.

Thanks for testing...

Hmm I currently only checking for if the --enable-egl switch has been
thrown when selecting so if you throw in --disable-egl in there it
should work again. I'll look into it.

Cheers Jakob.

Re: [Mesa3d-dev] [RFC] gallium-targets merge

[Xavier C. <cha...@gm...>]

I've been using the configure line from nouveau wiki for a while now :
http://nouveau.freedesktop.org/wiki/GalliumHowto

./configure --enable-debug --enable-glx-tls --disable-asm
--with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel
--disable-gallium-radeon --disable-gallium-svga
--with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests

        Gallium:         yes
        Gallium dirs:    auxiliary drivers state_trackers
        Target dirs:      dri-nouveau egl-nouveau dri-swrast egl-swrast
        Winsys dirs:     sw sw/xlib sw/dri sw/drm nouveau/drm
        Driver dirs:     softpipe failover trace identity nouveau nvfx nv50
        Trackers dirs:   glx dri

        Shared libs:     yes
        Static libs:     no
        EGL:             glx dri2
        GLU:             yes
        GLw:             yes (Motif: no)
        glut:            yes
        Demos:           no

This setup broke after that last merge I think :

make[3]: Entering directory
`/home/xavier/app/mesa/src/gallium/targets/egl-nouveau'
gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fvisibility=hidden -fno-strict-aliasing -g  -fPIC   -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -D_GNU_SOURCE -DPTHREADS -DDEBUG
-DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o
make[3]: *** No rule to make target
`../../../../src/gallium/state_trackers/egl/libeglx11.a', needed by
`egl_x11_nouveau.so'.  Stop.

It seems egl is enabled by default, but manually specifying
state-trackers without egl disables egl state tracker, and build
fails.
I am not sure why it worked before.

I don't know if configure.ac should handle the above configure line
somehow, either reporting it as invalid or enabling egl state tracker
anyway.

On Thu, Mar 25, 2010 at 3:06 PM, Jakob Bornecrantz <wal...@gm...> wrote:
> Hi
>
> I since this was not a interface change and I think I got a large
> enough test sample from various people I have merged the branch to
> master. I confirmed that the following builds are working; configure
> with all drivers, configure default, make linux-debug, scons with
> dri=yes, scons with dri=no.
>
> Cheers Jakob.
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>

[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 #1 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-25 10:18:05 PST ---
Created an attachment (id=34439)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34439)
fragment shader used to reproduce bug


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

           Summary: glCopyTexImage2D Doesnt seem to work correctly (returns
                    incorrect alpha component )when internal format is
                    GL_RGB
           Product: Mesa
           Version: unspecified
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: kar...@ar...


Created an attachment (id=34438)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34438)
vertex shader used with above code snippet

In the following code snippet we are using RGBA color buffer which means,

glGetIntegerv(GL_RED_BITS, &red_bits);
glGetIntegerv(GL_GREEN_BITS, &green_bits);
glGetIntegerv(GL_BLUE_BITS, &blue_bits);
glGetIntegerv(GL_ALPHA_BITS, &alpha_bits);

All of the above return 8. 

The shaders are attached. I am unable to give complete code at the moment.

<Code Snippet starts>
projMat_loc = glGetUniformLocation(uiProgram, "mvpMatrix_uni");
glUniformMatrix4fv(projMat_loc, 1, 0, matProjection);

vertices_loc = glGetAttribLocation(uiProgram, "vertex_att");
colors_loc = glGetAttribLocation(uiProgram, "color_att");
txtCoord_loc = glGetAttribLocation(uiProgram, "multiTexCoord_att");
txtSampler = glGetUniformLocation(uiProgram, "texture0");

glEnableVertexAttribArray(vertices_loc);
glEnableVertexAttribArray(colors_loc);
glEnableVertexAttribArray(txtCoord_loc);

glClearColor(0.0f, 0.0f, 0.0f, 0.0f);

texCol[0] = 0.56;
texCol[1] = 0.56;
texCol[2] = 0.56;
texCol[3] = 0.56;

glClear(GL_COLOR_BUFFER_BIT);

glVertexAttribPointer(txtCoord_loc, 2, GL_FLOAT, GL_FALSE, 0, texCoords1);

vertex[0] = 4.5;
vertex[1] = 4.5;

glVertexAttribPointer(vertices_loc, 2, GL_FLOAT, GL_FALSE, 0, &vertex[0]);
glVertexAttribPointer(colors_loc, 4, GL_FLOAT, GL_FALSE, 0, texCol);

glDrawArrays(GL_POINTS, 0, 1);

glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 4, 4, 1, 1, 0); 

glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, (GLfloat)GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, (GLfloat)GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, (GLfloat)GL_CLAMP_TO_EDGE);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, (GLfloat)GL_CLAMP_TO_EDGE);

glActiveTexture(GL_TEXTURE0);

glUniform1i(txtSampler, 0); 
glVertexAttribPointer(txtCoord_loc, 2, GL_FLOAT, GL_FALSE, 0, texCoords0);

vertex[0] = 12.5;
vertex[1] = 12.5;

col[0] = col[1] = col[2] = col[3] = 1; 

glVertexAttribPointer(vertices_loc, 2, GL_FLOAT, GL_FALSE, 0, &vertex[0]);
glVertexAttribPointer(colors_loc, 4, GL_FLOAT, GL_FALSE, 0, col);

glDrawArrays(GL_POINTS, 0, 1);

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)
##############################################################
##############################################################
##############################################################*/
</Code Snippet ends>


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


Joakim Sindholt <ba...@zh...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tst...@gm...




--- Comment #2 from Joakim Sindholt <ba...@zh...>  2010-03-25 08:29:53 PST ---
*** Bug 27301 has been marked as a duplicate of this bug. ***


-- 
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 27301] r300g: segfault while running glxgears

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

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


Joakim Sindholt <ba...@zh...> changed:

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




--- Comment #2 from Joakim Sindholt <ba...@zh...>  2010-03-25 08:29:53 PST ---


*** This bug has been marked as a duplicate of bug 24942 ***


-- 
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] plumbing for gallium swrast_dri.so

[George S. <gsa...@gm...>]

I pushed this to master, swrastg_dri was added to the autoconf build
system only.

I also did a merge with gallium-resources for st/dri at
~gsap7/gallium-resources-merge-drisw, it basically reverts the old
conversion, merges and redoes the conversion because there were a lot
of conflicts, hope this is ok.

regards,
George.


On Tue, Mar 23, 2010 at 6:52 PM, George Sapountzis
<gsa...@gm...> wrote:
> On Sun, Mar 14, 2010 at 12:25 PM, George Sapountzis
> <gsa...@gm...> wrote:
>> Hi,
>>
>> I put some patches at
>> http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do
>> the plumbing in order to build the swrast_dri wrapper around gallium
>> instead of classic mesa. For reference, swrast_dri is the fallback
>> driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It
>> must not link with libdrm, nor use any drm headers during building
>> because it is also used on platforms without drm.
>>
>
> I updated the patches with the feedback from the list and added TODO
> items at the top of drisw.c with the remaining issues. I think it's in
> good state, given the scope of swrastg_dri.so, and would like to merge
> this to master. So please review and test, esp. DRI2 and scons (since
> I cannot test DRI2 and have a tendency to break the build system ...)
>
> There is also the issue of when to choose swrastg_dri.so over
> swrast_dri.so that should be handled by the loaders, just rename
> swrastg_dri.so to swrast_dri.so for now.
>
> regards,
> George.
>

[Mesa3d-dev] [Bug 27301] r300g: segfault while running glxgears

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

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





--- Comment #1 from Alex Deucher <ag...@ya...>  2010-03-25 07:11:22 PST ---
IGP cards don't currently work properly with r300g.


-- 
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] [RFC] gallium-targets merge

[Jakob B. <wal...@gm...>]

Hi

I since this was not a interface change and I think I got a large
enough test sample from various people I have merged the branch to
master. I confirmed that the following builds are working; configure
with all drivers, configure default, make linux-debug, scons with
dri=yes, scons with dri=no.

Cheers Jakob.

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

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

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

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

[Mesa3d-dev] [Bug 27301] New: r300g: segfault while running glxgears

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

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

           Summary: r300g: segfault while running glxgears
           Product: Mesa
           Version: git
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Demos
        AssignedTo: mes...@li...
        ReportedBy: tst...@gm...


Created an attachment (id=34427)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34427)
gdb backtrace

Using the latest version of mesa from git (commit
b4b4ac668116d974522df2ce56e30b74ecdfef77) glxgears segfaults.  Here is my card
info:

01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress
200M] (prog-if 00 [VGA controller])
        Subsystem: IBM Device 059d
        Flags: bus master, 66MHz, medium devsel, latency 66, IRQ 17
        Memory at c8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at 9000 [size=256]
        Memory at b0100000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at b0120000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
        Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
        Kernel driver in use: radeon


-- 
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 27300] New: r300_fs.c:209: r300_translate_fragment_shader: Assertion `0' failed.

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

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

           Summary: r300_fs.c:209: r300_translate_fragment_shader: Assertion
                    `0' failed.
           Product: Mesa
           Version: git
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: li...@yo...


Hit while trying out the r300g driver by playing Oolite (svn HEAD, no OXPs
needed, but shaders turned up to full).

Setup: Debian testing/unstable, with bits from experimental.
  xserver-xorg-core 1.7.5
  xserver-xorg-video-radeon 6.12.192-1
  libdrm 2.4.19 (local build, with packaging adapted from 2.4.18-4)
  mesa git 2ad8692a (local build, with packaging adapted from 7.7-4)

Oolite: svn://svn.berlios.de/oolite-linux/trunk


-- 
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] Separate demos repository

[tom f. <tf...@al...>]

Eric Anholt <er...@an...> writes:
[snip -- move demos to separate repo]

*shrug*, doesn't affect me much, but sounds like a good idea.

> I'm not sure if we want the repository to contain all of previous
> Mesa history.  Right now that history costs 145MB on disk for a deep
> checkout.  If that's a problem for people, we could use the same tool
> that xcb did whose name I forget to to construct a history of just
> progs/

You're thinking of git filter-branch.  It can, indeed, drastically
reduce repository size.  Probably this:

  git filter-branch --subdirectory-filter progs -- --all

is what you want.  Might want to delete (some?) branches and tags
afterwards too.

HTH,

-tom

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

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

On Tue, Mar 23, 2010 at 7:26 PM, Luca Barbieri <lu...@lu...> wrote:
> What is the rationale behind the gallium-resources changes?

Luca,

Thanks for the feedback.  I posted something describing this a little while ago:

http://www.mail-archive.com/mes...@li.../msg11375.html

There are a bunch of things pushing us in this direction, but at its
most basic it is a recognition that we have two gpu-side objects with
very similar operations on them but exposed by the interface in quite
different ways.   Look for instance at the SVGA driver which has
implemented two separate (and fairly complex) non-blocking upload
paths for each of these entities.

And crucially, we also have APIs starting to blur the line between
textures and buffers.  In DX10 and 11 in particular, you can perform
operations on buffers (like binding as a render-target) which are
easier to cope with if we have a unified abstraction.


In the past we had some confusion in what a pipe_buffer really is -- is it:
a) a GPU-side entity which can be bound to the pipeline?
b) a mechanism for CPU/GPU communication - effectively a dma buffer?
c) a way of talking about the underlying storage for GPU resources,
effectively a linear allocation of VRAM memory?

What we're doing in gallium-resources is a unification of textures and
the view (a) of buffers as abstract GPU entities.

That implies that the roles b) and c) are covered by other entites --
in particular transfers become the generic CPU/GPU communication path,
and the underlying concept of winsys buffers (not strictly part of
gallium) provides (c).

Basically the change unifies all the GPU-side entities under a single
parent (resource).  The driver is free to implement textures and
buffers as one code path or two.  For expediency, I've tried to avoid
changing the drivers signficantly at this point, which has meant
keeping alive the separate texture and buffer implementations and
selecting between them with a vtbl.  That isn't a strict requirement
of the design, just something I've done to avoid rewriting all of the
drivers at once on my own...


> I couldn't find any and I see several points that could be improved:
> 1. How does one do texture_blanket with the gallium-resources API?
> That is, how does one bind a buffer as a texture with a specific
> format?
> 2. Why is there a transfer_inline_write and not a transfer_inline_read?
> 3. How about adding a transfer_update_region that would copy data from
> the resource to the transfer, just like transfer_inline_write copies
> from the transfer to the resource?
> 4. How about making transfers be always mapped when alive and removing
> transfer_map and transfer_unmap?

I think you brought up some of these points up in the followup to my
earlier post, eg:

http://www.mail-archive.com/mes...@li.../msg11537.html

I think your suggestions are good - I had an 'inline_read' initially,
and although I took it out, I've been convinced by others that there
are actually users for such an interface - so no objections to it
coming back in.  Similarly I agree there isn't much value in
transfer_create/destroy being separate from map and unmap.

I see these as additional enhancements beyond getting the basic
resource concept up and running which can be done in follow-on work.

In reference to texture_blanket - this was actually removed from
gallium a little while ago - replaced by the texture_from_handle() and
texture_get_handle() interfaces.  In this case the 'handle' is a
pointer to an operating-system specific entity -- presumably
describing the underlying storage.

> In addition to these micro-level issues, is the bigger picture
> unification of buffers and textures as resources a good idea?

I think so, not least because other APIs are moving in this direction
and using them somewhat interchangeably.

> It will burden all buffer operations with redundant notions of 3D
> boxes, strides, formats and texture targets.

I'm not sure where you see this, but if there are specific cases where
there is a lot of new overhead, we can work to reduce that.

> How about instead layering textures over buffers, and exposing the
> underlying buffer of a texture, maybe also allowing to dynamically
> change it?

I think this makes sense for the view of buffers as memory-manager
allocations.  That works for certain cases, eg native rendering on
local machines, but not all uses of gallium can be described that way.
 We're really positioning the gallium api at a slightly higher
abstraction level, to cover both the case where that could work in
addition to ones which don't fit that mold.

> Then you could create a texture, asking the driver to create a buffer
> too, for the normal texture creation case.
> You could create a texture with a specified format and layout over an
> existing buffer to implement buffer-as-texture, or reinterpret the
> underyling buffer of an existing texture as another data format.
> You could also create a texture without an underlying buffer, to find
> out how large of a buffer you would need for that texture layout. (and
> whether it is supported). This could be useful for OpenGL texture
> proxies.
> For shared textures, you would call buffer_from_handle and then create
> a texture over it with the desired format/layout.
>
> 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.

> Furthermore, in the gallium-resource branch both r300g and nouveau
> drivers have different internal implementations for buffer and texture
> transfers (they actually look fundamentally different, not just
> duplicated code): why not just expose them directly as two separate,
> more efficient, interfaces, instead of going through a single fat
> interface, and then a further indirect branch in the driver?

I hope that the driver will unify these implementations internally
over time.  The reason I have a split internally is because I want to
avoid changing too much of the driver in a single hit and hence have
done my best to keep the original code intact.  It will be up to the
driver owners over time to decide how and when  to merge those
implementations down to a single path.

It's just too much for me do that for all these drivers on my own -
even the current code is more change than I wanted to make, especially
for the nouveau drivers where there was this internal layering of
textures on top of pipe_buffers.  That really was a layering violation
- it would have been cleaner if both textures and buffers were
directly layered on top of some underlying drm/winsys bo, eg the
nouveau_bo.

> In addition transfers could be handled by an auxiliary module that
> would ask the driver to directly map the texture, and would otherwise
> create a temporary itself and use a driver-provided buffer_copy or
> surface_copy manually.
> Note that many drivers implement transfers this way and this would
> avoid duplicate code in drivers.
> transfer_inline_write can also be done by copies from user buffers, or
> textures layered over user buffers.

An auxilliary module for this sounds like a good idea -- I don't see
that having a combined GPU-side abstraction makes it any harder than
it would be otherwise though.

Some of the confusion we have is because of the many different
entities we can label as buffers.  Your suggestion sounds more like
how I'd describe layering graphics functionality on top of the
underlying video memory manager's idea of a buffer.  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.

Keith