dri which makes my system stable
again.
Thanks,
Frank
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your R
-n says:
:01:00.0 0300: 1002:5460
Once I do this, dri seems to work.
Frank
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernigha
On Sunday 27 November 2005 20:18, Alex Deucher wrote:
> On 11/26/05, Michael Frank <[EMAIL PROTECTED]> wrote:
> > I like to upgrade mach64 driver for inclusion in kernel
> > and desire a datasheet.
> >
> > Thanks Michael
>
> You should have enough in the sou
On Sunday 27 November 2005 07:32, Dave Airlie wrote:
> > Current cvs does not build as part of kernel. There are
> > major changes since in-kernel version. I want to
> > build in kernel space by kernel make together with
> > other drivers.
>
> Get current CVS, don't worry about the kernel, you don'
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Sunday 27 November 2005 01:09, Dave Airlie wrote:
> > I like to upgrade mach64 driver for inclusion in kernel
> > and pull relevant version from cvs.
>
> There isn't one.. just fix the mach64 in CVS to be secure
> a
On Wednesday 23 November 2005 18:32, Alan Cox wrote:
> On Mer, 2005-11-23 at 11:46 -0500, Adam Jackson wrote:
> > On Wednesday 23 November 2005 07:48, Michael Frank
wrote:
> > > Testing 2.6.15-rc2 in-kernel DRM, why still no
> > > mach64 support which works fine for
I like to upgrade mach64 driver for inclusion in kernel and
desire a datasheet.
Thanks Michael
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that make
I like to upgrade mach64 driver for inclusion in kernel and
pull relevant version from cvs.
Thanks Michael
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engi
Testing 2.6.15-rc2 in-kernel DRM, why still no mach64
support which works fine for me from snapshots/cvs?
Michael
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certi
ATI Radeon X800 (R430) (PCIE)
:05:00.0 Class 0300: 1002:554f
:05:00.1 Class 0380: 1002:556f <-- second device
73 de Frank
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Produc
On Sun, 7 Mar 2004 08:13:14 -0800 (PST), Alex Deucher <[EMAIL PROTECTED]> wrote:
--- Cristiano De Michele <[EMAIL PROTECTED]> wrote:
Hi Michel,
I'm using your dri-trunk debian packages on a compaq evo n1015v
laptop with ati radeon IGP320M graphic adapter
and all works fine concerning suspend/resum
On Fri, 05 Mar 2004 11:41:54 +0100, Cristiano De Michele <[EMAIL PROTECTED]> wrote:
Hi,
I have linux 2.4.25 + swsusp 2.0.0.10
on compaq evo 1015 (ati radeon IGP 320M)
and I recently installed the dri trunk
of xfree86-xserver recompiling all sources
from scratch.
This way I got finally dri working
mouth and a roof
over your head.
What makes the situation with some of the older chips worse is that they're
not suited, as you've noticed, to what DRI offers. They're almost better off
with something else- of what, I'm not precicely sure yet.
--
Frank Earl
---
,
Frank
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https
The following is missing from the r200 driver:
ATI_texture_env_combine3
Hence when trying to play ut2k3, all I see when playing is
colliding triangles??
When will ATI_texture_env_combine3 be added?
Thanks,
Frank
---
This SF.NET email is
Radeon 8500 LE (Built by ATI) can't do 1600x1200 on a ViewSoncic A90.
The Radeon 7500 can.
I placed a bugzilla item at
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79501
Please fix.
Thanks,
Frank
---
This sf.net email is spon
In function `firegl_stub_open':
firegl_public.c:361: parse error before `)'
firegl_public.c: In function `firegl_stub_getminor':
firegl_public.c:398: parse error before `)'
firegl_public.c: In function `firegl_stub_register':
...
and many more lines like this. Anyone g
t's enough to muddle through a driver for the chip, I
just haven't had the time to sit down and actually do the work.
--
Frank Earl
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), t
nstalled everything from the latest snapshot.
Anything I can do, any output I can provide to help find the error?
cu,
Frank
--
Dipl.-Inform. Frank Steinermailto:fst@;informatik.uni-kiel.de
Lehrstuhl f. Programmiersprachen mailto:fsteiner@;web.de
CAU Kiel, Olshausenstraße 40 Phon
On Saturday 02 November 2002 05:18 pm, you wrote:
> Wasn't VIAGRA a PC Chips relabeling of the VIA MVP4? What would a DRI
> developer do with that? ;)
Write a driver for it??
(If memory serves, the MVP4 had an integrated 3D "accelerator", namely a
Trident CyberBlade...
and DMA it from there. The copy method is
probably going to be faster than an audit and unmap because everything is in
cache with the copy operation.
--
Frank Earl
---
This sf.net emial is sponsored by: Influence the future
of Java(TM) tec
e. The stuff I do have is under NDA and useless at the same time (2D and
MPEG decode programming)- and it was like pulling teeth to get that much out
of them for the 310/630.
--
Frank Earl
---
This sf.net email is sponsored by:ThinkGeek
We
, the new site would have
probably been ready much sooner.
It was fun being a part of this project and definitely very interesting
to follow some of the threads on this mailing list.
I wish everyone and the project the best of luck in the future.
Cheers,
- Frank
have to scroll down to the developer docs after
clicking on the link.
Cheers,
- Frank
---
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server
today at
scroll it out of view. Just modify the
dri_header() code for that.
Anyway, I think the site looks a lot better now. It's almost ready for
primetime. Keep up the good work.
Cheers,
- Frank
---
This sf.
ie: border=0 for the IMG tag.
- Frank
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourc
is how it was done I have various
> DRI sites eg new, old , update sitting on my HDD.
Ok, I am glad we agree on the page layout.
> I must say I appreciate your input / opinions / requests if have been trying
> to obtain this sort of thing fro
and all. I cannot do this with DRI - there are no specs. all I
> can do is poke blindly.
As I said above, if you were really serious about becoming a developer
you would be able to obtain documentation from the companies. Obviously
you must be doing something wrong ...
t; it and IMO definetely deserve a credit for it.
I do appreciate Liams effort and I am sure that everyone else does to.
However, that doesn't mean I have to accept it as is, one must be
allowed to make some constructive critisism.
- Frank
---
a fair bit of
that work myself, but I don't have time to continuously maintain the
site. It would be nice for someone to finally take over and after making
those changes actively maintain the site and add some other cool
features.
I would also recommend that you work together with Nick Leippe
Oops, sorry for including all of the previous message in my reply. I
probably shouldn't have sent this right after coming home from the pub!
- Frank
On Sun, 2002-06-23 at 02:06, Frank Worsley wrote:
> Hi Ian,
>
> to upload the new site you have to tar it up, then do the follo
Hi Ian,
to upload the new site you have to tar it up, then do the following:
scp tarball.tar.gz [EMAIL PROTECTED]:/home/groups/d/dr/dri/htdocs/
Then login to dri.sf.net with ssh and your SF user id and untar the site
into a temporary directory. Make sure its 'chmod a+r'.
Cheers,
-
3D stuff. While I could probably hack some improvements to that
situation, I'm not as inclined because I've got no info on the tuning, etc.
of the 3D support.)
--
Frank Earl
___
Don't miss the 2002 Sprint PCS Applicatio
battle. We have an
NDA with them, but they won't disclose anything other than the 2D and MPEG
support portions of the chip to us.
--
Frank Earl
___
Don't miss the 2002 Sprint PCS Application Developer&#
ly saw when attempting to compile the
kernel sources included with earlier versions of Mandrake.
--
Frank Earl
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://dev
uences quickly mapping and unmapping memory reigons into userspace
has on the system? We've got a couple of the DRM modules that do that to
ensure the driver is secure. I'm thinking it's a source of some performance
degredation in the drivers and i
-which-I-dont-recall-the-name... I'm
> getting more and more inclined towards a robust implementation, like
> unmapping buffers, which probably won't have a significant performance
> impact, and which will give us much freedom to control the card properly.
> Well, time will a
had this last line of thought
while I was mowing the yard (still doing yardwork...). I was going to plug
in your test case, the one José just came up with, and my proposed one into
my test driver code and see what comes out from all of
x27;s not
really something you want to do often (just like you don't want to do ioctls
all that often either... :-)
--
Frank Earl
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28
le time. Buffer aging could still be used in the
> interrupt driven model, so that's not really a constraint of one approach
> versus the other. I don't think it would be too difficult to test both
> methods without too much change in the basic code infrastructure.
Works for me.
sets the DMA engine settings to what they should be for the third
descriptor? I'd say it'd depend on what the chip was actually doing- what do
you guys think?
--
Frank Earl
___
Don't miss the 2002 Sprint PCS Application
, as to which is more effiicient, that's still up to debate. I can't say
which is going to be faster overall. There's the aging in your design that
allows for buffers being released sooner than in mine. There's the need for
serialization in your design that is unreq
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
> On 2002.05.25 17:16 Frank C. Earl wrote:
> Frank, Leif was pretty clear and I quote:
>
> "it IS possible to derail a bus master in progress and set it
> processing from a different table in mid-stream. Plus, if th
mean that the CPU will
> be a little more stressed, and that we have much more code to do...
If you guys don't mind, I'd like to revisit the work by modernizing my branch
and finalizing what I'd started. I think it'd do well and make it secure
--
Frank Earl
___
already as secure as you're likely going to get with the
Mach64- the DRM is in the driver's seat the whole time for any submitted
data. Otherwise, you're going to be doing copying of some sort, which pretty
much burns up any speed advantages the "optimal" way of doing t
ts to possibly
confuse/hang the engine) with the design described to me back a little while
ago.
--
Frank Earl
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon
it's a good idea to replace
individual pages one at a time.
- Frank
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://
ryone can check it out.
If everyone agrees it's ready I will make it the main site.
- Frank
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.spr
DRI are employed by VA Linux and a bunch of other VA Linux stuff.
> > Anybody who can come up with an updated and nice sounding paragraph to
> > replace that, send it in and I will put it up.
Already done.
- Frank
_
is
> still prone to lock-ups, but most of the time it's recoverable.
What's it doing when it isn't recoverable?
(Oh, and can you flip me a diff of your sources from the current CVS? I've
got a little time and I want
the chip to
interrupt on the VBLANK and when it hits the midpoint scanline- that's
something like 120-160hz which is probably much more than the chip could
handle in rendering performance. I'm still voting for that one because it
gives cleaner error recovery...)
--
Frank Earl
ls from several other people promising to do the same,
but then nothing came from it. It's going to be interesting to see if
Ian will get it done.
Basically, anyone can do whatever they want - but don't expect any help
from me. :)
- Frank
P.S.: somebody else sent in this mockup for a ne
in
against the DRM DMA handler and vice-versa so that screen updates and other
stuff could be managed.
Unfortunately, my lack of available time precluded me from coding in more
than the base framework for that scheme.
--
Frank Earl
__
; until xrandr is done.
In that case, you'll have to make 2 "screen" environments... or have your
desktop at a sane resolution ;-)
Frank
--
homepage: www.student.kuleuven.ac.be/~m9917684
jabber (=IM): [EMAIL PROTECTED]
No part of this copyright message may be reproduced, r
olution? Or would I have to restart the X
> server at a lower resolution?
>
> That would be a nice thing to support, if it is possible to support
> it.
Since that game changes the X server's resolution, there is no problem at
all. There would be one if that game crash
have to do
something like NVidia did.
--
Frank Earl
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
egisters
at the end of a pass, there will be nothing a malicious client could do to
initiate their own passes, bogus or otherwise.
> I plan to build a test case for this, but I would like to hear preliminary
> opinions about this, in case I'm missing something. Frank, have you tested
ething, i.e. since I didn't test past one descriptor entry, it might be
that under some cases there's a loophole that allows someone to arbitrarily
fire off their own DMA operations...)- go right on ahead. I want this to be
the best performing solution for the chip, but also the most secure po
On Wednesday 01 May 2002 03:58 am, JosX Fonseca wrote:
> Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in
> own words:
>
> "Most of the first cut of the DMA code. It's got most of the
> dispatch
> architecture in place (Lacks actual D
ones? If it can't, you don't want to be
using that framework for this- you only need 16k aligned on a 16k boundary.
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
bit of fun keeping me from finishing it earlier
this week, but unless more fun comes my way I am still anticpating having
something in place that can be looked at if not used by the end of the week.
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
tc that is governed by the CTRC interrupt.). It may not
be quite what I have in hand, but as Gareth has said before, get it working-
I'm just waay to busy to have completed what I had in mind up until recently.
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
The idea was that people who don't have XFree86 4.1 or later can just
use the Extras package to upgrade their X server, instead of upgrading
all of X.
This worked pretty well in the past for people who had version problems
with the X server being too old for the binary package.
- Frank
O
Hi,
I'm getting repeated emails from people asking for an extras package.
Anybody want to volunteer to make one? All it needs to contain is an
updated X server binary and a shell script that installs the binary and
does suid root on it.
-
suedo DMA, why isn't it working right in DMA?" The mach64
has an issue with PPC machines where it just isn't happy with one of the
gears rotating in gears, but only if it's being DMAed to the chip- PDMA works
fine and both work as expected on x86 platforms... I
omment.
Thanks,
Frank
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
's always good to have
> more than just the latest snapshot since the trunk could go havoc
> sometimes.
>
> Does the the dynamic HTML code in the download page handle this?
>
It doesn't right now, but I will fix it so it
would break the installation script (and covers the libGL case).
You can find a README here:
http://dri.sourceforge.net/doc/install_readme.txt
I actually just emailed a note to Jens mentioning this too. :)
- Frank
___
Dri-devel mailing list
[EMAIL P
You can now grab the snapshots directly by following the 'Download' link
on the main DRI site. I have also updated the link for the FAQ on the
documentation page to point to the new location.
Cheers,
- Frank
___
Dri-devel mailing l
Submitted to Mesa3d at sourceforge as #529551
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
So far the last four revisions
of radeon-200203xx-04xx-i386-Linux.tar.bz2 haven't had the shiny
appearance either. I have been using X 4.2.0-6.xx built from source.
Has this enhancement been dropped from dri for now?
Thanks,
Frank
___
Dri-devel
on't need special clear commands or swap commands,
you only need to issue DMAable buffers of commands to the DRM engine for
eventual submission to the chip. Right now, I'm not 100% sure that the
mach64 is one of those sorts of chips, but it's shaping up to be a good
prospect for
ic operation when it's doing a command-type DMA.
It will not act on many of the settings after a DMA pass is complete.
It will not let you set up any sort of DMA pass during the operation.
Junk commands, by themselves, do not seem to hose up the engine in operation.
Mapping and unmapp
ings- I got the impression from the documentation that they were just out in
memory and were purely DMAed from anywhere in system memory.
Thank you for being patient and putting up w/me here... :-)
--
Frank Earl
___
Dri-devel maili
uld be a workable chipset for the pilot
project with my employer's planned product offerings- it would be a slow
chip, but it would allow me a way of demoing some 3D games, etc. on a set-top
box system. Now, well...
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
#x27;re doing in the command to start the buffer) then they can't
overwrite anything or be used to snag memory that doesn't belong to the app.
I'd have to double check the source code- I didn't see anything that parsed
vertex info i
these situations for us. While I know the chip is slow, is it
really needed to do this operation which is a very big bottleneck on
performance?
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
x27;re claiming on my end. I've got a PII-450 and it's peak with
Utah-GLX was ~250 fps with gears and something like a low 20-ish fps with
Q3A. I'm only seeing ~110 fps with the same machine and the PIO hack version
of the Mesa driver in the branch. Is a PIII-600 really nearly 2
ys for submitting verticies,
etc. This one doesn't. I'll recode it to accomodate no commands but pure
data- it's not just a pain, it's horribly inefficient with this card the way
it's designed.
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
busy "forever"- and end up being
deadlocked, thus hanging the console but good. If the XAA driver and the
kernel module could check unobtrusively for a locked up state and do a reset
if it is locked up, the situation would go from being an insecure one to a
relatively secur
G200/G400 and RagePRO (a.k.a. Mach64). I don't
know if it was included in any of the other drivers or not.
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
on the chip from all of our hacking about to get the DMA test working.).
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
>
> Sounds good, have you seen the log of the first meeting I put at
> http://dri.sourceforge.net/DRI-IRC-meeting-20020121.txt ?
>
Ok, I have added this.
- Frank
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourcefor
somebody emails this to me I will
add it to the website.
- Frank
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
new log as as question titled "IRC Log from ".
The first question in that section should probably be the schedule when
the meetings take place. Anybody who attends the meetings and wants to
post the logs let me know.
- Frank
On Wed, 2002-01-30 at 05:52, Jose Fonseca wrote:
> Frank,
>
there will be a new website. I
will keep you posted. :)
Cheers,
- Frank
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
t really technology- it's an API that drives the technology. MS
is very likely shopping more tech for DirectX.
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
love to
understand why I'm doing it this way while I'm coding it into the DRM... :-)
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
e the DMA stuff because I
> > think that perhaps Frank is very busy and he has no time to do this work.
> > The DMA problem was discovered aprox. Oct 21th and we have no news about
> > any progress in DMA. I'm sure that Frank would do it better than me,
> > but I can try
t the
comments in a long time. Anybody interested in cleaning up, let me know.
- Frank
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
g on putting together a better
status page with a card/chipset feature checklist. I am sure he could
use some help, so anybody intersted in that can help him out.
Anyway, just some ideas for little projects for anybody who wants to
contribute in some way.
Cheers,
- Frank
_
or not they are implemnted in DRI / driver or the
> > status of said function.
This has been discussed before but nothing has come out of it yet. It is
a good idea and we had a fairly detailed discussion about it outside of
the list.
> 1) Work with Frank Worsely regarding the content of
ed a
reminder...
Thanks
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Thursday 06 December 2001 10:58, you wrote:
> Frank, the buffer management problem has largely been solved. So has
> the PCI-based DMA (pcigart in r128). Just get it working in the context
> of the existing code, and then move onto more fancy things that are
> perhaps more s
because of varying things coming up (Like playing
the "scramble to find work" game as my employer's not making payroll...).
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Cs will pretty much hose up your machine. I
wouldn't be putting this in the HEAD until it's had a LOT of pounding on.
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Tuesday 20 November 2001 11:27 pm, you wrote:
> Yep, that's correct. Had to deal with missing and/or conflicting info
> to boot...
This sounds strangely familiar... :-)
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTE
don't think there's any more available from ATI than what we already have.
If memory serves, Gareth and John worked from the register docs and the 2D
coding info from the Programmer's guide.
--
Frank Earl
___
Dri-devel ma
holidays come around.
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
.)- we're
working on a driver right now for that chipset. Just follow the "mach64"
(the official designation from ATI for all the chips in the Rage/RagePRO
family) discussion to get a feel for things.
--
Frank Earl
___
Dri-devel mailing list
1 - 100 of 161 matches
Mail list logo
