mesa3d-dev

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

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

On Thu, Mar 18, 2010 at 12:30 PM, Tom Stellard <tst...@gm...> wrote:
> Hi,
>
> I am interested in working on the Gallium R300 driver as a part of
> Google Summer of Code.  I would like to try and target a specific game,
> probably Civilization 4, and get it working as well as possible.  I am
> interested in getting some feedback on whether or not this is a good
> goal for the summer.  In the past, I have filed bug reports and done some
> testing of the mesa drivers, but I have not spent a lot of time looking at
> the code.  Where is a good place for me to start looking through the code?
> Is there a reference Gallium driver I can look at to get a good idea of
> how the drivers are structured?

Nifty. Well, there's a few places to look for information.

If you're not sure how the actual video card works,
http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a
great starting point. Of particular interest is the 3D engine; r300g
only talks to the 3D part of the video card.

The reference Gallium driver is probably identity, although softpipe
is a good reference as well. We also have documentation for the
Gallium API and associated bits; if you don't want to build it
yourself from the Mesa tree, there should be an up-to-date copy at
http://people.freedesktop.org/~csimpson/gallium-docs/. (If there's a
problem with the documentation, lemme know!)

~ C.

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

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

[Mesa3d-dev] Google Summer of Code: we got in / call for mentors!

[Stephane M. <ste...@gm...>]

Hi,

Good news, X.Org just got accepted into the Google Summer of Code
program! Now we need mentors. If you are a developer and would like to
possibly mentor Summer of Code projects, please contact me off-list.

Thanks,
Stephane

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

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

Tom Stellard <tst...@gm...> writes:
> Where is a good place for me to start looking through the code?  Is
> there a reference Gallium driver I can look at to get a good idea of
> how the drivers are structured?

I'm sure one of the actual gallium developers can give you more
detail/correct me, but: src/gallium/drivers is where you want to start
looking.  You'll note there's an `r300' directory, which is how your
card is supported, of course.

The reference driver is in the `softpipe' subdirectory.  You can
also compare with "classic" Mesa, referred to as swrast, by building
--with-driver=xlib.

Search the archives, as well.  LunarG posted a bunch of videos from a
recent hrm... 'gallium conference', I'd guess you'd call it?  They're
probably enlightening for the current state of gallium.  I'd suggest
doing this before reading code, it's probably better higher-level
documentation.

HTH,

-tom

[Mesa3d-dev] GSOC: Gallium R300 driver

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

Hi,

I am interested in working on the Gallium R300 driver as a part of
Google Summer of Code.  I would like to try and target a specific game,
probably Civilization 4, and get it working as well as possible.  I am
interested in getting some feedback on whether or not this is a good
goal for the summer.  In the past, I have filed bug reports and done some
testing of the mesa drivers, but I have not spent a lot of time looking at
the code.  Where is a good place for me to start looking through the code?
Is there a reference Gallium driver I can look at to get a good idea of
how the drivers are structured?

Thanks.

-Tom Stellard

[Mesa3d-dev] [PATCH] Fix compile error caused by missing include dir

[Johannes O. <joh...@gm...>]

Please apply this patch.

Otherwise st:es has a compile error in st_es2.c!

Thanks.
Johannes

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Luc V. <li...@sk...>]

On Thu, Mar 18, 2010 at 01:28:28AM -0700, Corbin Simpson wrote:
> On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen <li...@sk...> wrote:
> > On Wed, Mar 17, 2010 at 12:28:39AM +0100, Luc Verhaegen wrote:
> >> Modularized dri drivers and an SDK enabled mesa tree are available in my
> >> personal git repos at http://cgit.freedesktop.org/~libv/
> >>
> >> The SDK enabled mesa tree adds to the mesa build system to create shared
> >> libraries libmesadri and libmesadricommon. It creates the relevant .pc
> >> files and installs the necessary headers include/mesa/ (and updates
> >> glcore.h). The patch is about 300 lines each time, and only adjusts the
> >> build system.
> >>
> >> The modularized drivers are fully autotooled and can be built and
> >> installed the familiar way once the dependencies are available
> >> (currently, libdrm and the dri sdk, and some driver specific libdrms for
> >> i9xx and radeon). These drivers are i810, i9xx (i915 and i965), mach64,
> >> mga, r128, radeon (also includes r200, r300 and r600), savage, sis, tdfx
> >> and unichrome.
> >>
> >> This work was done for currently 16 versions between mesa 7.0 and the
> >> freshly tagged 7.8-rc1, all were extensively and oft repeatedly built
> >> through. 5 versions were also run tested (glxinfo, glxgears) for the
> >> radeon and unichrome drivers, and the swrast driver was also tested
> >> several times. Such a large range of versions was handled to prove the
> >> long term feasability of this.
> >>
> >> This work satisfies my requirements from my "TODO: Mesa" slide from my
> >> fosdem talk, for which the slides are available at:
> >> http://people.freedesktop.org/~libv/graphics_driver_stack_(FOSDEM2010_-_slides)$
> >>
> >> This only handles the DRI part of things, gallium seems to be more in
> >> flux atm, and from what i hear, it should be easier to have modular
> >> drivers there.
> >>
> >> Comments, additions, changes?
> >>
> >> Thanks,
> >>
> >> Luc Verhaegen.
> >
> > After giving the mesa3d-dev list the opportunity to have a whole day of
> > deafening silence, maybe the other lists should join in on that fun :p
> 
> Hey Luc,
> 
> Wow. This is pretty nifty. Lots of work here, obviously. I do have a
> couple of questions, though:
> 
> ~) Did you know about or use the automake branch that Eric and I have
> had floating around for a while?

Nope, didn't know about those, is this in your personal git repos?
 
> ~) Do you think it's gonna be tenable to ship the drivers with lots of
> shared code (i915/i965, radeon/r200/r300/r600) like this? Seems like
> we might run into the situation we've got right now with the X server
> and DDX drivers, where it might be easier to move some drivers back
> in. Also (warning: sore subject!) it reminds me of the mesa/drm tree
> and the same problems with keeping code in two locations... Maybe
> that's just me.

The goal is to solve the dependency nightmare between the driver 
specific drm, libdrm, mesa and x parts. The hot and highly volatile 
interfaces are between the driver specific parts, as of course, 
developers making changes there only have to update parts of their own 
driver.

So, identify the volatile interfaces, and the more stable interfaces, 
and then isolate the volatile ones, and then you come to only one 
conclusion.

And currently the really hot interfaces are in the intel and radeon 
stacks, and without making any changes, we are quickly converging to a 
situation where the linux kernel, libdrm, xserver and mesa are 1-1 
version tied. This means that if you update anything you pretty much 
have to update most of your installation, a situation no-one wants, and 
a situation which will be highly detrimental for the linux desktop.

It either leads to throw-away installations (where you have to be lucky, 
or need to have especially backported bits, like in preloads, to be able 
to get things to work), or no graphics at all. And i am sure that that 
is not where linux should be headed, especially not when it can be 
solved this neatly and cleanly.

> As far as Gallium goes, I really wouldn't worry about it. From what I
> can tell, the people that actually care about header stability have
> been using really specific versions of the interface in their own
> shipped bundles, and there's far too much mainline work going on right
> now to really even attempt this kind of splitting. I think there's a
> total of five branches right now that will change the entire Gallium
> interface, all getting prepared for merge? Lots of churn. Gallium's
> all mix'n'match though, so it shouldn't be a big deal further down the
> road.

While it probably is not that feasible right now, the people moving 
those interfaces that much atm should keep future modularization in 
mind.

A nice example: If you disable building gallium (as all the drivers are 
still in there) and building the dri drivers (also through configure), 
then you can easily build mesa with libdrm 2.3.0. The xserver, with 
already modular xf86 drivers has exactly libdrm 2.3.0 in its 
configure.ac requirements. Surely this is a sign that modularizing the 
driver bits and posssibly (as it is all up to the driver devs then, 
while there is no such freedom of choice now) bring those bits closer 
together in a more unified stack. There are several more examples like 
this.

Thanks,

Luc Verhaegen.

[Mesa3d-dev] [PATCH] Export glXGPA symbols

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

They seem to have become hidden with the visibility changes, at least
--with-driver=xlib.

-tom

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

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

On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen <li...@sk...> wrote:
> On Wed, Mar 17, 2010 at 12:28:39AM +0100, Luc Verhaegen wrote:
>> Modularized dri drivers and an SDK enabled mesa tree are available in my
>> personal git repos at http://cgit.freedesktop.org/~libv/
>>
>> The SDK enabled mesa tree adds to the mesa build system to create shared
>> libraries libmesadri and libmesadricommon. It creates the relevant .pc
>> files and installs the necessary headers include/mesa/ (and updates
>> glcore.h). The patch is about 300 lines each time, and only adjusts the
>> build system.
>>
>> The modularized drivers are fully autotooled and can be built and
>> installed the familiar way once the dependencies are available
>> (currently, libdrm and the dri sdk, and some driver specific libdrms for
>> i9xx and radeon). These drivers are i810, i9xx (i915 and i965), mach64,
>> mga, r128, radeon (also includes r200, r300 and r600), savage, sis, tdfx
>> and unichrome.
>>
>> This work was done for currently 16 versions between mesa 7.0 and the
>> freshly tagged 7.8-rc1, all were extensively and oft repeatedly built
>> through. 5 versions were also run tested (glxinfo, glxgears) for the
>> radeon and unichrome drivers, and the swrast driver was also tested
>> several times. Such a large range of versions was handled to prove the
>> long term feasability of this.
>>
>> This work satisfies my requirements from my "TODO: Mesa" slide from my
>> fosdem talk, for which the slides are available at:
>> http://people.freedesktop.org/~libv/graphics_driver_stack_(FOSDEM2010_-_slides)$
>>
>> This only handles the DRI part of things, gallium seems to be more in
>> flux atm, and from what i hear, it should be easier to have modular
>> drivers there.
>>
>> Comments, additions, changes?
>>
>> Thanks,
>>
>> Luc Verhaegen.
>
> After giving the mesa3d-dev list the opportunity to have a whole day of
> deafening silence, maybe the other lists should join in on that fun :p

Hey Luc,

Wow. This is pretty nifty. Lots of work here, obviously. I do have a
couple of questions, though:

~) Did you know about or use the automake branch that Eric and I have
had floating around for a while?

~) Do you think it's gonna be tenable to ship the drivers with lots of
shared code (i915/i965, radeon/r200/r300/r600) like this? Seems like
we might run into the situation we've got right now with the X server
and DDX drivers, where it might be easier to move some drivers back
in. Also (warning: sore subject!) it reminds me of the mesa/drm tree
and the same problems with keeping code in two locations... Maybe
that's just me.

As far as Gallium goes, I really wouldn't worry about it. From what I
can tell, the people that actually care about header stability have
been using really specific versions of the interface in their own
shipped bundles, and there's far too much mainline work going on right
now to really even attempt this kind of splitting. I think there's a
total of five branches right now that will change the entire Gallium
interface, all getting prepared for merge? Lots of churn. Gallium's
all mix'n'match though, so it shouldn't be a big deal further down the
road.

Sorry for not speaking up sooner; it's finals week and my attention to
every single email in my box is rather limited. :3

~ C.

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

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

[Mesa3d-dev] [Bug 27150] glBlitFramebuffer defined on 64bit but not 32bit of Ubuntu with Mesa7.7

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

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





--- Comment #3 from Alan <al...@au...>  2010-03-17 21:31:15 PST ---
(In reply to comment #2)
> (In reply to comment #1)
> > Created an attachment (id=34186)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34186) [details] [details]
> > fix gl_x86_asm.py
> > 
> > This sounds like a bug to me.  The attached patch should fix it.
> > 
> > I can commit the patch if someone could help me double check the fix.
> > 
> 
> Cheers mate, I will have a go with it and let you know this patch fix it or
> not.
> 

I applied the patch to 7.8-rc1 and the symbol is there now and my program
successfully link against it on both 32bit and 64bit machine. Thanks a lot.
And other 3 functions that you put in are also in the library. 


-- 
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 27150] glBlitFramebuffer defined on 64bit but not 32bit of Ubuntu with Mesa7.7

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

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





--- Comment #2 from Alan <al...@au...>  2010-03-17 20:45:56 PST ---
(In reply to comment #1)
> Created an attachment (id=34186)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34186) [details]
> fix gl_x86_asm.py
> 
> This sounds like a bug to me.  The attached patch should fix it.
> 
> I can commit the patch if someone could help me double check the fix.
> 

Cheers mate, I will have a go with it and let you know this patch fix it or
not.


-- 
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 27150] glBlitFramebuffer defined on 64bit but not 32bit of Ubuntu with Mesa7.7

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

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





--- Comment #1 from Chia-I Wu <ol...@gm...>  2010-03-17 20:41:10 PST ---
Created an attachment (id=34186)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34186)
fix gl_x86_asm.py

This sounds like a bug to me.  The attached patch should fix it.

I can commit the patch if someone could help me double check the fix.


-- 
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] New branch to switch st/dri to st_api.h

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

Hi list,

I've created a new branch, gallium-st-api-dri, that switches st/dri from
st_public.h to st_api.h.  The branch starts with four commits that move DRI1
support to a new file, followed by 2 commits to switch st/dri to st_api.h.

My laptop has Intel 945GM so I can only test i915g.  I've done some basic tests
with progs/{demos,xdemos} and they seem to work fine.  The red/blue channels of
the demos are swapped.  But I suspect it is a bug in the pipe driver since I
observe the same issue on master branch.

Only the DRI2 path is tested.  I couldn't figure out how to disable DRI2 and
enable DRI1 in my xserver.  It would be great if someone can tell me how to do
that with Intel DDX.

The changes are bigger than I expected.  It would be great to get some
feedbacks before merging.  If everthing works fine, the current plan is to
merge it over the weekend.

-- 
ol...@Lu...

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Luc V. <li...@sk...>]

On Wed, Mar 17, 2010 at 12:28:39AM +0100, Luc Verhaegen wrote:
> Modularized dri drivers and an SDK enabled mesa tree are available in my 
> personal git repos at http://cgit.freedesktop.org/~libv/
> 
> The SDK enabled mesa tree adds to the mesa build system to create shared
> libraries libmesadri and libmesadricommon. It creates the relevant .pc 
> files and installs the necessary headers include/mesa/ (and updates 
> glcore.h). The patch is about 300 lines each time, and only adjusts the 
> build system.
> 
> The modularized drivers are fully autotooled and can be built and 
> installed the familiar way once the dependencies are available 
> (currently, libdrm and the dri sdk, and some driver specific libdrms for 
> i9xx and radeon). These drivers are i810, i9xx (i915 and i965), mach64, 
> mga, r128, radeon (also includes r200, r300 and r600), savage, sis, tdfx 
> and unichrome.
> 
> This work was done for currently 16 versions between mesa 7.0 and the 
> freshly tagged 7.8-rc1, all were extensively and oft repeatedly built 
> through. 5 versions were also run tested (glxinfo, glxgears) for the 
> radeon and unichrome drivers, and the swrast driver was also tested 
> several times. Such a large range of versions was handled to prove the 
> long term feasability of this.
> 
> This work satisfies my requirements from my "TODO: Mesa" slide from my
> fosdem talk, for which the slides are available at:
> http://people.freedesktop.org/~libv/graphics_driver_stack_(FOSDEM2010_-_slides)$
> 
> This only handles the DRI part of things, gallium seems to be more in 
> flux atm, and from what i hear, it should be easier to have modular 
> drivers there.
> 
> Comments, additions, changes?
> 
> Thanks,
> 
> Luc Verhaegen.

After giving the mesa3d-dev list the opportunity to have a whole day of 
deafening silence, maybe the other lists should join in on that fun :p

Luc Verhaegen.

[Mesa3d-dev] [Bug 27150] New: glBlitFramebuffer defined on 64bit but not 32bit of Ubuntu with Mesa7.7

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

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

           Summary: glBlitFramebuffer defined on 64bit but not 32bit of
                    Ubuntu with Mesa7.7
           Product: Mesa
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: al...@au...
                CC: al...@au...


I have built Mesa7.7 on both 32bit and 64bit Ubuntu but as I tried to link
libGL.so against my program. I got the undefined reference to glBlitFramebuffer
error on the 32bit machine but not on the 64bit machine.

I ran the command "objdump -x libGL.so" and found the glBlitFramebuffer header
on the 64bit machine but it is missing from the 32bit one.

The version of Ubuntu I tested on are 6.06 and 8.04.


-- 
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 27126] Account request for nv30/nv40 driver contributions

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

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


Brian Paul <bri...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|mesa3d-                     |sit...@li...eedesk
                   |de...@li...   |top.org
          Component|Other                       |New Accounts
            Product|Mesa                        |freedesktop.org
            Version|git                         |unspecified




--- Comment #1 from Brian Paul <bri...@gm...>  2010-03-17 15:46:07 PST ---
Approved. Re-assigning to fd.o admins.


-- 
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] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

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

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

Xavier Chantry wrote:

> Patrice also pointed me to the workaround that nvidia driver provides itself :
> http://us.download.nvidia.com/freebsd/190.42/README/chapter-09.html

Their solution is roughly analogous to a driconf variable.  I think we
should do the same.  I was initially thinking the configuration variable
should change the sorting, but now I'm thinking that it should limit the
extensions exposed.  Something like "only advertise extension from 1998
or before".  That would be even easier to implement than the alternate
sorting rule.

Perhaps someone should file an enhancement bug to track this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuhT+MACgkQX1gOwKyEAw8MGACfWQ2w6jpZ0RNkXR6F+52BbyX5
CSoAoIyo/TYsw4Cw9aCZ7qaz9rBeDPE/
=VZoU
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

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

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

Jose Fonseca wrote:

> The most worrysome thing here is not quake3 by itself, but the
> thought that other GL apps  out there may too truncate the GL
> extension string.

Yes.  I have heard other people in the ARB mention that some apps do
that.  I'm sure the games in the Quake family aren't the only ones.  I
usually hate hacks to work around app bugs, but I think that some form
of this hack is okay because there are a bunch of apps that do the wrong
thing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuhTvwACgkQX1gOwKyEAw/DbgCghoL1RB0Psh6gSjiNLndw8g7r
cBgAn0x5ZQ8hFS9CGahCZ7+n+nC5ZXOd
=MQZG
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

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

On Wed, Mar 17, 2010 at 1:01 AM, Jose Fonseca <jfo...@vm...> wrote:
> Indeed, this problems happen with Windows q3arena demo only. Ioquake3, and I believe that the latest windows full quake3 binary too, correctly handles the full extensions list.
>
> However I suspect that quake2 and earliy releases of quake3 arena and quake3 arena demo suffer from limitation.
>
> The most worrysome thing here is not quake3 by itself, but the thought that other GL apps  out there may too truncate the GL extension string.
>

Then sorry for the noise, maybe the commit could have made it a bit clearer :)

It does seem that latest version of quake 3 (and ioquake3) use a large
enough buffer of 8192.
But earlier versions of q3 might have used something as short as 512.
Unfortunately, I could not find when exactly it was fixed.

I somehow forgot the obvious fact that there are 20 or more q3 based
proprietary games
(thanks to Patrice Mandin for pointing that out)
http://en.wikipedia.org/wiki/Id_Tech_3#Uses_of_the_engine

We would need to test them all in their latest version to know which
ones are still affected and were not fixed. I could not find any
report / information about that either.

Patrice also pointed me to the workaround that nvidia driver provides itself :
http://us.download.nvidia.com/freebsd/190.42/README/chapter-09.html

Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

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

On Tue, Mar 16, 2010 at 4:32 PM, Ian Romanick <id...@fr...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jose Fonseca wrote:
>> Module: Mesa
>> Branch: mesa_7_7_branch
>> Commit: 93e77b0028170fafd176c3a80a99287343c946b4
>> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=93e77b0028170fafd176c3a80a99287343c946b4
>>
>> Author: José Fonseca <jfo...@vm...>
>> Date:   Fri Mar 12 17:59:10 2010 +0000
>>
>> mesa: List Quake3 extensions first.
>>
>> Quake3 truncates the extension string, and GL_EXT_compiled_vertex_array
>> wasn't being detected, making it very slow.
>>
>> This is a quick fix. The IMHO best way to address this in a more general
>> fashion is to sort by year.
>
> Shame on id! :)  I never understood why applications had fixed-size
> buffers to store the GL extension string.  Was the extra call to strlen
> and malloc during start-up really that expensive?!?
>

I don't really have interest in investigating further to check/verify
these claims , but this might be an answer :

21:26 <@kevlarman> oh and it's not nearly as simple as "just use malloc()"
21:27 <@kevlarman> the structure with the extensions string is passed
to the cgame and ui modules,
                   which are usually run in a sandbox without a
malloc() implementation
21:28 <@kevlarman> and even if they had it, the client has no way of
communicating to them how much
                   memory they should allocate for it to write the
extension string
21:29 < shining> kevlarman: why isnt there all freedom to change that ?
21:30 <@kevlarman> shining: because then it won't work with q3 anymore

Re: [Mesa3d-dev] Mesa 7.7.1 release candidate 1 and Mesa 7.8 release candidate 1

[Tomáš C. <sca...@ge...>]

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

Dne 16.3.2010 16:07, Ian Romanick napsal(a):
> Mesa 7.7.1-rc1 available for testing at
> ftp://freedesktop.org/pub/mesa/7.7/RC/
> 
I don't see tag in git for this one :]
(you have to push them individually O;])

Cheers

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

iEYEARECAAYFAkug/ckACgkQHB6c3gNBRYeWYgCdGDliHZLOUh5OVY7kaopoyLjX
0LgAoJqGtVLIPj07QYlK+L5g0Wgfx1Ic
=jcGR
-----END PGP SIGNATURE-----

[Mesa3d-dev] [Bug 27126] New: Account request for nv30/nv40 driver contributions

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

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

           Summary: Account request for nv30/nv40 driver contributions
           Product: Mesa
           Version: git
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: luc...@gm...


Created an attachment (id=34139)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34139)
GPG public key for Luca Barbieri

Hello,
I'd like to ask for an fdo account and commit access for nv30/nv40
contributions.
This would allow me to contribute more effectively, and push fixes in a timely
manner when possible.

I followed the instructions at http://www.freedesktop.org/wiki/AccountRequests.
Please let me know if anything is missing.

Thanks in advance,
Luca

Real name: Luca Barbieri
E-mail address: lu...@lu... (alias of luc...@gm...)
Preferred account name: lb (otherwise, lbarbieri or lucabarbieri)

SSH public key:
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAyvaK8rJvdDhcON64l4AlIt7QGStnINAQ2jZsF8h6vGwttFRM/9B/PyxoaSyKavHx4Gnfj78j+YlvnUr48lG8Ogg2SPZ4BniPWNK6eNOHy3IWVqpiEImvMLeuqrQ+bG2WkQeeVjUdcdpPlzywNBE/bRPCgUFxKgACLuCpcromMiU=
lb@lb-linux

GPG key attached.


-- 
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] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

[Jose F. <jfo...@vm...>]

Indeed, this problems happen with Windows q3arena demo only. Ioquake3, and I believe that the latest windows full quake3 binary too, correctly handles the full extensions list.

However I suspect that quake2 and earliy releases of quake3 arena and quake3 arena demo suffer from limitation.

The most worrysome thing here is not quake3 by itself, but the thought that other GL apps  out there may too truncate the GL extension string.

Jose


________________________________________
From: Xavier Chantry [cha...@gm...]
Sent: Tuesday, March 16, 2010 19:40
To: Roland Scheidegger
Cc: Keith Whitwell; Ian Romanick; Jose Fonseca; mes...@li...
Subject: Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions  first.

On Tue, Mar 16, 2010 at 7:13 PM, Roland Scheidegger <sr...@vm...> wrote:
> On 16.03.2010 18:52, Keith Whitwell wrote:
>> On Tue, 2010-03-16 at 08:32 -0700, Ian Romanick wrote:
>>
>>> I'm also a bit surprised that not detecting GL_EXT_compiled_vertex_array
>>> has any impact on our Quake3 performance.  After all, our CVA
>>> implementation doesn't do anything!  Looking at the list, it seems more
>>> likely that GL_EXT_texture_env_add is the problem.  Not having that will
>>> cause Quake3 to use additional rendering passes in quite a few cases.
>>
>> I think if CVA isn't present, it falls back to glVertex() and friends...
> Bad...
>
> I'm not sure though listing that extension first really solves all
> problems. There's a quite famous bug when you bring up the information
> with the extension string it'll actually segfault. I think though that
> got fixed in later versions (though I don't know how, if by just copying
> only the first n bytes of the extension string it obviously wouldn't
> solve the problem that it doesn't recognize the CVA extension...). And
> against this you can't really do anything other than app detection and
> cut the string appropriately...
>

As far as I know, quake 3 code was open sourced 5 years ago. Though it
sounds like we are talking about an evil proprietary game doing bad
things.
And not only it is GPL, but there is also a reference project
maintaining that code :)
http://ioquake3.org/

Now are we talking about q3 or ioq3 ? If it's q3, why do we care ?
If it's ioq3, let's figure out the issues and work together with ioq3
people to fix them.

The limit for GL_EXTENSION seems to be 8192, both for ioq3 and q3.
Is any driver really exceeding that ?

Here are the size I get :
GL_EXTENSIONS: 2385
GL_RENDERER: Gallium 0.4 on NV84
GL_EXTENSIONS: 2407
GL_RENDERER: Gallium 0.4 on llvmpipe
GL_EXTENSIONS: 3250
GL_RENDERER: Software Rasterizer

Seems to be far from the limit. And with all 3 drivers, cva is
detected and enabled fine :
compiled vertex arrays: enabled

Any information about the extension string segfault ? I never heard of
it before, and never saw it happening either.

Finally the only thing I can confirm is the big performance difference :
r_ext_compiled_vertex_array=1 : 50 fps
r_ext_compiled_vertex_array=0 : 10 fps

That last point sounds like something that could be reported and could
be easily fixed.
I hope we can progress on the other issues too :)

cheers
Xavier

[Mesa3d-dev] DRI SDK and modularized drivers.

[Luc V. <li...@sk...>]

Modularized dri drivers and an SDK enabled mesa tree are available in my 
personal git repos at http://cgit.freedesktop.org/~libv/

The SDK enabled mesa tree adds to the mesa build system to create shared
libraries libmesadri and libmesadricommon. It creates the relevant .pc 
files and installs the necessary headers include/mesa/ (and updates 
glcore.h). The patch is about 300 lines each time, and only adjusts the 
build system.

The modularized drivers are fully autotooled and can be built and 
installed the familiar way once the dependencies are available 
(currently, libdrm and the dri sdk, and some driver specific libdrms for 
i9xx and radeon). These drivers are i810, i9xx (i915 and i965), mach64, 
mga, r128, radeon (also includes r200, r300 and r600), savage, sis, tdfx 
and unichrome.

This work was done for currently 16 versions between mesa 7.0 and the 
freshly tagged 7.8-rc1, all were extensively and oft repeatedly built 
through. 5 versions were also run tested (glxinfo, glxgears) for the 
radeon and unichrome drivers, and the swrast driver was also tested 
several times. Such a large range of versions was handled to prove the 
long term feasability of this.

This work satisfies my requirements from my "TODO: Mesa" slide from my
fosdem talk, for which the slides are available at:
http://people.freedesktop.org/~libv/graphics_driver_stack_(FOSDEM2010_-_slides)$

This only handles the DRI part of things, gallium seems to be more in 
flux atm, and from what i hear, it should be easier to have modular 
drivers there.

Comments, additions, changes?

Thanks,

Luc Verhaegen.

[Mesa3d-dev] [Bug 27090] xorg_crtc.c won't compile because of change in libdrm

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

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





--- Comment #2 from Martin Stolpe <mar...@gm...>  2010-03-16 13:55:19 PST ---
Hm, strange git describe shows me the following line:
 mesa_7_6_1_rc1-2402-ga0518e6
I was using the master branch.

Switching to the mesa_7_7_branch didn't help.

After deleting the source directory and creating a new checkout I get the
following line:
 mesa_7_6_1_rc1-6259-g5782b2a
And now it compiles. Really strange.


-- 
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] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

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

On Tue, Mar 16, 2010 at 7:13 PM, Roland Scheidegger <sr...@vm...> wrote:
> On 16.03.2010 18:52, Keith Whitwell wrote:
>> On Tue, 2010-03-16 at 08:32 -0700, Ian Romanick wrote:
>>
>>> I'm also a bit surprised that not detecting GL_EXT_compiled_vertex_array
>>> has any impact on our Quake3 performance.  After all, our CVA
>>> implementation doesn't do anything!  Looking at the list, it seems more
>>> likely that GL_EXT_texture_env_add is the problem.  Not having that will
>>> cause Quake3 to use additional rendering passes in quite a few cases.
>>
>> I think if CVA isn't present, it falls back to glVertex() and friends...
> Bad...
>
> I'm not sure though listing that extension first really solves all
> problems. There's a quite famous bug when you bring up the information
> with the extension string it'll actually segfault. I think though that
> got fixed in later versions (though I don't know how, if by just copying
> only the first n bytes of the extension string it obviously wouldn't
> solve the problem that it doesn't recognize the CVA extension...). And
> against this you can't really do anything other than app detection and
> cut the string appropriately...
>

As far as I know, quake 3 code was open sourced 5 years ago. Though it
sounds like we are talking about an evil proprietary game doing bad
things.
And not only it is GPL, but there is also a reference project
maintaining that code :)
http://ioquake3.org/

Now are we talking about q3 or ioq3 ? If it's q3, why do we care ?
If it's ioq3, let's figure out the issues and work together with ioq3
people to fix them.

The limit for GL_EXTENSION seems to be 8192, both for ioq3 and q3.
Is any driver really exceeding that ?

Here are the size I get :
GL_EXTENSIONS: 2385
GL_RENDERER: Gallium 0.4 on NV84
GL_EXTENSIONS: 2407
GL_RENDERER: Gallium 0.4 on llvmpipe
GL_EXTENSIONS: 3250
GL_RENDERER: Software Rasterizer

Seems to be far from the limit. And with all 3 drivers, cva is
detected and enabled fine :
compiled vertex arrays: enabled

Any information about the extension string segfault ? I never heard of
it before, and never saw it happening either.

Finally the only thing I can confirm is the big performance difference :
r_ext_compiled_vertex_array=1 : 50 fps
r_ext_compiled_vertex_array=0 : 10 fps

That last point sounds like something that could be reported and could
be easily fixed.
I hope we can progress on the other issues too :)

cheers
Xavier