headers
Petri.Lipponen | 2 May 2003 08:52
Picon
Picon
Favicon

Re: dynamic OSMesa usage

At 09:27 30.4.2003 -0600, Brian Paul wrote:

>>So far I've got as far as trying to compile the extgl.c with Mesa.
>>The result was less than perfect with a huge pile of:
>>c:\Projects\NCA\Framework\UtilityLib\ExtGL\extgl.c(133) : error C2061: 
>>syntax error : identifier 'glDrawRangeElements'
>>c:\Projects\NCA\Framework\UtilityLib\ExtGL\extgl.c(133) : error C2059: 
>>syntax error : ';'
>>c:\Projects\NCA\Framework\UtilityLib\ExtGL\extgl.c(133) : error C2513: 
>>'/*global*/ ' : no variable declared before '='
>>for each extension function since OpenGL1.2.
>>If anyone on the list have done anything similar or has any idea
>>of the function-problems above, I would be more than happy to hear about it.
>
>Is the code for extgl.c readily available?  It's hard to say what the 
>problem is just from those error messages.

Sorry, Of course I forgot to put the link to extgl. It's a small LGPL'd 
helper that handles the tedious extension stuff. You can find it here if 
you're interested...

http://www.levp.de/3d/

I think I forgot to mention, that the extgl did work fine with the default 
GL/gl.h (the one that came with the VC7 platformSDK). As soon as I add 
"Mesa-5.0.1/includes" to the include path, I start to get the problems. 
I'll try to contact the ExtGL maintainer, and ask him if he has any insight.

Thanks,
(Continue reading)

Permalink | Reply | 1 comment |
headers
indrek | 2 May 2003 12:19
Picon

Developer: maybe I can too...

Hi!
Shortly:
- I wrote simple OpenGL (presentation) programs in plain C for one SGI Indigo2IMPACT couple of years ago
- from this time I am interested in advancements in Mesa development
- I love gcc 3.x and the possibility to play with SSE code
- I do programming with oracle and python in daily basis
- I have not any fancy software project to mess with at moment
- recently I got one cheap 845GE and Celeron 1.7GHz. btw, this is quite a suitable platform in terms of
integrated stuff.
- maybe I can help someone here to test and implement some ideas (especially with x86 SSE)?

Thank you,
Indrek
http://www.tuleriit.ee

-----------------------------------------
Hot Mobiil - helinad, logod ja piltsõnumid!
http://portal.hot.ee

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 1 comment |
headers
Jakub Jelinek | 2 May 2003 12:46
Picon
Favicon

[PATCH] A bunch of libGL.so optimizations

Hi!

Finally got to write some optimizations I meant to write for quiet some time
for libGL.so.
Note that I'm not a GL person, but a tools person, so I'd appreciate
hearing from you all about where the current GL bottlenecks are.

The primary reason why I decided to do something about this is that
as libGL.so on IA-32 is commonly built without -fpic, my prelink(8) tool
cannot optimize any binaries and libraries linked against libGL.so
(since libGL.so is DT_TEXTREL and there are some prelink conflicts
against the read-only segment needed), and since e.g. most of the KDE stuff
in RHL is linked against libGL.so (although it often is not used at all),
it means almost no KDE program can be prelinked.
In addition to that, current libGL.so on my box has 12272 (+2 lazy) dynamic
relocations which need to be resolved at each program startup, and
also because of DT_TEXTREL almost whole libGL.so memory image is
non-shareable between processes (my guess is something like 400k
per process non-shareable).
In the past, I've been told BuildLibGlxWithoutPIC is needed because
otherwise performance sucks. So this patch tries to deal with the
performance side as well.
The end result is that the number of dynamic relocations went down
to 1803 (+66 lazy) or, in the TLS version to 1110 (+63 lazy),
libGL.so is no longer DT_TEXTREL and thus prelinkable and its size shrunk
from ~ 450k stripped to ~250k stripped.

The patch is against XFree86-4.3.0 (particularly Red Hat
XFree86-4.3.0-6.src.rpm), so it will likely not apply 100% cleanly against
other trees, but I hope should be usable as starting point at least for the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Evgeny Kotsuba | 2 May 2003 13:25
Picon
Favicon

embed status

Hi, 
what is status of embed Mesa ?
Where is it ? (i.e. is it  embedded-1-branch   or something else ?)

Is it linux-only and/or  X-only project ?

In part, what is 

embed-1/src/kernel
embed-1/src/drv
embed-1/src/fbdev
embed-1/src/miniglu
embed-1/src/miniglut

stand for ?

What chips are supported by  embed-1/src/drv ?
If there are some readmes then I don't ask...

SY,
Evgeny Kotsuba

___________________
Лучшие туры на ближайшие даты. Сеть магазинов
горящих путевок.
www.tournews.ru

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Klaus Niederkrueger | 2 May 2003 14:08
Picon

tnl-questions

Hi,

I'm writing a bit of documentation for the tnl-module in Mesa, and I
wonder about several things:

Why is the _tnl_run_pipeline embedded into the Driver-struct? Couldn't it
be called directly. I mean, it seems to be a function called only from
within the tnl-module itself and what it does seems to be quite generic.
The pipeline_stages can be changed without changing the _tnl_run_pipeline
function...

In tnlBegin function there is a check if the immediate is almost full, and
if it is, the immediate is flushed. Wouldn't it be "conceptually cleaner"
to do this check in tnlEnd. Right now, it may be the same, but somehow it
"feels better" to flush things as soon as possible...

I had other questions, but I have forgotten them. I will write them down
next time...

Thanks

        Klaus

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 12 comments |
headers
Keith Whitwell | 2 May 2003 14:39

Re: tnl-questions

Klaus Niederkrueger wrote:
> Hi,
> 
> I'm writing a bit of documentation for the tnl-module in Mesa, and I
> wonder about several things:
> 
> Why is the _tnl_run_pipeline embedded into the Driver-struct? Couldn't it
> be called directly. I mean, it seems to be a function called only from
> within the tnl-module itself and what it does seems to be quite generic.
> The pipeline_stages can be changed without changing the _tnl_run_pipeline
> function...

This is to allow drivers an opportunity to wrap pipeline execution with their 
own code.  Previously we had 'PipelineStart' and 'PipelineFinish' (or similar) 
but wrapping it turned out to be more flexible.

> In tnlBegin function there is a check if the immediate is almost full, and
> if it is, the immediate is flushed. Wouldn't it be "conceptually cleaner"
> to do this check in tnlEnd. Right now, it may be the same, but somehow it
> "feels better" to flush things as soon as possible...

You could do it either place.  Since we have a lot of other checks in Begin, I 
prefer to do it there.

> I had other questions, but I have forgotten them. I will write them down
> next time...

Nice to see people reading the code.

Keith
(Continue reading)

Permalink | Reply | 11 comments |
headers
Brian Paul | 2 May 2003 16:57

Re: Developer: maybe I can too...

indrek wrote:
> Hi!
> Shortly:
> - I wrote simple OpenGL (presentation) programs in plain C for one SGI Indigo2IMPACT couple of years ago
> - from this time I am interested in advancements in Mesa development
> - I love gcc 3.x and the possibility to play with SSE code
> - I do programming with oracle and python in daily basis
> - I have not any fancy software project to mess with at moment
> - recently I got one cheap 845GE and Celeron 1.7GHz. btw, this is quite a suitable platform in terms of
integrated stuff.
> - maybe I can help someone here to test and implement some ideas (especially with x86 SSE)?
> 

Mesa has some SSE vertex transformation code.  But I'm not sure if it's as 
efficient as it could be.  Perhaps you could look at optimizing it.

Another fun project might be dynamically generating SSE code to implement 
vertex programs (GL_NV_vertex_program and GL_ARB_vertex_program).

-Brian

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Brian Paul | 2 May 2003 17:03

Re: dynamic OSMesa usage

Petri.Lipponen <at> iki.fi wrote:
> At 09:27 30.4.2003 -0600, Brian Paul wrote:
> 
>>> So far I've got as far as trying to compile the extgl.c with Mesa.
>>> The result was less than perfect with a huge pile of:
>>> c:\Projects\NCA\Framework\UtilityLib\ExtGL\extgl.c(133) : error 
>>> C2061: syntax error : identifier 'glDrawRangeElements'
>>> c:\Projects\NCA\Framework\UtilityLib\ExtGL\extgl.c(133) : error 
>>> C2059: syntax error : ';'
>>> c:\Projects\NCA\Framework\UtilityLib\ExtGL\extgl.c(133) : error 
>>> C2513: '/*global*/ ' : no variable declared before '='
>>> for each extension function since OpenGL1.2.
>>> If anyone on the list have done anything similar or has any idea
>>> of the function-problems above, I would be more than happy to hear 
>>> about it.
>>
>>
>> Is the code for extgl.c readily available?  It's hard to say what the 
>> problem is just from those error messages.
> 
> 
> Sorry, Of course I forgot to put the link to extgl. It's a small LGPL'd 
> helper that handles the tedious extension stuff. You can find it here if 
> you're interested...
> 
> http://www.levp.de/3d/
> 
> I think I forgot to mention, that the extgl did work fine with the 
> default GL/gl.h (the one that came with the VC7 platformSDK). As soon as 
> I add "Mesa-5.0.1/includes" to the include path, I start to get the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jakub Jelinek | 3 May 2003 00:04
Picon
Favicon

Re: [PATCH] A bunch of libGL.so optimizations

On Fri, May 02, 2003 at 12:46:03PM +0200, Jakub Jelinek wrote:
> Finally got to write some optimizations I meant to write for quiet some time
> for libGL.so.

During full rpm build I found a couple of minor things, so I've updated
the patch and put it at
ftp://people.redhat.com/jakub/XFree86/XFree86-4.3.0-libGL-opt.patch
and also put in the same location RHL rpms with this patch applied.

	Jakub

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 1 comment |
headers
Denis Oliver Kropp | 3 May 2003 12:22

Re: embed status

Quoting Evgeny Kotsuba (evgen__k <at> rambler.ru):
> Hi, 
> what is status of embed Mesa ?

It's already running pretty well on top of the linux framebuffer device
using the builtin MiniGLX. But it has no input or real windowing support yet.

With my recent changes that I'm about to post this weekend you are also
able to use it on top of DirectFB (with windowing and input).
See http://www.directfb.org/ for a screenshot.

> Where is it ? (i.e. is it  embedded-1-branch   or something else ?)

That's correct.

> Is it linux-only and/or  X-only project ?

It's linux only, but it could be ported to other systems.

> In part, what is 
> 
> embed-1/src/kernel

These are the modified drm kernel modules.

> embed-1/src/drv

These are the user space OpenGL drivers.

> embed-1/src/fbdev
(Continue reading)

Permalink | Reply | 3 comments |

Gmane