mesa3d-dev

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

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

Thanks!

Cheers Jakob.

On Wed, Mar 24, 2010 at 9:28 PM, STEVE555 <ste...@ho...> wrote:
>
> Hi Jakob,
>             I've tried out your gallium-targets branch with ./autogen.sh
> and my configure options added to it.After a recompile and a re-boot,there
> were no compile breakages and no real ill-affects after a re-boot.
>
> I also tried out merging my copy of the Mesa master branch into my copy of
> your gallium-targets branch.I used ./autogen.sh with my configure options
> again,and there were no compile breakages and no ill-effects after a
> re-compile and a re-boot.
>
> I compile the nouveau drivers myself,so I can't speak for others who compile
> mesa for their different hardware.
> Regards,
>             STEVE555
>
> Jakob Bornecrantz wrote:
>>
>> Hi all
>>
>> Can people please try out the gallium-targets branch I like to merge
>> that as soon as possible.
>>
>> Also you will need to run autogen.sh if you switch to this branch.
>>
>> The branch moves all target like directories from the winsys directory
>> into the targets directory this the dri/xorg/egl directories in
>> src/gallium/winsys/drm/*/. It also reorganizes the winsys directory so
>> that the first level says which winsys it exposes the second which
>> type.
>>
>> Example:
>> winsys/drm/radeon/core -> winsys/radeon/drm
>> winsys/drm/radeon/dri -> targets/dri-radeong
>> winsys/drm/radeon/egl -> targets/egl-radeon
>> winsys/drm/radeon/xorg -> targets/xorg-radeon
>>
>> Bad things still left:
>> winsys/i965/xlib should probably be split up into a target and winsys.
>> winsys/g3dvl/* as well (tho this might be dead on the master branch).
>>
>> As far as I know things should not have regressed.
>>
>> Cheers Jakob.
>>
>> ------------------------------------------------------------------------------
>> 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/-RFC--gallium-targets-merge-tp28019425p28021629.html
> Sent from the mesa3d-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
>

[Mesa3d-dev] Separate demos repository

[Eric A. <er...@an...>]

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

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

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

Hi Jakob,
             I've tried out your gallium-targets branch with ./autogen.sh
and my configure options added to it.After a recompile and a re-boot,there
were no compile breakages and no real ill-affects after a re-boot.

I also tried out merging my copy of the Mesa master branch into my copy of
your gallium-targets branch.I used ./autogen.sh with my configure options
again,and there were no compile breakages and no ill-effects after a
re-compile and a re-boot.

I compile the nouveau drivers myself,so I can't speak for others who compile
mesa for their different hardware.
Regards,
             STEVE555

Jakob Bornecrantz wrote:
> 
> Hi all
> 
> Can people please try out the gallium-targets branch I like to merge
> that as soon as possible.
> 
> Also you will need to run autogen.sh if you switch to this branch.
> 
> The branch moves all target like directories from the winsys directory
> into the targets directory this the dri/xorg/egl directories in
> src/gallium/winsys/drm/*/. It also reorganizes the winsys directory so
> that the first level says which winsys it exposes the second which
> type.
> 
> Example:
> winsys/drm/radeon/core -> winsys/radeon/drm
> winsys/drm/radeon/dri -> targets/dri-radeong
> winsys/drm/radeon/egl -> targets/egl-radeon
> winsys/drm/radeon/xorg -> targets/xorg-radeon
> 
> Bad things still left:
> winsys/i965/xlib should probably be split up into a target and winsys.
> winsys/g3dvl/* as well (tho this might be dead on the master branch).
> 
> As far as I know things should not have regressed.
> 
> Cheers Jakob.
> 
> ------------------------------------------------------------------------------
> 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/-RFC--gallium-targets-merge-tp28019425p28021629.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

[Eric A. <er...@an...>]

On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf <kri...@gm...> wrote:
> Brian,
> 
> that was fast! Who do you think I should bug, to get these working on i965?
> 
> Also as my time allows, I am planning to extend them with mouse input
> for orientation and arrow keys for moving to camera to become more
> interactive.

Make a testcase for piglit, and I'd love to fix your bug.

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

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

Hi all

Can people please try out the gallium-targets branch I like to merge
that as soon as possible.

Also you will need to run autogen.sh if you switch to this branch.

The branch moves all target like directories from the winsys directory
into the targets directory this the dri/xorg/egl directories in
src/gallium/winsys/drm/*/. It also reorganizes the winsys directory so
that the first level says which winsys it exposes the second which
type.

Example:
winsys/drm/radeon/core -> winsys/radeon/drm
winsys/drm/radeon/dri -> targets/dri-radeong
winsys/drm/radeon/egl -> targets/egl-radeon
winsys/drm/radeon/xorg -> targets/xorg-radeon

Bad things still left:
winsys/i965/xlib should probably be split up into a target and winsys.
winsys/g3dvl/* as well (tho this might be dead on the master branch).

As far as I know things should not have regressed.

Cheers Jakob.

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

[RALOVICH, K. <kri...@gm...>]

On Wed, Mar 24, 2010 at 13:52, Ian Romanick <id...@fr...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> RALOVICH wrote:
>> Brian,
>>
>> that was fast! Who do you think I should bug, to get these working on i965?
>
> As always, if you find a bug, submit a bug report:
>
> http://intellinuxgraphics.org/how_to_report_bug.html
>
> Anything else will get lost and / or forgotten.

My first mail lists the active bug reports I opened for these. Please
refer to that e-mail.

Kristof

>
>> Also as my time allows, I am planning to extend them with mouse input
>> for orientation and arrow keys for moving to camera to become more
>> interactive.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuqUWwACgkQX1gOwKyEAw/CzwCfYLs2tg4tQ74xD1LScZ3QP6NE
> /goAn2kzMPsZC7gXIIl+amfzkMJ6MN0m
> =p5Ud
> -----END PGP SIGNATURE-----
>

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

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

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

RALOVICH wrote:
> Brian,
> 
> that was fast! Who do you think I should bug, to get these working on i965?

As always, if you find a bug, submit a bug report:

http://intellinuxgraphics.org/how_to_report_bug.html

Anything else will get lost and / or forgotten.

> Also as my time allows, I am planning to extend them with mouse input
> for orientation and arrow keys for moving to camera to become more
> interactive.

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

iEYEARECAAYFAkuqUWwACgkQX1gOwKyEAw/CzwCfYLs2tg4tQ74xD1LScZ3QP6NE
/goAn2kzMPsZC7gXIIl+amfzkMJ6MN0m
=p5Ud
-----END PGP SIGNATURE-----

[Mesa3d-dev] [Bug 27286] Mod function returns wrong value

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

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





--- Comment #4 from Brian Paul <bri...@gm...>  2010-03-24 08:37:42 PST ---
OK, looks like I wasn't running w/ X86/SSE codegen enabled.  Looks like a bug
in that code.  I'll try to take a look in a while.


-- 
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] demos: import GLSL raytracing demos

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

RALOVICH wrote:
> Brian,
> 
> that was fast! Who do you think I should bug, to get these working on i965?

Eric Anholt has been working on the i965 driver.  I wouldn't bug him 
too much though.  He's pretty busy.


> Also as my time allows, I am planning to extend them with mouse input
> for orientation and arrow keys for moving to camera to become more
> interactive.

OK, ignore my other msg then.

-Brian

> 
> Thanks,
> Kristof
> 
> 
> 
> On Wed, Mar 24, 2010 at 11:04, Brian Paul <br...@vm...> wrote:
>> RALOVICH wrote:
>>> Attached patch adds to glsl demos to mesa. If the drivers support
>>> them, these might give better performance numbers than glxgears.
>>>
>>> Currently both works fine with swrast, but neither works on i965.
>>>
>>> Corresponding active bug reports:
>>> https://bugs.freedesktop.org/show_bug.cgi?id=26691
>>> https://bugs.freedesktop.org/show_bug.cgi?id=27060
>>>
>>> Please apply!
>> Done, with minor fixes.  Thanks!
>>
>> -Brian
>>
>>

[Mesa3d-dev] [Bug 27286] Mod function returns wrong value

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

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





--- Comment #3 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-24 08:13:10 PST ---
(In reply to comment #2)
> Can you provide a stand-alone test program that demonstrates this?
> 
> I tried it myself and I got the expected result: mod(4.0, 2.0) returns 0.0
> 
> Mesa's mod() function is implemented just as the spec says:
> 
> float mod(const float a, const float b)
> {
>     float oneOverB;
>     __asm float_rcp oneOverB, b;
>     __retVal = a - b * floor(a * oneOverB);
> }
> 

Hi Brian,

  Could you try running the program against the library in lib/gallium.
export LD_LIBRARY_PATH=<blah>/Mesa-7.7/lib/gallium

The test passes when the following is set
export LD_LIBRARY_PATH=<blah>/Mesa-7.7/lib/

Thanks


-- 
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] demos: import GLSL raytracing demos

[RALOVICH, K. <kri...@gm...>]

Brian,

that was fast! Who do you think I should bug, to get these working on i965?

Also as my time allows, I am planning to extend them with mouse input
for orientation and arrow keys for moving to camera to become more
interactive.

Thanks,
Kristof



On Wed, Mar 24, 2010 at 11:04, Brian Paul <br...@vm...> wrote:
> RALOVICH wrote:
>>
>> Attached patch adds to glsl demos to mesa. If the drivers support
>> them, these might give better performance numbers than glxgears.
>>
>> Currently both works fine with swrast, but neither works on i965.
>>
>> Corresponding active bug reports:
>> https://bugs.freedesktop.org/show_bug.cgi?id=26691
>> https://bugs.freedesktop.org/show_bug.cgi?id=27060
>>
>> Please apply!
>
> Done, with minor fixes.  Thanks!
>
> -Brian
>
>

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

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

RALOVICH wrote:
> Attached patch adds to glsl demos to mesa. If the drivers support
> them, these might give better performance numbers than glxgears.
> 
> Currently both works fine with swrast, but neither works on i965.
> 
> Corresponding active bug reports:
> https://bugs.freedesktop.org/show_bug.cgi?id=26691
> https://bugs.freedesktop.org/show_bug.cgi?id=27060
> 
> Please apply!

Done, with minor fixes.  Thanks!

-Brian

[Mesa3d-dev] [Bug 27286] Mod function returns wrong value

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

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





--- Comment #2 from Brian Paul <bri...@gm...>  2010-03-24 07:53:33 PST ---
Can you provide a stand-alone test program that demonstrates this?

I tried it myself and I got the expected result: mod(4.0, 2.0) returns 0.0

Mesa's mod() function is implemented just as the spec says:

float mod(const float a, const float b)
{
    float oneOverB;
    __asm float_rcp oneOverB, b;
    __retVal = a - b * floor(a * oneOverB);
}


-- 
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] Build Error with Xorg State Tracker

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

Dear Jakob,
                 I did a ./autogen.sh and Mesa builds fine now,sorry about
that.I do run ./autogen.sh from time to time,I just thought ./configure
would be enough,oh well,I like to thank you for your help.

Regards,
            STEVE555

STEVE555 wrote:
> 
> Hi everyone,
>                  I pulled the latest commits from the git repository last
> night and did a gmake -B realclean,and did ./configure with these 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 --enable-debug
> 
> I then ran gmake,but when the build gets to the xorg state-tracker,I keep
> hitting this error:
> 
> gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/xorg'
> gmake[4]: Entering directory `/opt/mesa/src/gallium/state_trackers/glx'
> gmake[5]: Entering directory
> `/opt/mesa/src/gallium/state_trackers/glx/xlib'
> rm -f depend
> touch depend
> /usr/bin/makedepend -fdepend
> -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include -I.
> -I../../../../../src/gallium/include
> -I../../../../../src/gallium/auxiliary
> -I../../../../../src/gallium/drivers -I../../../../../include
> -I../../../../../src/mesa @X11_CFLAGS@ glx_api.c glx_getproc.c
> glx_usefont.c xm_api.c xm_st.c    2> /dev/null
> gmake[5]: Leaving directory
> `/opt/mesa/src/gallium/state_trackers/glx/xlib'
> gmake[5]: Entering directory
> `/opt/mesa/src/gallium/state_trackers/glx/xlib'
> gcc -c -I. -I../../../../../src/gallium/include
> -I../../../../../src/gallium/auxiliary
> -I../../../../../src/gallium/drivers -I../../../../../include
> -I../../../../../src/mesa @X11_CFLAGS@ -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  glx_api.c -o glx_api.o
> gcc: @X11_CFLAGS@: No such file or directory
> gmake[5]: *** [glx_api.o] Error 1
> gmake[5]: Leaving directory
> `/opt/mesa/src/gallium/state_trackers/glx/xlib'
> gmake[4]: *** [subdirs] Error 1
> gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/glx'
> gmake[3]: *** [subdirs] Error 1
> gmake[3]: Leaving directory `/opt/mesa/src/gallium/state_trackers'
> gmake[2]: *** [default] Error 1
> gmake[2]: Leaving directory `/opt/mesa/src/gallium'
> gmake[1]: *** [subdirs] Error 1
> gmake[1]: Leaving directory `/opt/mesa/src'
> gmake: *** [default] Error 1
> 
> Regards,
>              STEVE555
> 

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

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

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

On Wed, Mar 24, 2010 at 1:43 PM, STEVE555 <ste...@ho...> wrote:
>
> Hi everyone,
>                 I pulled the latest commits from the git repository last
> night and did a gmake -B realclean,and did ./configure with these options:

Re-run autogen.sh

Cheers Jakob.

[Mesa3d-dev] Build Error with Xorg State Tracker

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

Hi everyone,
                 I pulled the latest commits from the git repository last
night and did a gmake -B realclean,and did ./configure with these 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 --enable-debug

I then ran gmake,but when the build gets to the xorg state-tracker,I keep
hitting this error:

gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/xorg'
gmake[4]: Entering directory `/opt/mesa/src/gallium/state_trackers/glx'
gmake[5]: Entering directory `/opt/mesa/src/gallium/state_trackers/glx/xlib'
rm -f depend
touch depend
/usr/bin/makedepend -fdepend -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include
-I. -I../../../../../src/gallium/include
-I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers
-I../../../../../include -I../../../../../src/mesa @X11_CFLAGS@ glx_api.c
glx_getproc.c glx_usefont.c xm_api.c xm_st.c    2> /dev/null
gmake[5]: Leaving directory `/opt/mesa/src/gallium/state_trackers/glx/xlib'
gmake[5]: Entering directory `/opt/mesa/src/gallium/state_trackers/glx/xlib'
gcc -c -I. -I../../../../../src/gallium/include
-I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers
-I../../../../../include -I../../../../../src/mesa @X11_CFLAGS@ -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  glx_api.c -o
glx_api.o
gcc: @X11_CFLAGS@: No such file or directory
gmake[5]: *** [glx_api.o] Error 1
gmake[5]: Leaving directory `/opt/mesa/src/gallium/state_trackers/glx/xlib'
gmake[4]: *** [subdirs] Error 1
gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/glx'
gmake[3]: *** [subdirs] Error 1
gmake[3]: Leaving directory `/opt/mesa/src/gallium/state_trackers'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/opt/mesa/src/gallium'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/opt/mesa/src'
gmake: *** [default] Error 1

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

[Mesa3d-dev] [Bug 27286] Mod function returns wrong value

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

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


Karthik Hariharakrishnan <kar...@ar...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|All                         |Linux (All)
           Platform|Other                       |x86 (IA32)
            Version|unspecified                 |7.6




--- Comment #1 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-24 04:41:43 PST ---
Changing the version of Mesa, Hardware and OS info in 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 23884] Unigine Tropics demo requires GL_ARB_half_float_vertex

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

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





--- Comment #9 from Artem S. Tashkinov <t....@ma...>  2010-03-24 04:37:49 PST ---
Unigine Heaven v2.0 demo/benchmark is out and also requires this extension in
order to run.


-- 
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 27286] New: Mod function returns wrong value

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

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

           Summary: Mod function returns wrong value
           Product: Mesa
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: kar...@ar...


The following shader returns incorrect output. It looks like the GLSL Compiler
doesnt implement mod correctly.

varying vec var1;
void main (void)
{
        gl_FragColor = vec4(mod(4.0, 2.0), 0.0, 0.0, 1.0);
}

It should be the same as,

varying vec var1;
void main (void)
{
        float var = 4.0 - (2.0 * (floor(4.0/2.0)) ); //According to spec
        gl_FragColor = vec4(0.0, 0.0, 0.0, 1.0);
}


-- 
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] Rationale of gallium-resources changes?

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

What is the rationale behind the gallium-resources changes?

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?

In addition to these micro-level issues, is the bigger picture
unification of buffers and textures as resources a good idea?
It will burden all buffer operations with redundant notions of 3D
boxes, strides, formats and texture targets.

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

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

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.

[Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

[RALOVICH, K. <kri...@gm...>]

Attached patch adds to glsl demos to mesa. If the drivers support
them, these might give better performance numbers than glxgears.

Currently both works fine with swrast, but neither works on i965.

Corresponding active bug reports:
https://bugs.freedesktop.org/show_bug.cgi?id=26691
https://bugs.freedesktop.org/show_bug.cgi?id=27060

Please apply!

Thanks,
Kristof

Re: [Mesa3d-dev] Current tinderbox regression (xeglthreads)

[Chris B. <cj...@la...>]

Hi,

   > I've made xeglthreads link against -lpthread.  Hope it fixes the
   > issue in next build round.

Looks like it did, thanks very much.  All of the tinderbox machines
are passing the mesa build successfully now.

- Chris.
-- 
Chris Ball   <cj...@la...>
One Laptop Per Child

Re: [Mesa3d-dev] Current tinderbox regression (xeglthreads)

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

On Wed, Mar 24, 2010 at 4:25 AM, Dan Nicholson <dbn...@gm...> wrote:
> On Tue, Mar 23, 2010 at 12:27 PM, Chris Ball <cj...@la...> wrote:
>> http://tinderbox.x.org/builds/2010-03-23-0034/logs/libGL/#build
>> /usr/bin/ld: xeglthreads.o: undefined reference to symbol 'pthread_join@@GLIBC_2.0'
>> /usr/bin/ld: note: 'pthread_join@@GLIBC_2.0' is defined in DSO /lib/libpthread.so.0 so try adding it to the linker command line
>> /lib/libpthread.so.0: could not read symbols: Invalid operation
>> collect2: ld returned 1 exit status
>> gmake[2]: *** [xeglthreads] Error 1
>> This error started after upgrading one of the build machines to Fedora
>> 14 (Rawhide).  Any ideas?
> We have a hack in the xdemos directory to link the programs with
> -lpthread for the same reason (I think). Probably need to carry that
> hack to the progs/egl directory for xeglthreads, too.
I've made xeglthreads link against -lpthread.  Hope it fixes the issue in
next build round.

-- 
ol...@Lu...

Re: [Mesa3d-dev] Segfault on glClear of non-existent stencil buffer caused by bd1ce874728c06d08a1f9881f51edbdd2f1c9db0

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

On Wed, Mar 24, 2010 at 12:56 AM, Brian Paul <br...@vm...> wrote:
>> The problem seems to be in st_manager.c:
>>   if (visual->depth_stencil_format != PIPE_FORMAT_NONE) {
>>      mode->haveDepthBuffer = GL_TRUE;
>>      mode->haveStencilBuffer = GL_TRUE;
>>
>>      mode->depthBits =
>>         util_format_get_component_bits(visual->depth_stencil_format,
>>               UTIL_FORMAT_COLORSPACE_ZS, 0);
>>      mode->stencilBits =
>>         util_format_get_component_bits(visual->depth_stencil_format,
>>               UTIL_FORMAT_COLORSPACE_ZS, 1);
>>   }
>>
>> This sets haveStencilBuffer even for depth-only buffers.
Yes, I think this is the root cause.  Thanks for looking into and fixing it.
>> How about fixing this to set haveDepthBuffer and haveStencilBuffer
>> only if bits > 0, and later removing haveStencilBuffer,
>> haveDepthBuffer and haveAccumBuffer in favor of just testing the *bits
>> counterparts?
> The haveDepth/Stencil fields come from the original SGI GLX.  We should
> probably just test the number of bits in Mesa, as you say. Want to make a
> patch for that?
>> BTW, what if we have a floating-point depth buffer, or, say, a shared
>> exponent floating-point color buffer? How do we represent that with
>> the visual structure?
> Those things came along after the SGI GLX release.  They'd have to be added
> to __GLcontextModes.
>> Shouldn't we be using the actual formats instead of this *bits stuff,
>> maybe by having Mesa look at its internal structures instead of a
>> GLXVisual-like struct?
> yeah, probably.  I'd have to study it for a while.
That sounds good.  Many fields of __GLcontextModes are of no interest in Mesa
core.  It might make some sense not to store __GLcontextModes in the contexts
and the framebuffers after creation.

-- 
ol...@Lu...

Re: [Mesa3d-dev] Current tinderbox regression (dri: fix dri_test.c for non-TLS build)

[Chris B. <cj...@la...>]

Hi Luca,

   > According to the logs, that build was not based on that commit,
   > which instead actually fixes that issue.
   > 
   > http://tinderbox.x.org/builds/2010-03-23-0040/ was actually the
   > first tinderbox build using that, and it went past that issue to
   > fail on xeglthreads problem, which is unrelated.

Thanks!  You're right, this one's fixed on the latest run.

- Chris.
-- 
Chris Ball   <cj...@la...>
One Laptop Per Child