mesa3d-dev

Re: [Mesa3d-dev] Broken variable scopes in Mesa?

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

Mathias Gottschlag wrote:
> While trying Horde3D on nouveau I found out that Mesa rejects the
> following shader which correctly compiles on the proprietary drivers
> and, as far as I can see, seems to be correct according to the GLSL specs:
> 
> 
> uniform sampler2D tex;
> 
> void main()
> {
> 	vec3 tex = texture2D(tex, gl_TexCoord[0].st);
> 	gl_FragColor.rgb = tex;
> }
> 
> Here Mesa chokes on the first parameter to texture2D because it inserts
> an (undefined?) vec3 there, the same way as C/C++ would react here,
> which results in the following error:
> 
> Error: undefined function 'texture2D'
> Error: incompatible types in assignment
> 
> The GLSL spec (1.20) however says:
> 
> Within a declaration, the scope of a name starts immediately after the
> initializer if present or immediately
> after the name being declared if not.
> 
> 
> Did I miss something here, did I interpret the specs wrong? I looked
> into the sources in order to maybe fix the problem, but without any
> knowledge of Mesa's internals, that's a bit to high for me.

It's probably incorrect in our compiler.

You're best off playing it safe and using another variable name.  I 
wouldn't be surprised if other GLSL compilers got this wrong too.

-Brian

Re: [Mesa3d-dev] sw-api-2 branch

[Dan N. <dbn...@gm...>]

On Thu, Mar 11, 2010 at 12:23 PM, Dan Nicholson <dbn...@gm...> wrote:
> On Thu, Mar 11, 2010 at 12:19 PM, STEVE555 <ste...@ho...> wrote:
>>
>> Hi Keith,
>>            Here's what I did.I opened Konsole on my mesa folder.I did a git
>> pull origin to get the latest commits from master,then I did a git checkout
>> -b gallium-sw-api-2 origin/gallium-sw-api-2 to get your branch again(I
>> deleted it earlier) .I then switched to the gallium-sw-api-2 using git
>> branch and then did a git merge master.I saved your patch in a txt file,and
>> then renamed it as gallium-sw-api-2.patch,I then used Kompare to apply and
>> save all the differences.
>>  I then did a gmake -B realclean and then I used the same configure options
>> as before.
>> Unfortunately,your patch didn't work,I still get the same error as before.
>
> You would actually need to run autoconf first to generate a new
> configure script with Keith's changes.

Or just run ./autogen.sh with the arguments you normally pass to configure.

--
Dan

Re: [Mesa3d-dev] sw-api-2 branch

[Dan N. <dbn...@gm...>]

On Thu, Mar 11, 2010 at 12:19 PM, STEVE555 <ste...@ho...> wrote:
>
> Hi Keith,
>            Here's what I did.I opened Konsole on my mesa folder.I did a git
> pull origin to get the latest commits from master,then I did a git checkout
> -b gallium-sw-api-2 origin/gallium-sw-api-2 to get your branch again(I
> deleted it earlier) .I then switched to the gallium-sw-api-2 using git
> branch and then did a git merge master.I saved your patch in a txt file,and
> then renamed it as gallium-sw-api-2.patch,I then used Kompare to apply and
> save all the differences.
>  I then did a gmake -B realclean and then I used the same configure options
> as before.
> Unfortunately,your patch didn't work,I still get the same error as before.

You would actually need to run autoconf first to generate a new
configure script with Keith's changes.

--
Dan

Re: [Mesa3d-dev] sw-api-2 branch

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

Hi Keith,
            Here's what I did.I opened Konsole on my mesa folder.I did a git
pull origin to get the latest commits from master,then I did a git checkout
-b gallium-sw-api-2 origin/gallium-sw-api-2 to get your branch again(I
deleted it earlier) .I then switched to the gallium-sw-api-2 using git
branch and then did a git merge master.I saved your patch in a txt file,and
then renamed it as gallium-sw-api-2.patch,I then used Kompare to apply and
save all the differences.
 I then did a gmake -B realclean and then I used the same configure options
as before.
Unfortunately,your patch didn't work,I still get the same error as before.
Regards,
             Steve

Keith Whitwell-3 wrote:
> 
> Steve,
> 
> Does the attached patch help for you?
> 
> Keith
> 
> On Wed, 2010-03-10 at 05:34 -0800, STEVE555 wrote:
>> Hi Keith,
>>             I use these configure options:
>> ./configure --prefix=/usr --enable-32-bit --enable-xcb
>> --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es
>> --enable-motif --enable-gl-osmesa --disable-gallium-intel
>> --disable-gallium-radeon --with-expat=/usr/lib
>> --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast
>> --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096
>> --with-max-height=4096 --ernable-debug
>> 
>> I sometimes use --with-max-width= and --with-max-height= but the rest of
>> them generally stay the same.
>> 
>> Regards,
>>              STEVE555
>> 
>> 
>> Keith Whitwell-3 wrote:
>> > 
>> > Steve,
>> > 
>> > What configure options are those?
>> > 
>> > Keith
>> > 
>> > On Wed, 2010-03-10 at 04:41 -0800, STEVE555 wrote:
>> >> Dear Keith,
>> >>                 I checked out your branch using git checkout -b.and
>> used
>> >> git
>> >> pull to get the differences between your branch and master.I did a
>> gmake
>> >> -B
>> >> realclean and used my ./configure options I use for master.
>> >> Unfortunately,it has stopped compiling with this error:
>> >> 
>> >> /usr/bin/install -c vmwgfx_dri.so ../../../../../../lib/gallium
>> >> gmake[5]: Leaving directory
>> `/opt/mesa/src/gallium/winsys/drm/vmware/dri'
>> >> gmake[5]: Entering directory
>> >> `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
>> >> gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
>> >> -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
>> >> -DUSE_X86_ASM
>> >> -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
>> >> -DDEBUG
>> >> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
>> -DIN_DRI_DRIVER
>> >> -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
>> >> -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 -D_GNU_SOURCE
>> >> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
>> >> -DUSE_EXTERNAL_DXTN_LIB=1
>> >> -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING
>> >> -DHAVE_ALIAS
>> >> -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dummy.c -o
>> dummy.o
>> >> gmake[5]: *** No rule to make target
>> >> `../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
>> >> `egl_x11_vmwgfx.so'.  Stop.
>> >> gmake[5]: Leaving directory
>> `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
>> >> gmake[4]: *** [default] Error 1
>> >> gmake[4]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware'
>> >> gmake[3]: *** [default] Error 1
>> >> gmake[3]: Leaving directory `/opt/mesa/src/gallium/winsys/drm'
>> >> gmake[2]: *** [default] Error 1
>> >> gmake[2]: Leaving directory `/opt/mesa/src/gallium/winsys'
>> >> gmake[1]: *** [subdirs] Error 1
>> >> gmake[1]: Leaving directory `/opt/mesa/src'
>> >> gmake: *** [default] Error 1
>> >> 
>> >> Regards,
>> >>              STEVE555
>> >> 
>> >> 
>> >> Keith Whitwell-3 wrote:
>> >> > 
>> >> > This has reached a point where I could think about merging it. 
>> There
>> >> is
>> >> > plenty more cleanup to do, but the branch makes some big strides and
>> >> > introduces a couple of concepts that I've wanted for a long time. 
>> >> > 
>> >> > In particular the idea of a designated "targets" subtree which has
>> code
>> >> > for explicitly constructing driver stacks. 
>> >> > 
>> >> > Secondly the ability to inject layers into (at least) the software
>> >> > stacks has been greatly improved, and I'd like to see us build on
>> that
>> >> > for hardware drivers as well.
>> >> > 
>> >> > There is probably still some bugfix to come, but if you're
>> interested
>> >> in
>> >> > the software rasterizers, please check out this branch and let me
>> know
>> >> > how much I've broken things...
>> >> > 
>> >> > Keith
>> >> > 
>> >> > 
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > 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
>> >> > 
>> >> > 
>> >> 
>> > 
>> > 
>> > 
>> >
>> ------------------------------------------------------------------------------
>> > 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
>> > 
>> > 
>> 
> 
> 
> diff --git a/configure.ac b/configure.ac
> index 70e158f..049c9e5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -458,6 +458,7 @@ CORE_DIRS="glsl mesa"
>  SRC_DIRS="glew"
>  GLU_DIRS="sgi"
>  GALLIUM_DIRS="auxiliary drivers state_trackers"
> +GALLIUM_TARGET_DIRS=""
>  GALLIUM_WINSYS_DIRS=""
>  GALLIUM_WINSYS_DRM_DIRS=""
>  GALLIUM_DRIVERS_DIRS="softpipe failover trace identity"
> @@ -467,11 +468,12 @@ case "$mesa_driver" in
>  xlib)
>      DRIVER_DIRS="x11"
>      GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS xlib"
> +    GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS libgl-xlib"
>      ;;
>  dri)
>      SRC_DIRS="$SRC_DIRS glx"
>      DRIVER_DIRS="dri"
> -    GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS drm"
> +    GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS xlib drm"
>      ;;
>  osmesa)
>      DRIVER_DIRS="osmesa"
> @@ -481,6 +483,7 @@ AC_SUBST([SRC_DIRS])
>  AC_SUBST([GLU_DIRS])
>  AC_SUBST([DRIVER_DIRS])
>  AC_SUBST([GALLIUM_DIRS])
> +AC_SUBST([GALLIUM_TARGET_DIRS])
>  AC_SUBST([GALLIUM_WINSYS_DIRS])
>  AC_SUBST([GALLIUM_WINSYS_DRM_DIRS])
>  AC_SUBST([GALLIUM_DRIVERS_DIRS])
> @@ -1415,6 +1418,7 @@ echo ""
>  if echo "$SRC_DIRS" | grep 'gallium' >/dev/null 2>&1; then
>      echo "        Gallium:         yes"
>      echo "        Gallium dirs:    $GALLIUM_DIRS"
> +    echo "        Target dirs:     $GALLIUM_TARGET_DIRS"
>      echo "        Winsys dirs:     $GALLIUM_WINSYS_DIRS"
>      echo "        Winsys drm dirs:$GALLIUM_WINSYS_DRM_DIRS"
>      echo "        Driver dirs:     $GALLIUM_DRIVERS_DIRS"
> 
> ------------------------------------------------------------------------------
> 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/sw-api-2-branch-tp27841684p27869260.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

[Mesa3d-dev] Fwd: Re: Gallium questions ...

[Christoph B. <e04...@st...>]

Sorry, forgot to reply-all ...

-------- Original Message --------
Subject: 	Re: [Mesa3d-dev] Gallium questions ...
Date: 	Thu, 11 Mar 2010 18:29:10 +0100
From: 	Christoph Bumiller <e04...@st...>
To: 	Jerome Glisse <gl...@fr...>



On 11.03.2010 18:13, Jerome Glisse wrote:
> Hi all,
>
> I have been a little bit out of the loop on the mesa side, thus now i am
> having a bunch of questions relating to gallium, apologies if i am asking
> for obvious thing.
>
> First in tgsi compiler there is a Dimension field (struct tgsi_dimension)
> that i don't understand, it seems all driver are ignoring it, from quick
> glimpse to tgsi code it's for 2d array addressing, but i think glsl only
> talks about 1d array. What are the exepction for this field ? Should
> driver care ?
>
>   
In geometry programs you have 2D arrays, Dimension specifying
the vertex index (nv50 does use this);
at least that's how I interpreted it (left out the swizzles):

MOV OUT[0], IN[a[i] + j][b[k] + n]
i = src->DimIndirect.Index
j = src->Dimension.Index
k = src->Indirect.Index
n = src->Register.Index
a = src->DimIndirect.File
b = src->Indirect.File

VertexID = a[i] + j

> What is the indirect boolean for in src or dst operand of an instruction ?
> What is the GLSL equivalent of it.
>
>   
If src->Register.Indirect is true, src->Indirect is the addressing
register to be used.
> Also i think GLSL state that the sampler information should be defined
> at shader build time but the TGSI doesn't seems to provide those, for
> r600 i need to have a shader rewritting because of this (it's not big
> and i don't mind much and i also can avoid rewritting by checking if
> there is a change in the bound sampler).
>   
What sampler information ?
The texture target is defined in FullInstruction.Texture.Texture,
is that not sufficient ?

Christoph

> A more practical question are what are the gallium branches likely to be
> merge in the next few weeks ? I will likely have r600g driver in good
> shape enough in the next few weeks to consider merging it with master
> but i would like first to port it to the lastest gallium change before
> merging it so i don't put the burden on people working on those
> branches.
>
> What are the plan to expand TGSI to support new shader feature ? (double
> precision op, ...)
>
>
> Thanks to who ever can shed some light on those question for me :)
>
> Cheers,
> Jerome
>
> ------------------------------------------------------------------------------
> 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 26730] Gallium driver for r500 GL_NV_vertex_program doesn't work

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

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


Marek Olšák <ma...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED




-- 
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 26730] Gallium driver for r500 GL_NV_vertex_program doesn't work

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

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


Marek Olšák <ma...@gm...> changed:

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




--- Comment #1 from Marek Olšák <ma...@gm...>  2010-03-11 12:08:40 PST ---
The extension NV_vertex_program has been removed from Gallium as of today.
Closing...


-- 
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] Broken variable scopes in Mesa?

[Mathias G. <mat...@we...>]

While trying Horde3D on nouveau I found out that Mesa rejects the
following shader which correctly compiles on the proprietary drivers
and, as far as I can see, seems to be correct according to the GLSL specs:


uniform sampler2D tex;

void main()
{
	vec3 tex = texture2D(tex, gl_TexCoord[0].st);
	gl_FragColor.rgb = tex;
}

Here Mesa chokes on the first parameter to texture2D because it inserts
an (undefined?) vec3 there, the same way as C/C++ would react here,
which results in the following error:

Error: undefined function 'texture2D'
Error: incompatible types in assignment

The GLSL spec (1.20) however says:

Within a declaration, the scope of a name starts immediately after the
initializer if present or immediately
after the name being declared if not.


Did I miss something here, did I interpret the specs wrong? I looked
into the sources in order to maybe fix the problem, but without any
knowledge of Mesa's internals, that's a bit to high for me.

Mathias Gottschlag

[Mesa3d-dev] [Bug 27007] Lines disappear with GL_LINE_SMOOTH

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

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





--- Comment #3 from Søren Hauberg <so...@ha...>  2010-03-11 11:12:03 PST ---
Created an attachment (id=33962)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33962)
Output of 'glxinfo'


-- 
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] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[Jakob B. <ja...@vm...>]

On 11 mar 2010, at 04.15, Chia-I Wu wrote:
> Hi all,
>
> This patch series adds st_api interface to st/mesa and st/vega, and
> switch st/egl and st/glx from st_public interface to the new  
> interface.
>
> Feature-wise, st_api provides a more robust multiple client APIs
> (OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
> various EGLImage extensions.  As st_api interface can coexist with
> st_public interface, co state trackers should work as before unless  
> they
> are switched to use st_api.
>
> The original plan to merge the work to master after the interface is
> implemented by st/mesa and st/vega, and st/egl is converted to use it.
> Further development and conversions of st/glx and st/dri will happen  
> in
> master.  While this is still the plan, the recent merge of
> gallium-sw-api-2 motivates me to submit this WIP patch series for  
> public
> review.  I will cover only pipe_screen::update_buffer,
> pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
> here as the other parts were discussed a while ago.  But any  
> feedback to
> the design is appreciated.
>
> To summarize, there is *no* change to pipe_screen::update_buffer and
> pipe_screen::flush_frontbuffer.  This guarantees the non-Khronos state
> trackers are not affected, and the st_public path of st/mesa and st/ 
> vega
> still work.  But when the st_api path is taken,
> pipe_screen::update_buffer is no longer got called.  And the caller of
> pipe_screen::flush_frontbuffer becomes co state trackers instead of
> state trackers.
>
> In st_api, the co state trackers are responsible for representing
> windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
> depth/stencil, ...) to the state trackers.  In DRI2, this is done
> through DRI2GetBuffers and winsys_handle.  In software rasterizer (or
> DRI1?), this is done by having co state trackers allocate a set of
> private pipe_textures.  In both cases, the pipe_textures are created  
> as
> needed.  That is, if the state trackers draw only to the back buffer,
> the front buffer will not be creatd.
>
> At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
> st_framebuffer_iface.  The state trackers retrieve the pipe_textures  
> of
> a window/pixmap/pbuffer mentioned above through this interface.  Other
> than retrieving the pipe_textures, to support front buffer rendering,
> the state trackers should call st_framebuffer_iface::flush_front  
> when it
> has something to display.
>
> The implementation of st_framebuffer_iface::flush_front again  
> depends on
> the window systems.  In X11 with DRI2, it is no-op if the front buffer
> passed to the state trackers is real;  Otherwise, it calls
> DRI2CopyRegion to copy the contents from the fake front buffer to the
> real front one.
>
> In X11 with software rasterizer, the co state tracker is responsible  
> to
> display its private pipe_texture to a X drawable.  With the merge of
> gallium-sw-api-2, this is made really easy by calling
> pipe_screen::flush_frontbuffer.
>
> The last patch of the series converts st/glx to use st_api.  The  
> diff is
> cleaner than the diff to st/egl.  It is a quick conversion to help see
> the design of st_api in work.  There should be bugs, but the simple
> demos I tested all work.  The other patches are constrained to EGL and
> any regression outside EGL is considered a bug.
>
> If you read this long because of the mention of EGLImage in the  
> subject,
> you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
> thank-you gift :)

Thanks for doing this Chia-I, also a very excellent summary. Last time  
we talked about st_api IIRC we both agreed that the way we implemented  
EGLImage was wrong. However I think that we have waited long enough to  
move the state trackers over to st_api.

Would it to much trouble for you if we didn't do EGLImage in the first  
gallium-st-api feature branch? My feeling is that they are two  
separate issues and I think we should be able to quickly resolve  
moving the state trackers over to st_api and then move on to EGLImage.  
Looking at the patches the only affected one is the VG state tracker  
while the rest should just be not to apply the EGLImage related  
patches. I can do this later tonight and send out a series and give  
you something to work on.

I really want to move the state trackers over to st_api and I don't  
want the EGLImage issues holding us back. I also think that that part  
of the patch series looks excellent and I don't foresee any  
difficulties getting this merged ASAP.

Again thanks for doing this I know the inter state tracker  
interactions are a mess.

Cheers Jakob.

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

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

On Thu, 2010-03-11 at 11:28 -0700, Brian Paul wrote: 
> Luca Barbieri wrote:
> > Solves the Warsow issue and seems to work.
> 
> OK, I think you can commit the patch to 7.8 then.

Can this also be backported to mesa_7_7_branch?


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

Re: [Mesa3d-dev] Gallium questions ...

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

On Thu, Mar 11, 2010 at 9:13 AM, Jerome Glisse <gl...@fr...> wrote:
> Also i think GLSL state that the sampler information should be defined
> at shader build time but the TGSI doesn't seems to provide those, for
> r600 i need to have a shader rewritting because of this (it's not big
> and i don't mind much and i also can avoid rewritting by checking if
> there is a change in the bound sampler).

Yeah, welcome to TGSI. You'll have to do like r300g and recompile the shader.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

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

Re: [Mesa3d-dev] Gallium questions ...

[michal <mi...@vm...>]

Jerome Glisse wrote on 2010-03-11 18:13:
> Hi all,
>
> I have been a little bit out of the loop on the mesa side, thus now i am
> having a bunch of questions relating to gallium, apologies if i am asking
> for obvious thing.
>
> First in tgsi compiler there is a Dimension field (struct tgsi_dimension)
> that i don't understand, it seems all driver are ignoring it, from quick
> glimpse to tgsi code it's for 2d array addressing, but i think glsl only
> talks about 1d array. What are the exepction for this field ? Should
> driver care ?
>
>   
It makes sense for geometry shaders, where you use one dimension to 
address input vertex, and another one to index a particular input 
attribute within that vertex.

> What is the indirect boolean for in src or dst operand of an instruction ?
> What is the GLSL equivalent of it.
>
>   
This is used to e.g. address constant registers with a non-constant index.

> A more practical question are what are the gallium branches likely to be
> merge in the next few weeks ? I will likely have r600g driver in good
> shape enough in the next few weeks to consider merging it with master
> but i would like first to port it to the lastest gallium change before
> merging it so i don't put the burden on people working on those
> branches.
>
> What are the plan to expand TGSI to support new shader feature ? (double
> precision op, ...
I am planning to add a new set of texture fetch/sampler instructions in 
the immediate future. The gallium-double-opcodes branch has stalled, 
though, so it won't be merged any time soon.

Re: [Mesa3d-dev] Commit messages broken??

[Dan N. <dbn...@gm...>]

On Thu, Mar 11, 2010 at 7:10 AM, Daniel Stone <da...@fo...> wrote:
> On Thu, Mar 11, 2010 at 10:02:46AM -0500, Zack Rusin wrote:
>> On Thursday 11 March 2010 02:58:49 Tollef Fog Heen wrote:
>> > ]] Zack Rusin
>> > | BTW, replacing a mail client on the server with something that's not
>> > | compatible is not very social.
>> >
>> > Rather than assuming malice, you may assume that I was trying to fix
>> > something when I made that change.
>>
>> I was assuming that whoever did it was trying to do something, but the
>> reasoning behind the change doesn't change the result at all - we were not
>> informed of it and the commit messages broke. So as far as we are concerned
>> there really wouldn't be any difference between someone just deleting
>> /usr/bin/mail and you trying to fix something by replacing mail with something
>> else. The bottom line is that there's quite a few projects hosted on fdo, with
>> a lot of people depending on that setup and making changes to it without
>> communicating it very clearly it is bound to break something.
>> I don't want to make into a big deal, because it wasn't but a short email or
>> even an blog just saying "new /usr/bin/mail is coming in, make sure it doesn't
>> break your project" would avoid the whole problem.
>
> Shit happens.  Ease up.

Not to fan the flames anymore, but there is the fd.o administration
blog that's syndicated on planet. That would be a nice place to dump
information like this, and IIRC Benjamin used to do that. However, it
seems that www.freedesktop.org/adminblog/ doesn't have the necessary
permissions to view the entries.

--
Dan

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

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

Luca Barbieri wrote:
> Solves the Warsow issue and seems to work.

OK, I think you can commit the patch to 7.8 then.

-Brian

Re: [Mesa3d-dev] extensions supported or not in gallium

[Roland S. <sr...@vm...>]

On 11.03.2010 17:54, Brian Paul wrote:
> Roland Scheidegger wrote:
>> Hi,
>>
>> there are currently a couple of extensions enabled in the mesa state
>> tracker which probably shouldn't be. These were moved there by commit
>> a0ae2ca033ec2024da1e01d1c11c0437837c031b (that is with dri they were
>> already always enabled before).
>>
>> Someone knows off-hand which one we can enable or not? I'm going to kill
>> off EXT_cull_vertex and  TDFX_texture_compression_FXT1, clearly we can't
>> handle them.
>> The others in question are
>> ARB_window_pos
> 
> handled in core mesa.
> 
> 
>> APPLE_client_storage
> 
> should not be enabled by default.
> 
> 
>> MESA_pack_invert
> 
> handled by core mesa.
> 
> 
>> NV_vertex_program
>> NV_vertex_program1_1
>>
>> (the latter two IIRC the problem was that regs needed to be
>> zero-initialized)
> 
> There may be other issues too.  Someone would have to enable the 
> extension(s) and do some testing.
> 
> 
>> Currently gallium dri drivers also have ARB_imaging enabled too (via
>> driInitExtensions()), I think that's not correct neither.
> 
> Yeah, I think that needs to be disabled.

Ok thanks I've pushed a fix.

Roland

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

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

Solves the Warsow issue and seems to work.
Thanks!

[Mesa3d-dev] Gallium questions ...

[Jerome G. <gl...@fr...>]

Hi all,

I have been a little bit out of the loop on the mesa side, thus now i am
having a bunch of questions relating to gallium, apologies if i am asking
for obvious thing.

First in tgsi compiler there is a Dimension field (struct tgsi_dimension)
that i don't understand, it seems all driver are ignoring it, from quick
glimpse to tgsi code it's for 2d array addressing, but i think glsl only
talks about 1d array. What are the exepction for this field ? Should
driver care ?

What is the indirect boolean for in src or dst operand of an instruction ?
What is the GLSL equivalent of it.

Also i think GLSL state that the sampler information should be defined
at shader build time but the TGSI doesn't seems to provide those, for
r600 i need to have a shader rewritting because of this (it's not big
and i don't mind much and i also can avoid rewritting by checking if
there is a change in the bound sampler).

A more practical question are what are the gallium branches likely to be
merge in the next few weeks ? I will likely have r600g driver in good
shape enough in the next few weeks to consider merging it with master
but i would like first to port it to the lastest gallium change before
merging it so i don't put the burden on people working on those
branches.

What are the plan to expand TGSI to support new shader feature ? (double
precision op, ...)


Thanks to who ever can shed some light on those question for me :)

Cheers,
Jerome

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Maxim L. <max...@gm...>]

On Wed, 2010-03-10 at 13:04 +0100, Florian Mickler wrote:
> On Sun, 07 Mar 2010 12:39:15 +0200
> Maxim Levitsky <max...@gm...> wrote:
> 
> > On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote:
> > > On Sun, 07 Mar 2010 00:24:24 +0200
> > > Maxim Levitsky <max...@gm...> wrote:
> > > 
> > > > On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
> > > > > On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
> > > > > > On Sat, 06 Mar 2010 18:02:51 +0100
> > > > > > Stephan Raue <mai...@op...> wrote:
> > > > > > 
> > > > > > > looks this like my problems that i have reported some days ago with 
> > > > > > > Subject "Problem using an Mesa based App with recent 
> > > > > > > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> > > > > > > 
> > > > > > > i have still this issue, but i dont know what you need for informations 
> > > > > > > to fix the issues?
> > > > > > > 
> > > > > > > with ati driver i dont have problems, only here with intel driver on my 
> > > > > > > Thinkpad X200t with intel HDA Graphics card
> > > > > > > 
> > > > > 
> > > > > I now see that compiz hangs in same way.
> > > > > 
> > > > > Attached are backtrace of the compiz, and backtrace of etracer which did
> > > > > start full screen but became hung on resolution change.
> > > > > 
> > > > > Best regards,
> > > > > 	Maxim Levitsky
> > > > 
> > > > Other info that might help:
> > > > 
> > > > I took a look at X and found that it was in normal waiting state
> > > > sleeping waiting for input.
> > > > 
> > > > Also, I found when 'unstable' mesa would appear to work when I start the
> > > > X while 'stable' one is used. It was compiz. When compiz is running
> > > > using stable mesa, an game does change the resolution 'usualy' without
> > > > hang even if uses unstable mesa.
> > > > 
> > > > Best regards,
> > > > 	Maxim Levitsky
> > > 
> > > i found that the kernel updates for 2.6.34-rc1 did make the hang time
> > > out... this has to be some vblank issue, i assume...
> > 
> > 
> > Note that I did try git master of linus tree, and that didn't help with
> > the hang at all (now pulled it again, but don't see any  changes in drm
> > code)
> > 
> > Best regards,
> > 	Maxim Levisky
> 
> yeah. i'm sorry. My issues vanished with current git versions of
> libdrm,mesa,xserver,xf86-video-intel ... while trying to find out(in
> vain) which part of the stack did fix the issue, i noticed that the 
> xserver-patches in jesse's tree was which changed "hung" into
> "timeout"... 


Note that I updated the stack today, but nothing changed.

Best regards,
	Maxim Levitsky

Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge

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

On Thu, 2010-03-11 at 08:59 -0800, Jerome Glisse wrote:
> On Thu, Mar 11, 2010 at 03:16:32PM +0000, Keith Whitwell wrote:
> > On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
> > > Keith Whitwell wrote on 2010-03-11 14:21:
> > > > On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> > > >   
> > > >> Hi,
> > > >>
> > > >> I would like to merge the branch in subject this week. This feature 
> > > >> branch allows state trackers to bind sampler views instead of textures 
> > > >> to shader stages.
> > > >>
> > > >> A sampler view object holds a reference to a texture and also overrides 
> > > >> internal texture format (resource casting) and specifies RGBA swizzle 
> > > >> (needed for GL_EXT_texture_swizzle extension).
> > > >>     
> > > >
> > > > Michal,
> > > >
> > > > I've got some issues with the way the sampler views are being generated
> > > > and used inside the CSO module.
> > > >
> > > > The point of a sampler view is that it gives the driver an opportunity
> > > > to do expensive operations required for special sampling modes (which
> > > > may include copying surface data if hardware is deficient in some way).
> > > >
> > > > This approach works if a sampler view is created once, then used
> > > > multiple times before being deleted.
> > > >
> > > > Unfortunately, it seems the changes to support this in the CSO module
> > > > provide only a single-shot usage model.  Sampler views are created in
> > > > cso_set_XXX_sampler_textures, bound to the context, and then
> > > > dereferenced/destroyed on the next bind.
> > > >
> > > >   
> > > The reason CSO code looks like this is because it was meant to be an 
> > > itermediate step towards migration to sampler view model. Fully 
> > > converting all existing state trackers is non-trivial and thus I chose 
> > > this conservative approach. State trackers that do not care about extra 
> > > features a sampler view provides will keep using this one-shot CSO 
> > > interface with the hope that creation of sampler objects is lighweight 
> > > (format matches texture format, swizzle matches native texel layout, 
> > > etc.). 
> > 
> > On the surface, this hope isn't likely to be fulfilled - lots of
> > hardware doesn't support non-zero first_level.  Most cases of drivers
> > implementing sampler views internally are to catch this issue.
> > 
> > Of course, it seems like your branch so leaves the existing
> > driver-specific sampler view code in place, so that there are
> > potentially two implementations of sampler views in those drivers.  
> > 
> > I guess this means that you can get away with the current implementation
> > for now, but it prevents drivers actually taking advantage of the fact
> > that these entities exist in the interface -- they will continue to have
> > to duplicate the concept internally until the state trackers and/or CSO
> > module start caching views.
> > 
> > > Ideally, everybody moves on and we stop using CSO for sampler 
> > > views. I prefer putting my effort into incremental migration of state 
> > > trackers rather than caching something that by definition doesn't need 
> > > to be cached.
> > 
> > The CSO module exists to manage this type of caching on behalf of state
> > trackers.  I would have thought that this was a sensible extension of
> > the existing purpose of the CSO module.
> > 
> > Won't all state-trackers implementing APIs which don't expose sampler
> > views to the application require essentially the same caching logic, as
> > is the case with regular state?  Wouldn't it be least effort to do that
> > caching once only in the CSO module?
> > 
> > Keith
> > 
> 
> I didn't read anything about sampler view stuff, thus i can be
> completely wrong here, but from driver pov i prefer having most
> of the state going through create,bind,destroy pattern ie having
> the CSO doing the caching.

Jerome,

The driver view in both cases is as you describe - it's just a question
of whether the state tracker does the create/bind/destroy itself, or if
we can build a helper module to do that logic for it.

Keith

Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge

[michal <mi...@vm...>]

Keith Whitwell wrote on 2010-03-11 16:16:
> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
>   
>> Keith Whitwell wrote on 2010-03-11 14:21:
>>     
>>> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
>>>   
>>>       
>>>> Hi,
>>>>
>>>> I would like to merge the branch in subject this week. This feature 
>>>> branch allows state trackers to bind sampler views instead of textures 
>>>> to shader stages.
>>>>
>>>> A sampler view object holds a reference to a texture and also overrides 
>>>> internal texture format (resource casting) and specifies RGBA swizzle 
>>>> (needed for GL_EXT_texture_swizzle extension).
>>>>     
>>>>         
>>> Michal,
>>>
>>> I've got some issues with the way the sampler views are being generated
>>> and used inside the CSO module.
>>>
>>> The point of a sampler view is that it gives the driver an opportunity
>>> to do expensive operations required for special sampling modes (which
>>> may include copying surface data if hardware is deficient in some way).
>>>
>>> This approach works if a sampler view is created once, then used
>>> multiple times before being deleted.
>>>
>>> Unfortunately, it seems the changes to support this in the CSO module
>>> provide only a single-shot usage model.  Sampler views are created in
>>> cso_set_XXX_sampler_textures, bound to the context, and then
>>> dereferenced/destroyed on the next bind.
>>>
>>>   
>>>       
>> The reason CSO code looks like this is because it was meant to be an 
>> itermediate step towards migration to sampler view model. Fully 
>> converting all existing state trackers is non-trivial and thus I chose 
>> this conservative approach. State trackers that do not care about extra 
>> features a sampler view provides will keep using this one-shot CSO 
>> interface with the hope that creation of sampler objects is lighweight 
>> (format matches texture format, swizzle matches native texel layout, 
>> etc.). 
>>     
>
> On the surface, this hope isn't likely to be fulfilled - lots of
> hardware doesn't support non-zero first_level.  Most cases of drivers
> implementing sampler views internally are to catch this issue.
>
> Of course, it seems like your branch so leaves the existing
> driver-specific sampler view code in place, so that there are
> potentially two implementations of sampler views in those drivers.  
>
> I guess this means that you can get away with the current implementation
> for now, but it prevents drivers actually taking advantage of the fact
> that these entities exist in the interface -- they will continue to have
> to duplicate the concept internally until the state trackers and/or CSO
> module start caching views.
>
>   
>> Ideally, everybody moves on and we stop using CSO for sampler 
>> views. I prefer putting my effort into incremental migration of state 
>> trackers rather than caching something that by definition doesn't need 
>> to be cached.
>>     
>
> The CSO module exists to manage this type of caching on behalf of state
> trackers.  I would have thought that this was a sensible extension of
> the existing purpose of the CSO module.
>
> Won't all state-trackers implementing APIs which don't expose sampler
> views to the application require essentially the same caching logic, as
> is the case with regular state?  Wouldn't it be least effort to do that
> caching once only in the CSO module?
>   
OK, I see your point. I will make the necessary changes and ping you 
when that's done.

Thanks.

Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge

[Jerome G. <gl...@fr...>]

On Thu, Mar 11, 2010 at 03:16:32PM +0000, Keith Whitwell wrote:
> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
> > Keith Whitwell wrote on 2010-03-11 14:21:
> > > On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> > >   
> > >> Hi,
> > >>
> > >> I would like to merge the branch in subject this week. This feature 
> > >> branch allows state trackers to bind sampler views instead of textures 
> > >> to shader stages.
> > >>
> > >> A sampler view object holds a reference to a texture and also overrides 
> > >> internal texture format (resource casting) and specifies RGBA swizzle 
> > >> (needed for GL_EXT_texture_swizzle extension).
> > >>     
> > >
> > > Michal,
> > >
> > > I've got some issues with the way the sampler views are being generated
> > > and used inside the CSO module.
> > >
> > > The point of a sampler view is that it gives the driver an opportunity
> > > to do expensive operations required for special sampling modes (which
> > > may include copying surface data if hardware is deficient in some way).
> > >
> > > This approach works if a sampler view is created once, then used
> > > multiple times before being deleted.
> > >
> > > Unfortunately, it seems the changes to support this in the CSO module
> > > provide only a single-shot usage model.  Sampler views are created in
> > > cso_set_XXX_sampler_textures, bound to the context, and then
> > > dereferenced/destroyed on the next bind.
> > >
> > >   
> > The reason CSO code looks like this is because it was meant to be an 
> > itermediate step towards migration to sampler view model. Fully 
> > converting all existing state trackers is non-trivial and thus I chose 
> > this conservative approach. State trackers that do not care about extra 
> > features a sampler view provides will keep using this one-shot CSO 
> > interface with the hope that creation of sampler objects is lighweight 
> > (format matches texture format, swizzle matches native texel layout, 
> > etc.). 
> 
> On the surface, this hope isn't likely to be fulfilled - lots of
> hardware doesn't support non-zero first_level.  Most cases of drivers
> implementing sampler views internally are to catch this issue.
> 
> Of course, it seems like your branch so leaves the existing
> driver-specific sampler view code in place, so that there are
> potentially two implementations of sampler views in those drivers.  
> 
> I guess this means that you can get away with the current implementation
> for now, but it prevents drivers actually taking advantage of the fact
> that these entities exist in the interface -- they will continue to have
> to duplicate the concept internally until the state trackers and/or CSO
> module start caching views.
> 
> > Ideally, everybody moves on and we stop using CSO for sampler 
> > views. I prefer putting my effort into incremental migration of state 
> > trackers rather than caching something that by definition doesn't need 
> > to be cached.
> 
> The CSO module exists to manage this type of caching on behalf of state
> trackers.  I would have thought that this was a sensible extension of
> the existing purpose of the CSO module.
> 
> Won't all state-trackers implementing APIs which don't expose sampler
> views to the application require essentially the same caching logic, as
> is the case with regular state?  Wouldn't it be least effort to do that
> caching once only in the CSO module?
> 
> Keith
> 

I didn't read anything about sampler view stuff, thus i can be
completely wrong here, but from driver pov i prefer having most
of the state going through create,bind,destroy pattern ie having
the CSO doing the caching.

Cheers,
Jerome

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

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

Brian Paul wrote:
> Luca Barbieri wrote:
>> I've looked into the issue, and found a workaround by looking at what
>> st_renderbuffer_alloc_storage (which is called to create the depth
>> buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does.
>>
>> Adding:
>> if(ctx) ctx->NewState |= _NEW_BUFFERS;
>>
>> at the end of st_set_framebuffer_surface seems to solve the warsow
>> problem with no other regressions.
>>
>> Brian, is this the right fix?
> 
> That's probably the right direction, but I think there's several other 
> things to be fixed in st_set_framebuffer_surface().  I'll have a patch 
> soon...

OK, here's a patch which sets that flag, and:

1. always allocates the renderbuffer if it's not already present.

2. removes the framebuffer size update code.  Core Mesa will do this 
during state validation if _NEW_BUFFERS is set.

Please test.  Thanks.

-Brian

Re: [Mesa3d-dev] extensions supported or not in gallium

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

Roland Scheidegger wrote:
> Hi,
> 
> there are currently a couple of extensions enabled in the mesa state
> tracker which probably shouldn't be. These were moved there by commit
> a0ae2ca033ec2024da1e01d1c11c0437837c031b (that is with dri they were
> already always enabled before).
> 
> Someone knows off-hand which one we can enable or not? I'm going to kill
> off EXT_cull_vertex and  TDFX_texture_compression_FXT1, clearly we can't
> handle them.
> The others in question are
> ARB_window_pos

handled in core mesa.


> APPLE_client_storage

should not be enabled by default.


> MESA_pack_invert

handled by core mesa.


> NV_vertex_program
> NV_vertex_program1_1
> 
> (the latter two IIRC the problem was that regs needed to be
> zero-initialized)

There may be other issues too.  Someone would have to enable the 
extension(s) and do some testing.


> Currently gallium dri drivers also have ARB_imaging enabled too (via
> driInitExtensions()), I think that's not correct neither.

Yeah, I think that needs to be disabled.

-Brian

[Mesa3d-dev] glapi execmem [was Re: code generation for dynamic extensions broken ?]

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

On Wed, Mar 10, 2010 at 2:18 AM, George Sapountzis
<gsa...@gm...> wrote:
>
> It turned out that there were two bugs in glapi. One with using
> non-exec memory and the other with using an un-relocated function
> template for entry-point generation. I put fixes at:
>
> Since we are already generating static dispatch stubs for all known
> extensions, I guess we can add a few more static stubs and use them,
> instead of generating on-the-fly. I put an example about this in the
> getproc-debug branch, but I don't know if it's a good idea.
>

I put a patch for using executable memory at:

http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-execmem

It just maps a single page with PROTO_EXEC and uses it as a backing
store for generated entrypoints.

Since there are many configure variables for glapi, please review and test.

The variables are mostly:
arch: x86, x86-64, sparc
threading: tls, threads, no-threads

I tested with tls on x86.

Testing means comparing libGL from getproc-debug (based on master) vs.
libGL from getproc-execmem-debug (based on getproc-execmem) and making
sure new libGL either fixes or does not regress. To build libGL:

configure ...
make -C src/mesa/ libglapi.a
make -C src/glx/
LD_PRELOAD=./lib/libGL.so.1.2 ./progs/demos/fbotexture

regards,
George.