I am attempting to recompile DRI on my newly
configured Mandrake 9.0 system..
but it cuts out with an error on line 14282 or so
of my log file..
with an error in a gcc line..
it's the only place it tries to use the Xpm library
"-lXpm"
and for some reason, it says it can't find
it.
Any idea
On Tue, 28 Jan 2003, Leif Delgass wrote:
> > BTW, when particular operation is implemented in software but require some
> > on-screen content, driver copy already rendered chunk from framebuffer, pass
> > it to Mesa, then copy back?
>
> To be honest, I don't know the gory details of the Mesa soft
On Wed, 29 Jan 2003, Arkadi Shishlov wrote:
> Hi.
> I'm working on QuakeForge engine, and some things related to transparency
> (player damage blood) and 'dynamic lighting' (grenade explosion) are very
> slow. Quake3 runs faster in mean time.
Quake3 has some "hacks" built in to work around the ma
Am Mittwoch, 29. Januar 2003 00:05 schrieb Ian Romanick:
> Felix Kühling wrote:
> > On Tue, 28 Jan 2003 13:10:41 -0800
> >
> > Ian Romanick <[EMAIL PROTECTED]> wrote:
> >>Felix Kühling wrote:
> >>>The patch moves the load operations back to the front of the loop as in
> >>>the G3TN_norm_w_lengths c
On Tue, 28 Jan 2003, Felix Kühling wrote:
> prefetching looks odd to me. In the first transform loop in
> _mesa_3dnow_transform_normalize_normals memory is prefetched which is
> never read but only written. This is obviously useless. Then in the
No -- at least not *obviously* useless. Whether it
Hi.
I'm working on QuakeForge engine, and some things related to transparency
(player damage blood) and 'dynamic lighting' (grenade explosion) are very
slow. Quake3 runs faster in mean time.
I want to investigate problem further on Quake side, but I want to be sure
I understood mach64 limitation co
On Tue, 28 Jan 2003, Ian Romanick wrote:
> As far as caching goes, I guess I don't understand. Does that mean that
> if someone changes settings while an OpenGL application is running, the
> changes will take effect in the running app? Will it only take effect
> if the app creates a new renderin
> Good story. But right there, you point out the main difference between your
> example, and the XFree86 config format.
Keep in mind - it is not XF68Config, it is just configuration
repository. The tree of available modeuls/layouts/variants/options. Not
actually chosen one (which is still in XF86C
On Tue, 28 Jan 2003, Ian Romanick wrote:
> D. Hageman wrote:
> > On Tue, 28 Jan 2003, Ian Romanick wrote:
> >
> >>How do we want to handle the case where a user changes video cards?
> >>Some of the parameters are likely to be generic, but a lot will be very
> >>device specific. The issue here
On Tue, 28 Jan 2003, Ian Romanick wrote:
> The thing that makes XML worse is that it gives people an extra degree
> of freedom. This amounts to giving people more rope with which to shoot
> themselves in the foot.
LOL.
/me holds rope
/me looks at foot
/me scratches head
--
Leif Delgass
http:
Felix Kühling wrote:
On Tue, 28 Jan 2003 13:10:41 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
Felix Kühling wrote:
The patch moves the load operations back to the front of the loop as in
the G3TN_norm_w_lengths case.
Good catch. It looks like this went into the Mesa tree back in October
On Tue, 28 Jan 2003, Philip Brown wrote:
> > If you think about it, what *really* matters is the bytes inside DRI.
> > The XF86Config syntax is just sugar to make it easy to get the right
> > values in there for people handy a text editor. An XML syntax is just
> > different kind of sugar which
On Tue, Jan 28, 2003 at 09:56:09PM +, Sergey V. Oudaltsov wrote:
> Hi
>
> Just one little XFree-related pro-XML story. Not from DRI, from XKB
> life. You know, XKB configuration is generally held in
> /usr/X11R6/lib/xkb directory and several subdirectories. All this would
> be fine if the form
On Tue, 28 Jan 2003 13:10:41 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
> > It seems I like answering my own mails ;-)
> >
> > I fixed this problem but it is probably not optimal. A simple patch is
> > attached. It seems that this error was introduced by an atempt to
> >
I think a better approach would be to add a level of indirection between
the app and the card - reason to follow this example:
...
...
...
The advantages this has are:
> > If you think about it, what *really* matters is the bytes inside DRI.
> > The XF86Config syntax is just sugar to make it easy to get the right
> > values in there for people handy a text editor. An XML syntax is just
> > different kind of sugar which makes it *trivial* to write tools for peop
Philip Brown wrote:
If you think about it, what *really* matters is the bytes inside DRI.
The XF86Config syntax is just sugar to make it easy to get the right
values in there for people handy a text editor. An XML syntax is just
different kind of sugar which makes it *trivial* to write tools f
Felix Kühling wrote:
It seems I like answering my own mails ;-)
I fixed this problem but it is probably not optimal. A simple patch is
attached. It seems that this error was introduced by an atempt to
optimize prefetching. The next normal was read into MM0 and MM1 at the
end of the G3TN_norm loop
On Tue, Jan 28, 2003 at 03:51:26PM -0500, Jamie Guinan wrote:
>
>> If the XML can be kept relativly simple to read and edit then fine but
>> the end user should never have to use a config tool if they don't want
>> to. So please keep it as simple as possle. In my opinion the
>> readability of
Hi
Just one little XFree-related pro-XML story. Not from DRI, from XKB
life. You know, XKB configuration is generally held in
/usr/X11R6/lib/xkb directory and several subdirectories. All this would
be fine if the format of the files in these directories would be
something good, structured, readabl
> >
> > > ...
> >
> >
>
> I'm coming to conclusion more the more I think about it. I really can't
> come up with a good, real-world case to argue for
> application-then-device. Most of the cases where you'd want the
> application at the top level could be handled by p
On Tue, 28 Jan 2003 07:59:47 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> Having the format be easilly extensible is relevent to us
extensible by the programmers yes. I see no need to use XML for that
though.
---
This SF.NET email is spo
Jamie Guinan wrote:
On Tue, 28 Jan 2003, Steven Paul Lilly wrote:
I'm not a developer and I know nothing about XML and so have no real
opinion as to what the file format should be. I am however woried about
comments like the ones quoted below. The notion that users dont edit
config files b
D. Hageman wrote:
On Tue, 28 Jan 2003, Ian Romanick wrote:
How do we want to handle the case where a user changes video cards?
Some of the parameters are likely to be generic, but a lot will be very
device specific. The issue here is that the set of available parameters
will change. A relea
Felix Kühling wrote:
It seems I like answering my own mails ;-)
I fixed this problem but it is probably not optimal. A simple patch is
attached. It seems that this error was introduced by an atempt to
optimize prefetching. The next normal was read into MM0 and MM1 at the
end of the G3TN_norm loop
On Tue, 28 Jan 2003, Ian Romanick wrote:
>
> How do we want to handle the case where a user changes video cards?
> Some of the parameters are likely to be generic, but a lot will be very
> device specific. The issue here is that the set of available parameters
> will change. A releated issue
On Tue, 28 Jan 2003, Steven Paul Lilly wrote:
> I'm not a developer and I know nothing about XML and so have no real
> opinion as to what the file format should be. I am however woried about
> comments like the ones quoted below. The notion that users dont edit
> config files by hand may be al
It seems I like answering my own mails ;-)
I fixed this problem but it is probably not optimal. A simple patch is
attached. It seems that this error was introduced by an atempt to
optimize prefetching. The next normal was read into MM0 and MM1 at the
end of the G3TN_norm loop. So in the first cycl
On Tue, 28 Jan 2003 11:53:10 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
> How do we want to handle the case where a user changes video cards?
> Some of the parameters are likely to be generic, but a lot will be very
> device specific. The issue here is that the set of available parameters
>
Ian,
Well, the build isn't done yet, but it's much further along now,
having built the GL library and the Direct Rendering Library, as well as
the 2D drivers.
FYI, the problem with the r128 driver also exists in the texmem
branch, which errored at the same point. I don't know, h
Michel Dänzer wrote:
I have an OpenGL program that crashes after opening the GL
context (I believe) - but then dies. The Xserver tries to cleanup
after this mishap and free memory. In the Mesa server code,
xc/extras/Mesa/src/tnl, a context structure element "freed_immesiate"
is used to cache the
Hallo
> We've been discussing general issues regarding the new DRI configuration
> system recently on IRC. The most user-visible issue is the configuration
> file format (until there is a GUI tool ;-).
> In any case we need a more structured (nested) format than win.ini since
> we want to be abl
Well, that solved that particular problem :-)
I don't think that's fixed all my problems, though. Let me grab a clean
copy of the CVS, patch that file, do a make World again, and post any more
problems I end up having.
Adam
On Tue, 28 Jan 2003, Ian Romanick wrote:
> Adam K Kirchhoff wrote:
>
D. Hageman wrote:
I don't have a list of all of the options supported by the drivers
compiled at this momment, but below is kinda my thoughts on a schema
for such a system. If we have any XML experts out there that are really
good at designing such a thing - speak up now!
...
[ Ian wrote ]
> There have been rumblings on [EMAIL PROTECTED] about problems with
> Radeon in 4.2.99.4, but I didn't think that those problems had
> propogated into DRI CVS yet. That's a shame. :(
I think it's the other way round: The DRI stuff that got merged into XFree86
4.2.99.x 'releases'
Adam K Kirchhoff wrote:
I'm trying to compile the DRI from within a chrooted linux
environment on FreeBSD. I've encountered a few errors that I've been able
to work through (I needed to install perl, create /tmp, etc.), but this
one has me stumped.
When it starts to compile the ATI drivers, I
D. Hageman wrote:
> Hence the GUI ...
GUI...
> Seriously, if you a technical reason why ... I would love to hear it.
Technical reason? XML is Bad By Nature, what reason do you expect? :)
Never heard such a lame thing as using a GUI (who needs that) to edit
XML (who needs that) ...
(pls don't ans
Martin Spott wrote:
Unfortunately the result of the merge is less stable with FlightGear on my
Radeon7500 than 'xc-texmem-0-0-1-20030123-trunk-premerge' - it's quite as
stable (or unstable) as the 'trunk' itself.
Would it make sense to split the merge up into a set of patches ? This way I
could r
Hello all :-)
I have an unusual problem I'm hoping someone can help me with.
I'm trying to compile the DRI from within a chrooted linux
environment on FreeBSD. I've encountered a few errors that I've been able
to work through (I needed to install perl, create /tmp, etc.), but th
Well, you are right. When a new app starts it does cache the file. So if
something else modifies the file (ini file) the OpenGL app will only know if
it needs to write and therefore synch.
BTW there is tool that modifies our files: KLT (Kyro Linux Tools).
Anyway I am glad to be of help.
Vlad S
> The merge is finally done. I actually finished it on Sunday. The tag
> is texmem-0-0-1-20030125-trunk-merge.
Unfortunately the result of the merge is less stable with FlightGear on my
Radeon7500 than 'xc-texmem-0-0-1-20030123-trunk-premerge' - it's quite as
stable (or unstable) as the 'trunk'
Hi,
I recently discovered some problem with normal vectors in the gflux hack
on my Duron, Radeon 7500 with and without TCL, even with
RADEON_NO_RAST=1. LIBGL_ALWAYS_INDIRECT works correctly, though.
A workaround is MESA_NO_3DNOW=1. Another way is to normalize the normals
in gflux and change glEna
Vlad Stamate wrote:
When we did the powervr.ini file structure we ported code from our Win32
drivers which used the same file structure. But Win32 offers an API to
read/write those kind of files, while for the Linux driver we had to rewrite
it from scratch. (not fun always :). But it satisfied our
> [...] The notion that users dont edit
> config files by hand may be all fine and good in the microsoft world but
> last time I checked I was using linux. You can't make the same
> assumptions about what users want to do as you can in the microsoft
> world.
I'd like to add _strong_ support to
I'm not a developer and I know nothing about XML and so have no real
opinion as to what the file format should be. I am however woried about
comments like the ones quoted below. The notion that users dont edit
config files by hand may be all fine and good in the microsoft world but
last time I
I don't have a list of all of the options supported by the drivers
compiled at this momment, but below is kinda my thoughts on a schema
for such a system. If we have any XML experts out there that are really
good at designing such a thing - speak up now!
When we did the powervr.ini file structure we ported code from our Win32
drivers which used the same file structure. But Win32 offers an API to
read/write those kind of files, while for the Linux driver we had to rewrite
it from scratch. (not fun always :). But it satisfied our needs good enough.
Keith Whitwell wrote:
Ian Romanick wrote:
Did you ever monkey around with their 16-sample texture filter (the
"anisotropic" mode)? I played with that a bit, but every time I
selected that mode it would crash the graphics chip. :(
No, never tried it. Do you have to somehow dedicate both text
Ian Molton wrote:
On Tue, 28 Jan 2003 01:25:48 -0600 (CST)
"D. Hageman" <[EMAIL PROTECTED]> wrote:
what alternative do you propose that would be faster? Are we talking
seconds, minutes, hours ... what?
On some systems, every nanosecond counts.
There are four times when the configuration fil
Damien Miller wrote:
Philip Brown wrote:
On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote:
If anyone has serious objections to XML, please let us know (mail to
dri-devel will suffice ;-).
I object. Using xml inevitably leads to files that are completely
human-unreadable, except
Title: GAZETE KEYFÝ
Gazete Keyfi...Her sabah güne baþlarken içinizi ýsýtacak bir site burasý...Sýcacýk çayýnýzý yudumlarken ya da yemekten sonra kahvenizi içerken alacaðýnýz keyfi ikiye katlayacak, Türkiye ve Dünyada neler olup bittiðini izleyebileceðiniz, günlük bulmacanýzý çözebileceðiniz, elin
FYI, apologies to those subscribed to the xfree86 list as well.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
--- Begin Message ---
XFree86 Bug/Test Report Form
Please fi
Ian,
Comments are inline below and I have also included a couple of one line
responses you posted to the list. I like to keep the traffic on the list
as reasonable as possible so that is why I am not replying to them
individually.
On Tue, 28 Jan 2003, Ian Molton wrote:
> On Tue, 28 Jan 2003
Ian Molton wrote:
On Tue, 28 Jan 2003 02:55:22 -0600 (CST)
"D. Hageman" <[EMAIL PROTECTED]> wrote:
*) Every major programming language has some library to handle XML
(say if you hacked togther a library that does the XF86Config file
format ... this wouldn't be the case).
Irrelevant in thi
Philip Brown wrote:
On Mon, Jan 27, 2003 at 10:37:06PM -0600, D. Hageman wrote:
On Mon, 27 Jan 2003, Philip Brown wrote:
Preferably in an area that XML was designed for: in exchanging
data between programs and OTHER programs, not between humans and programs.
Simplify: GUI configuration tool
Philip Brown wrote:
On Mon, Jan 27, 2003 at 06:04:19PM -0600, D. Hageman wrote:
Your argument is bogus. You can't claim that every XML file format leads
to unreadable files. Now, if you have a good *technical* reasons why we
shouldn't use XML - I would love to hear them.
Looks like you d
On Tue, Jan 28, 2003 at 10:37:03AM +, Ian Molton wrote:
> On Tue, 28 Jan 2003 02:55:22 -0600 (CST)
> "D. Hageman" <[EMAIL PROTECTED]> wrote:
>
> >
> > > So what are the "technical" advantages of XML in this case?
> >
> > Quick List --
> >
> > *) Text Based - easy to edit.
>
> Text based do
On Tue, 2003-01-28 at 12:00, Sven Luther wrote:
> Just my experience for when file-roller (part of gnome) upgrades its
> configuration, it takes minutes on a Atlhon 1700+, but i admit, the
> configuration file-roller manages are, if not big, at least there are
> many of them.
Thats something else.
On Tue, Jan 28, 2003 at 01:25:48AM -0600, D. Hageman wrote:
> On Tue, 28 Jan 2003, Sven Luther wrote:
>
> > On Mon, Jan 27, 2003 at 06:04:19PM -0600, D. Hageman wrote:
> > >
> > > I think you misunderstand. We aren't replacing the XF86Config file here.
> > > This is for DRI specific driver set
On Mon, Jan 27, 2003 at 10:41:20PM -0600, D. Hageman wrote:
> Those are some excellent examples of abuse. It doesn't have to be like
> that.
[..]
> If we went with libxml2 it has no exterior dependencies that I am aware.
Probably I was harsh when I said no to XML. Using libxml is good from
c
> *) Text Based - easy to edit.
>
> Text based does NOT imply easy to edit. look at USBsnopys' output. its
> completely illegible.
XML printed sensibly is ok for human editing (not ideal). Users dont
edit config files however they use apps to do this.
> > *) Well known basic format (think each t
On Mon, 27 Jan 2003, Philip Brown wrote:
>Perhaps the DRI config team could do the xfree side a favour, and write an
>actual mini-library. Then actually migrate code in the other direction
>for once :->
Like "libxf86config" the library included with XFree86 since 4.0?
>After all, it seems to be
On Tue, 28 Jan 2003 02:05:34 +0200
"Arkadi Shishlov" <[EMAIL PROTECTED]> wrote:
> It is also possible to rebuild XML parser in some binary
> incompatible way..
or find someone compiled their own broken one.
---
This SF.NET email is sponsored b
On Tue, 28 Jan 2003 01:25:48 -0600 (CST)
"D. Hageman" <[EMAIL PROTECTED]> wrote:
> what alternative do you propose that would be faster? Are we talking
> seconds, minutes, hours ... what?
On some systems, every nanosecond counts.
---
This SF
On Tue, 28 Jan 2003 02:55:22 -0600 (CST)
"D. Hageman" <[EMAIL PROTECTED]> wrote:
>
> > So what are the "technical" advantages of XML in this case?
>
> Quick List --
>
> *) Text Based - easy to edit.
Text based does NOT imply easy to edit. look at USBsnopys' output. its
completely illegible.
>
On Mon, 27 Jan 2003 22:37:06 -0600 (CST)
"D. Hageman" <[EMAIL PROTECTED]> wrote:
> > C code can be edited with any text editor, too. But the percentage
> > of DRI users that can usefully DO that, is a very small number,
> > comparative to the overall number of users.
>
> Hence the GUI ... I think
Philip Brown wrote:
On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote:
If anyone has serious objections to XML, please let us know (mail to
dri-devel will suffice ;-).
I object. Using xml inevitably leads to files that are completely
human-unreadable, except perhaps to the origina
On Tue, 28 Jan 2003, Dieter Nützel wrote:
> Am Dienstag, 28. Januar 2003 08:22 schrieb D. Hageman:
> > On Mon, 27 Jan 2003, Philip Brown wrote:
> > > I am trying to point out that none of
>
> [-]
>
> > > On the other hand,
> > > "DRI is meant to integrate with XFree86. XFree86 has a standard
>
68 matches
Mail list logo
