Panagiotis Papadakos schrieb:
On Thursday 16 April 2009 12:29:44 pm Jin, Gordon wrote:
Roland Scheidegger wrote on Thursday, April 16, 2009 8:52 AM:
I just fixed the link. Please give it a retry.
Thanks
Gordon
___
xorg mailing list
Eric Anholt schrieb:
On Sun, 2008-11-16 at 15:53 +0100, Philipp Klaus Krause wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In intel_fbo.c from the 965 driver RGBA, GL_RGBA2, GL_RGBA4, GL_RGB5_A1,
GL_RGBA8, GL_RGB10_A2, GL_RGBA12 and GL_RGBA16 are all mapped to GL_RGBA8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In intel_fbo.c from the 965 driver RGBA, GL_RGBA2, GL_RGBA4, GL_RGB5_A1,
GL_RGBA8, GL_RGB10_A2, GL_RGBA12 and GL_RGBA16 are all mapped to GL_RGBA8.
Is this limit imposed by the hardware or the driver? Can the hardware do
RGBA16?
Philipp
-BEGIN
I think it would be useful if one could choose software rendering
without having to uninstall hardware drivers. Maybe a driconf option or
an environment variable would be the way to go. This could be useful for
trying new OpenGL features not yet supported in hardware drivers, like
OpenGL 2.0.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick schrieb:
2. Decompressing textures for software fallbacks. As far as I'm aware,
all of the drivers still have some software fallbacks, so this support
is still required.
This decompression could be done by the hardware: Ortho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Dösinger schrieb:
This may be slightly off topic, but I am wondering if there's any way to
detect the ability to upload precompressed textures when
GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced
it). Wine and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Scheidegger schrieb:
If you only use DXT1 there's EXT_texture_compression_dxt1. It offers
support for using DXT1 precompressed textures. However AFAIK it'S
currently not supported in the free drivers (even if
GL_EXT_texture_compression_s3tc
I tried (as documented in the wiki at
http://dri.freedesktop.org/wiki/TestingAndDebugging)
export LIBGL_SOFTWARE_RENDERING=1
glxinfo
and got
OpenGL renderer string: Mesa DRI Intel(R) 965GM 4.1.3002
Philipp
P.S.:
I know such questions should go to dri-users, but I couldn't get an
answear
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt schrieb:
No. Gem can't coop with it. Let's say you have a 512M system with two 1G
video cards, 4G swap space, and you want to fill both card's videoram
with render-and-forget textures for whatever purpose.
Who's selling that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It seems Intel has released complete documentation for the 965:
http://intellinuxgraphics.com/documentation.html
Philipp
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Some time ago Vector Quantisation (VQ) texture compression was
implemented in some chips like the PowerVR series or the ATI MAch64 and
R128.
Is this still supported by today's hardware?
Is there an OpenGL extension for it (I looked briefly through those
texture compression extensions that contain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to
http://www.0xdeadbeef.com/weblog/?p=302
and
http://lwn.net/Articles/248227/
they will release complete hardware documentation.
Let's hope it's true this time.
Philipp
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
GL_ARB_*_program doesn't know about functions. It can easily be
implemented on a graphics chip whose shader processors don't know about
function calling, indirect addressing, stack, etc: Just a lot of
registers, directly addressed would do.
What about GLSL? Now there's a C-like language, functions
Dieter Nützel wrote:
But what is this?
If I set 'setenv LIBGL_ALWAYS_INDIRECT' (tcsh) I get:
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R300 20060815 AGP 4x x86/MMX+/3DNow!+/SSE TCL
OpenGL version string: 1.3 Mesa 6.5.1
Shouldn't it OpenGL 2.1 like
Benjamin Herrenschmidt schrieb:
In collaboration with the FB guys, we've been working on enhancing
the
kernel's graphics subsystem in an attempt to bring some sanity to the
Linux graphics world and avoid the situation we have now where
several
kernel and userspace drivers compete for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexy Khrabrov schrieb:
When trying to make nvidia drivers sleep, and then later get nouveau
to work, I got hopelessly confused about various pieces of video
hardware/software and their mutual entanglements. I'd much
appreciates if one of you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian St. Pierre wrote:
Hi -
I'm assembling a new pc and have gotten bogged down on video card choices.
Can someone here recommend a card?
* under US$80
* PCI Express -- motherboard is ASUS M2N-E which has PCIE
* take advantage of hw 3d
Adam K Kirchhoff wrote:
I was running some test comparing the r200 vs the r300 driver this
morning, and noticed a slight rendering issue with the r200 driver with
reflections in the game neverball.
I suggest you file a bug, so that this problems isn't forgotten as
completly as it would be
[EMAIL PROTECTED] wrote:
And the high-precision subpixel processing enables videos to be scaled
to any size, so that even small videos look like they were recorded in
high-resolution.
Trilinear texture filtering should do that. It's supported on any
graphics card these days. It's more a
John Clemens schrieb:
There was a post on this list at the end of december(?) indicating that
ATI was not interested in helping open source with 3D specs anymore..
I'm guessing they didn't do much with the r300 line either.. but does
anyone know anything or have any official word on whether
Felix Kühling schrieb:
One more show-stopper for auto-discovery of OpenGL apps is the fact that
some applications load libGL dynamically at run-time. I haven't got any
feedback to my GL application survey, but at the moment I see a
built-in database (does lookup-table sound less scary?) of
Felix Kühling schrieb:
See https://bugs.freedesktop.org/show_bug.cgi?id=5792 for details. I'm
fairly certain that we have solved all installation and configuration
issues. What remains is some size mismatch that prevents 3D from working
on an i855 with a recent binary snapshot. Could someone
Rogelio Serrano schrieb:
I have reinvented the wheel and now have standalone opengl on
framebuffer by hacking egl support into tinygl. I have also copied over
code from mesa and it looks like Ihave reinvented mesa too.
Which graphics card has the most open specs so i could start reinventing
Ian Romanick schrieb:
Dave Airlie: Can we get those DRM changes pushed into 2.6.15 or is it
too late for that?
2.6.15 has been released yesterday.
Philipp
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for
ATI stated that they will not release any information about there
hardware to developers of free drivers in the foreseeable future.
They were asked by the German computer magazine c't. You can find the
information on page 168 in the magazine from 27.12.2005.
Philipp
Adam K Kirchhoff schrieb:
I'm sure this confirms what are already known issues with the r300
driver, but felt it'd be worth posting anyway. There's definitely
something bizarre going on with textures. They're much crisper with the
fglrx driver.
To me it looks like the fglrx driver does
And 3D-acceleration seems to work! But I get some warnings:
*WARN_ONCE*
File r300_state.c function r300Enable line 457
TODO - double side stencil !
***
I assume you mean the newest file. If a software fallback for a hardware
operation is disabled, does that mean that the operation can not be done
at all? (I have no clue what a double side stencil is.)
Double sided stencil means that you can select different stencil buffer
operations
Ian Romanick schrieb:
Here's my opinion on the matter, but I'd like to hear from Brian or Keith.
1. All drivers should expose GL_ARB_vertex_program and
GL_MESA_program_debug. I don't care either way about the NV extensions.
So you think we should announce it even though the spec says
Roland Scheidegger schrieb:
Well the discussion only inovlved two people :-). It's quite possible
others might think it's worthwile, I'm certainly no authority on that.
I know. This is what Ian wrote last time I posted the patch (when it
still included GL_EXT_vertex_cull):
My only other
I hvae removed GL_EXT_cull_vertex from my patch, since Brian wants to
remove it from Mesa, too.
Since the r128 doesn't have hardware tcl all interesting features of
Mesa's software tcl should be exposed.
This patch adds support for
GL_ARB_vertex_buffer_object,
GL_ARB_vertex_program,
Stephane Marchesin schrieb:
What is the point of advertising GL_MESA_pack_invert if it's not
implemented ?
Stephane
According to extensions specification this extension's main purpose
seems to be making application developers life a little bit easier, just
like
In that sense, I'd consider NV_vertex_program as bloat just as well.
Applications really always can deal with not available non-standard
extensions very well.
About GL_NV_vertex_program:
1) It was the first nice vertex program interface and is used in many
old tutorials on vertex shading.
2)
Roland Scheidegger schrieb:
btw it looks you can't announce ARB_vertex_program on r128. The
extension says not only based on OpenGL 1.3, but it requires OpenGL 1.3.
I think that leaves two options
1) Don't add any vertex program stuff to the r128 driver. In that case
the patch I posted
Since vertex program support was the main point of the patch,
and the discussion has shown reasons not to add any vertex program
support to the r128 I think that my patch should be ignored.
I might create another one once Mesa implements vertex shaders.
Philipp
Roland found out how to do bigger aliased points on r200 hardware a long
time ago. AFAIK the patch was never applied since people failed to see
it's importance.
3D modellers use points to mark the currently selected vertices. A
maximum point size of 1 means they are invisible with today's screen
I can apply a patch if you think it's useful. I just thought that
antialiased is the norm for points rather than the exception, but if
it's not it could indeed be useful.
Antialiased points probably are the norm for most applications (games,
etc). 3d modellers seem to be an exception here.
believe it or not pkgconfig actually makes your life easier...once you
get to know it ;) It's the unix way. It basically tells you where to
find header information for various packages. You copy the package's
.pc file to the pkgconfig directory (often /usr/lib/pkgconfig). then
try
I found 4 mails in a thread about this in the
list archive, but all except the first drifted away
to GL_EXT_stencil wrap on the r100. Are the patches
for this still around somewhere?
What has been found out about the hardware stencil buffer on the
r128?
Philipp
Alan Cox schrieb:
On Sul, 2005-08-14 at 21:03 +0200, Philipp Klaus Krause wrote:
not yet. Alan Cox had a semi-working version here:
http://www.linux.org.uk/~alan/sis6326.tar.gz
This only contains the DRI part. Does that mean it uses the same
DRM as the 305?
There is a small patch
Look at the output of Mesa/progs/tests/texwrap
With the i915 driver there's no green without a border.
Indirect rendering and the r128 driver always show
the area around the [0,1]x[0,1] red aread in green.
What is the supposed display with GL_REPEAT?
With indirect rendering there is no green
What happened to this one?
I found some discussion about it in the mailing list archive,
but I didn't find it in the wiki.
Philipp
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA
Philipp Klaus Krause schrieb:
What happened to this one?
I found some discussion about it in the mailing list archive,
but I didn't find it in the wiki.
Philipp
OK I found it at
http://dri.sourceforge.net/doc/dri_driver_features.phtml
Shouldn't this be ported to the wiki?
Philipp
Ian Romanick schrieb:
I could have sworn that the vertex-program extensions and
GL_EXT_cull_vertex each required an addition TNL pipeline stage. I see
that the i915 driver adds _tnl_vertex_cull_stage and
_tnl_vertex_program_stage. Why does r128 not need those additions?
The r200 and the
I have some questions about the SiS driver:
1) The SiS driver looks different from the other drivers. It doesn't
have a custom tnl_pipeline as all the other drivers except tdfx do.
Was this some old style of writing drivers and all others have already
been converted?
2) Has any of the work on
What are the minimum requirements of Xegl in terms of extensions
supported?
Which modifications to a driver are necessary for EGL?
Wich parts of the driver (DRM, fb, DRI) have to be modified?
Will Xegl run fast enough on old hardware like the
RagePro 3D or the SiS 305 or Sis 6326?
Philipp
Adam Jackson schrieb:
On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote:
What are the minimum requirements of Xegl in terms of extensions
supported?
Not much. See http://freedesktop.org/wiki/Software/Xgl, but the major
requirements are:
NV_texture_rectangle
This shouldn't
Since the r128 has no hardware tcl and tcl has to be
done in software anyway I think it should have a
full-featured tcl. This patch enables some extensions:
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_EXT_cull_vertex
GL_EXT_multi_draw_arrays
GL_MESA_pack_invert
GL_NV_vertex_program
Alex Deucher schrieb:
2) Has any of the work on DRI for SiS 6326 been merged into DRM or Mesa?
not yet. Alan Cox had a semi-working version here:
http://www.linux.org.uk/~alan/sis6326.tar.gz
This only contains the DRI part. Does that mean it uses the same
DRM as the 305?
The Card is a PCI SiS 305 with 32 MB RAM.
I use DRM and Mesa from CVS with a 2.6.13-rc5 kernel.
I see
1)
I get segfaults in many OpenGL programs, including glxgears
and gears from Mesa/progs/demos. The segfaults are always
in neutral_VertexAttrib4fvARB. The problem seems to occur
in all
Alan Grimes schrieb:
I've been hacking on my version of the N64 emulator again and I noticed
I was getting an invalid value error from the texImage2D command...
I assumed that it was because it required textures to be a power of two
in size...
Then I checked the GL spec and the only
Roland Scheidegger schrieb:
Here's a somewhat experimental patch to enable
GL_ARB_texture_env_crossbar on r200. It got more ugly than I wanted...
Works with tests/crossbar, glean(texcombine), couldn't find anything
more which uses it (well ut2k4 seems to, but I couldn't see any
difference).
Vladimir Dergachev schrieb:
My understanding is that AGP only does transfers system RAM - video RAM
and all transfers in the opposite direction have to use plain PCI
transfers at least as far as the bus is concerned.
AGP can do both. Every AGP compliant device has to support the
System RAM
Nik schrieb:
Philipp!
Vielen Dank.
Philipp Klaus Krause wrote:
Nik schrieb:
It's unlikely that you'll have to debug the kernel module.
The bug probably is is the DRI.
Ok, thanks. Any tips on what I should be looking for in the DRI?
If the problem is in the DRI, then does
Nik schrieb:
Philipp Klaus Krause wrote:
Nik schrieb:
Oh ok. So in terms of names, the structure is:
The card-speciifc module in the kernel == radeon
the card specific driver part in the DRI. == r200
correct?
Yes
Nik schrieb:
...which brings me to the next point: Presumably, I should be
testing/debugging this in a recent version of the DRI source? But which
one? Should I be checking out from CVS? Or is it acceptable for me to
work with the source of my distro (2.6.11-1.14_FC3)?
And could
Rune Petersen schrieb:
Hi,
Enabling water in Scorched3D causes corruption of all textures and I
have tracked it down to interaction between glPopAttrib() and the
attributes GL_TEXTURE_GEN_S GL_TEXTURE_GEN_T.
I using the latest CVS updates of Xorg, Mesa, and r300_driver.
This problem is not
This is a known bug in glxgears that has been fixed some time ago.
Due to limited floating-point precision the gears stopped turning
after a fixed number of frames.
Philipp
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to
Hamie schrieb:
One other funny I noticed that I've never noticed before without the
r300 drivers is that X would 'reload' itself whenever the client
closed.. (I was only runnning one at a time, no window manager). Is that
normal?
It is.
---
SF
Is someone working on writing a driver for these chips?
XGI provides a free framebuffer driver and drm, but the
Mesa part of their driver is only available as closed-source.
Philipp
---
SF email is sponsored by - The IT Product Guide
Read honest
Vladimir Dergachev schrieb:
I think I found the cause of lockups in VB mode - they were due to
cursor updating function in radeon_mergedfb.c calling OUTREGP() which in
turn called INREG.
When silken mouse is enabled this function could be called at any time
which would do *bad* things when CP
Vladimir Dergachev schrieb:
Interesting :) Could you try this with latest X.org source ?
Sorry, but I probably won't find much time. I'll be away from the
rv250 during the next week. Next month I'll have to write some exams,
while at the beginning of april there are oral exams. I hope to
find more
Roland Scheidegger schrieb:
As for pntparam, I couldn't get it really working, and in this form it's
overkill for what works (larger point sizes). I'm not so sure it's worth
the trouble of whipping up a simpler patch which would only contain
that, since only aliased larger point sizes are
Geller Sandor schrieb:
1. build and install everything from CVS, if the X server can be crashed,
go to step 2, otherwise be happy :))
2. use the X.org CVS version with the stock kernel's drm, if X still
crashes, go to step 3. Otherwise use the X.org CVS, live without
projected textures...
3.
Adam K Kirchhoff schrieb:
Agreed, for the most part. I use an 8500 and 9200 at work and at home.
I regularly update my Mesa tree and build new version of the r200
driver. The only problems I've experienced is if I leave xscreensaver
up and running all night, randomly choosing from the OpenGL
Dave Airlie schrieb:
Just to update, I've looked at the fragment shader stuff and the
documentation I have isn't enough to implement the spec, we only have
access to the second stage registers (PP_CNTL - states second or only pass
registers)
Is it enough to implement GL_ARB_texture_crossbar?
Jerome Glisse schrieb:
Yellow dog seems to have support for radeon 9600.
At least they claim so. I tried to find out the source
of their distribution but only manage to get iso for
binary.
On their site they state that they support only 2D,
no hardware-accelerated 3D.
Does anyone have figures for the MOST time consuming parts of software
3D in the Mesa libs? Those would be the logical bits to push into
hardware first. But I'm not sure I've ever seen a profile output from X
to say which parts are actually most would benefit more from
acceleration than
Thank you for doing this work. We really need to get the open-source
ATI driver on par with the propretary driver (both feature-wise and
performance-wise).
But sadly we will NEVER match it.
NO SmoothVision, HyperZ docu ever
The nonfree xig driver has been developed without HyperZ docs and
Dieter Nützel schrieb:
The nonfree xig driver has been developed without HyperZ docs and
outperforms fglrx.
Are you sure.
I thought Xig had it all before.
Do you have actual numbers?
Haven't looked at them for very long time, but I bought the first version of
there X server 1994 (?) for mga.
Paulo R. Dallan schrieb:
Ok, things are getting worse.
After I installed the dri drivers, i had only re-started the x-server - and
acceleration worked but not as expected, as mentioned before.
After a reboot, when trying to start x, i did modprobe radeon (ok), and issued
the startx command. The
Paulo R. Dallan schrieb:
Another strange thing, as i mentioned before, is that glxgears gives me 400
FPS output, but the drawing is quite slow, while in another machine here i
have 200-250FPS and, at the same time, the drawing seems amazingly fast...
Any suggestion?
The gears turn faster when
Paulo R. Dallan schrieb:
Just complementing: man radeon gives a list of the PCI and AGP ATI cards
supported by the xorg radeon driver, and the ATI Radeon 9200se is mentioned
there:
RV280 Radeon 9200PRO/9200/9200SE, M9+
So, either the man pages are wrong, or I was indeed using the correct
I've just tried the ati generic driver (option from xorgconfig) and the
speed got even slower (however, glxinfo also gave me direct rendering: yes!).
Actually, I got a little confused over here.
In the dri/wiki, under the building description, it is described that the
ati is the 2D driver for
Paulo R. Dallan schrieb:
At first impression, 3d acceleration seemed really bad (). Glxgears was
giving me 130, 140 FPS! And this is an Athlon XP 2600 with the ATI 9200se (I
know, this video card is not that good, but results should not be so bad, it
has 128 Mb, AGP 8x (though dri is only
Oh, I should point out that TG does do both GLES consultancy and will
continue to push Mesa-solo where it makes sense to do so...
At some point I'd like to try writing integrating a GLES target into the
Mesa codebase. I don't know whether it would be possible or sensible to
try and have the
Mike Mestnik schrieb:
I was playing with winex, after paying for some games and a TransGaming
subscription. In the cfg there are options to enable/disable the use of
some OpenGL extensions, one being ARB_VBO. I saw that when using frglx
there were some of these advertised by glxinfo, but not
Ian Romanick schrieb:
Looking at the list, I noticed a couple of odd things. Why don't the
ATI drivers support GL_{ARB,EXT,NV}_texture_rectange or
GL_{ARB,EXT}_blend_equation_separate?
ATI sometimes makes strage decicions about the features their drivers
support: Even though the r200 could
Has anyone else experienced problems reading back depth values with
the r200 driver?
Whenever I read back a depth value from the right part
(about a seventh or eighth of the width) I get 1.0.
Reading back from other parts of the buffer works OK
as does software Mesa everywhere.
Philipp
At the time the code was written (fall 1999?) the only way Gareth found
that he could reliably determine that SSE was fully supported (by CPU
and kernel) was to try executing an SSE instruction and catching the
exception if it failed.
If there's a better way of doing that nowadays, we could
Ian Romanick schrieb:
Philipp Klaus Krause wrote:
Does that mean that software Mesa doesn't use SSE?
The problem occurs only with the r200 driver, not with software
rendering.
Okay, then the SSE test can't be the problem. The exact same code gets
executed in both the R200 driver and software
_mesa_test_os_sse_exception, executed upon start of any OpenGL
application raises SIGFPE. Normally this is not a problem,
applications continue to execute normally.
However when using the jogl OpenGL Java binding programs exit.
I tried both with Java 1.4 from Sun and sablevm.
Philipp
What became of the proposal of making fb a DRM client
that I saw on dri-devel some time ago?
It sounded like a good idea to me.
Philipp
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod
Brian Paul schrieb:
Pasi Kärkkäinen wrote:
Hi all!
From the www.opengl.org:
OpenGL 2.0 specification available for download
http://www.opengl.org/documentation/opengl_current_version.html
http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
Any plans for 2.0 support in Mesa? I think
Michael Mazack schrieb:
r200_context.c shows the following:
if(driQueryOptionb(rmesa-optionCache,
arb_vertex_program))
_mesa_enable_extension( ctx,
GL_ARB_vertex_program);
if(driQueryOptionb(rmesa-optionCache,
nv_vertex_program))
_mesa_enable_extension( ctx,
GL_NV_VERTEX_PROGRAM);
Should the
Dave Airlie schrieb:
When will we see this in?
http://marc.theaimsgroup.com/?l=dri-develm=109408144803743w=2
I've reviewed it and would be happy with it as well, but I would like a
driconf option to turn it off in case it some apps have issues..
adding a driconf option is explained at:
-p1 in Mesa/src/mesa/drivers/dri
Philipp Klaus Krause
diff --unified -r dri.bak/common/xmlpool.h dri/common/xmlpool.h
--- dri.bak/common/xmlpool.h 2004-05-08 12:08:21 +0200
+++ dri/common/xmlpool.h 2004-09-06 20:32:38 +0200
@@ -273,4 +273,25 @@
DRI_CONF_DESC(de,Anzahl der Textureinheiten
'Did some more testing and found bugs.
Here is the corrected patch.
Philipp
diff --unified -r dri.bak/common/xmlpool.h dri/common/xmlpool.h
--- dri.bak/common/xmlpool.h 2004-05-08 12:08:21 +0200
+++ dri/common/xmlpool.h 2004-09-06 20:39:06 +0200
@@ -273,4 +273,25 @@
Alan Cox schrieb:
[...] then there are a couple we
have docs for and no drivers.
The Wiki mentions only the SiliconMotion Chips as having docs,
but no drivers, and says that SiS docs are available and a driver is
in development.
Are there any other chips with driver, without docs?
Philipp Klaus
Dieter Ntzel schrieb:
Argh,
what a regression.
most tests show mostly empty and/or black and/or white windows...
Strange, I just ran Viewperf 8 on my r200 and didn't notice
any problems (expect ensight-01 that didn't even run, but it
seems that's a problem with a Viewperf script).
Philipp Klaus
I did use a slightly older cvs version with only my vertex
program patch applied and built in the Mes tree without
optimizations.
Strange, I just ran Viewperf 8
8.0.1?
Yes.
I've downloaded it in the morning. ;-)
on my r200 and didn't notice
any problems
SMP-system (EnvLINUX.c reports num=2)
gcc-3.5 -O2 -march=athlon-mp -msse -DMP
Just saw that the it seems to take the options from the Makefile,
I just set them in options (included by Makefile, but the CFLAGS
defined there is overwrittem)
Philipp
---
This SF.Net email is sponsored
Dieter Nützel schrieb:
Philipp Klaus Krause schrieb:
gcc-3.5 -O2 -march=athlon-mp -msse -DMP
Just saw that the it seems to take the options from the Makefile,
I just set them in options (included by Makefile, but the CFLAGS
defined there is overwrittem)
;-)
That's why I 'included' my changed
[-]
-mfpmath=sse will be ignored, since -march=athlon doesn't allow it
(the original athlon didn't have sse) you have to use -march=athlon-mp.
Philipp Klaus Krause
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE
the perspective divide onward is still hardware accelerated, even
when a vertex program is active.
Philipp Klaus Krause
Gemeinsame Unterverzeichnisse: r200.bak/CVS und r200/CVS.
diff -u r200.bak/r200_context.c r200/r200_context.c
--- r200.bak/r200_context.c 2004-08-19 18:20:48 +0200
+++ r200/r200_context.c 2004
Schneidegger these three were the ones were
most rendering errors occured, so running these should find rendering
errors in addition to benchmarking.
See http://homepage.hispeed.ch/rscheidegger/ for the comparison.
Philipp Klaus Krause
---
SF.Net
Some time ago I sent patches that enable vertex program support
in the r200 driver (software only though) to this list.
Now I wonder if they will be integrated into the driver and how this
process works. Do the driver maintainers read this list, lok at the
patches and decide what they integrate?
the
former are always there). The only thing in terms of hardware
acceleration that we loose when vertex programs are enabled is
hardware tcl. From the perspective divide onward everything is
accelerated again.
Philipp Klaus Krause
---
SF.Net email
Patrick McFarland schrieb:
On Thu, 19 Aug 2004 18:40:12 +0200, Philipp Klaus Krause [EMAIL PROTECTED] wrote:
Attached are patches to enable support for GL_ARB_vertex_program in the
r200 driver.
Thats very cool, but does this mean that it is hardware accelerated now?
No, I don't have any Radeon
:379) when
calling glMultiDrawElementsEXT while creating a display list.
Philipp Klaus Krause
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off
1 - 100 of 110 matches
Mail list logo
