Philipp Klaus Krause wrote:
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.
Right. T
Hamie wrote:
Hi.
A quick status report/feedback on how the r300 effort fares on my
workstation.
Hardware is an AMD64 3200 (Socket 939, on an Asus A8V Deluxe
Motherboard). 1GB RAM dual channeled (2x 512MB sticks) and a Saphire
Radeon 9600 card (Mobility Radeon 9600 M10 - PCI ID 1002,4e51
I've added in the pci-id's for the Saphire 9600 AGP card. As it has 2
pci-id's, I've added both to the pciids file, and added it into
radeon_screen, but left the seocnd head commented out on radeon-screen.c
as I'm unsiure whether or not it should be treeated separately...
Why does it appear as
Hi a..
I just got a Saphire radeon 9600 with 256MB of memory on it. lspci
reports is as two device though, one of which has a pci-id of 4e71,
which I can't find anywhere... Anyone know the details? And which
chipset it is?
:01:00.0 VGA compatible controller: ATI Technologies Inc M10 NQ
[Ra
Hamie wrote:
It's working...
Mostly... I get pretty good rates on glxgears... But get a funny error
about not enought verticies...
[EMAIL PROTECTED]:~$ glxgears
r300NewProgram, target=34336, id=0
vertex prog
r300NewProgram, target=34820, id=0
fragment prog
r300NewProgram, target=35104, id=
It's working...
Mostly... I get pretty good rates on glxgears... But get a funny error
about not enought verticies...
[EMAIL PROTECTED]:~$ glxgears
r300NewProgram, target=34336, id=0
vertex prog
r300NewProgram, target=34820, id=0
fragment prog
r300NewProgram, target=35104, id=0
ati fragment prog
Adam Jackson wrote:
On Saturday 29 January 2005 17:21, Hamie wrote:
This mornings cvs snapshot of Mesa using linux-dri config fails to
build. A missing drm.h file... It builds fine using linux-x86, but I
want it for the r300 stuff, so assuming I acytually need the linux-dri
build...
is there a
This mornings cvs snapshot of Mesa using linux-dri config fails to
build. A missing drm.h file... It builds fine using linux-x86, but I
want it for the r300 stuff, so assuming I acytually need the linux-dri
build...
is there a date tag I can use that will build?
TIA
Hamish Marson
--
Philipp Klaus Krause wrote:
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
Rogelio Serrano wrote:
On 2004-10-25 04:10:30 +0800 Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
If there weren't all those patents out there we might just try to
develop a free graphics chip.
I have thought about this (repeatedly - the idea gets very tempting
after asking for the docs for th
Alan Cox wrote:
What about if you want to use fb when in text mode (Because you get
200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
back & forth between X & fb... (i.e. how I currently use it but with
Alan Cox wrote:
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
User 1's game queues up 20ms of 3D drawing commands.
Process swap to user 2. ->quiesce() is going to take 20ms.
User 2's timeslice expires and we go back to user 1.
User 1 queues up another 20ms.
User 2's editor is never going to f
Patrick McFarland wrote:
On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
In some cases yes. The DRM is happy with the idea of the kernel being a
DRM client too.
Thats actually a pretty cool idea. For us that need to use the vesa
fbcon driver because
there is no nativ
Alan Cox wrote:
On Llu, 2004-09-06 at 21:58, Hamie wrote:
The fs -> SCSI interface is a logical one.
We just have to make the fb and DRI to hardware one logical.
OK. (Even) I follow that... :)
Unless you can have fb sitting on top of DRM of course... (I discount
DRM on-top of
Alan Cox wrote:
On Sul, 2004-09-05 at 23:11, Jon Smirl wrote:
What is the advantage to continuing a development model where two
groups of programmers work independently, with little coordination on
two separate code bases trying to simultaneously control the same
piece of hardware? This is a con
15 matches
Mail list logo
