As promised from the irc session... here's details on the little
32/64-bit issue I ran into.
Its not quite a direct 32/64 bit thing in the drm itself exactly, but
ambiguity can be a problem...
drm_map_t.offset is unsigned long.
unsigned long is semi-unspecified, but is reasonably assumed to
On Tue, 2003-03-04 at 08:22, Philip Brown wrote:
unsigned long is semi-unspecified, but is reasonably assumed to be
a 32-bit quantity.
On all 64bit bit platforms I have met unsigned long is a 64bit quantity.
In fact I can't think of a single exception
mmap() takes an arg of type off_t.
off_t
On Tue, 2003-03-04 at 05:00, David Bronaugh wrote:
I searched Google.
Here's the result I got:
ftp://download.intel.com/support/graphics/intel740/29061902.pdf
Looks like a pretty full spec to me. Hopefully it is.
Doesn't document any of the drawing commands/setup/mode change. Hardly
*As seen on TV*
The health discovery that reverses signs of aging naturally and that is completely safe and effective is on sale for a limited time! Buy a two-month supply of our product and we will give you one month free!
All natural H_G_H Enhancer will help you with all of the following:
-
On Die, 2003-03-04 at 01:52, Jonathan Thambidurai wrote:
I am pleased to report that thanks to the guidance Jens Owens gave in a
previous message, I have made 3D work on two heads simultaneously (IIRC,
the ATI Windows XP drivers didn't do this).
Coolness.
I have not provided a diff
So it's now fairly easy to build either a regular DRI driver, or an
fbdev/miniglx driver for the classic radeon on this branch.
Check out the branch, and look in Mesa/Makefile.include for configuration
options. People on this list probably aren't interested in the subsetted driver.
It's
Michel Daenzer [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/radeon/
Changes by: [EMAIL PROTECTED] 03/03/03 17:02:35
Log message:
Set Mesa hooks to flush vertices on state changes (Keith Whitwell)
Whps, it appears
On Tue, Mar 04, 2003 at 09:41:54AM -0800, Philip Brown wrote:
On Tue, Mar 04, 2003 at 01:27:28PM +, Alan Cox wrote:
On Tue, 2003-03-04 at 08:22, Philip Brown wrote:
unsigned long is semi-unspecified, but is reasonably assumed to be
a 32-bit quantity.
On all 64bit bit platforms I
On Tue, Mar 04, 2003 at 11:59:50AM -0600, Andy Isaacson wrote:
On Tue, Mar 04, 2003 at 09:41:54AM -0800, Philip Brown wrote:
On Tue, Mar 04, 2003 at 01:27:28PM +, Alan Cox wrote:
On all 64bit bit platforms I have met unsigned long is a 64bit quantity.
In fact I can't think of a single
Jose,
I've been on the road for the last few days, so I haven't had a chance
to express my concern for porting the DRI to C++. Please take these
concerns with a grain of salt as I am definitely in the old fuddy duddy
class (as Keith calls it) in that I'm not fluent in C++.
Concern #1:
Denis Oliver Kropp wrote:
Quoting Keith Whitwell ([EMAIL PROTECTED]):
So it's now fairly easy to build either a regular DRI driver, or an
fbdev/miniglx driver for the classic radeon on this branch.
Check out the branch, and look in Mesa/Makefile.include for configuration
options. People on
Hi,
I reported some time ago (Sat, 1 Feb 2003 22:38:44 +0100, message-id:
[EMAIL PROTECTED]) that return to Castle Wolfenstein
stutters with radeon 8500. The problem was traced to large memory usage
by the game. Back then, I did not know whether it was a problem with
the game or with XFree.
Pawel Salek wrote:
Hi,
I reported some time ago (Sat, 1 Feb 2003 22:38:44 +0100, message-id:
[EMAIL PROTECTED]) that return to Castle Wolfenstein
stutters with radeon 8500. The problem was traced to large memory usage
by the game. Back then, I did not know whether it was a problem with the
Philip Brown wrote:
On Tue, Mar 04, 2003 at 11:59:50AM -0600, Andy Isaacson wrote:
The 64-bit kernel is perfectly capable of running 32-bit binaries, and
that's precisely what you're doing.
Yes. And that's exactly what DRI users will do. So right there is a
64/32 bit problem.
[snip]
So kernel
Pawel Salek wrote:
Hi,
I reported some time ago (Sat, 1 Feb 2003 22:38:44 +0100, message-id:
[EMAIL PROTECTED]) that return to Castle Wolfenstein
stutters with radeon 8500. The problem was traced to large memory usage
by the game. Back then, I did not know whether it was a problem with the
Martin Spott [EMAIL PROTECTED] wrote:
Michel Daenzer [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/radeon/
Changes by: [EMAIL PROTECTED] 03/03/03 17:02:35
Log message:
Set Mesa hooks to flush vertices on state changes
Is anyone interested in developing OpenGL DRI
drivers for this card?
If anyone is, I would be willing to pay for drivers
- on the condition that they are Open Sourced. Please contact me for further
information or questions.
[C]arlos
Noguera
On Tue, 2003-03-04 at 05:19, Philip Brown wrote:
ah. Thanks for the extra info.
[someone might want to comment the thing in the header files]
Solaris handles it differently. It specifies a particular memory mapping as
needing sequential access, at map time, I believe.
The purpose of this
I'd be very interested in seeing your code, hacky or not. We were
actually just discussing this on this list and on the devel list at
xfree86.org. David Dawes said he has some preliminary work for setting
up multiple viewports into a single framebuffer. Sven Luther and
myself, among others,
On 2003.03.04 20:00 Ian Romanick wrote:
Pawel Salek wrote:
Today, I have run a molecular visualisation program on a RNA strand
(I usually deal with slightly smaller molecules) and I was surprised
when I noticed that the process occupied more than 200MB of memory.
Disabling the visualisation
Carlos Noguera wrote:
Is anyone interested in developing OpenGL DRI drivers for this card?
If anyone is, I would be willing to pay for drivers - on the condition that they are Open Sourced. Please contact me for further information or questions.
Is there any reason why you have to have support
Is there any reason why you have to have support for that card? AFAIK,
there is no documentation available for that card, and the company that
made the chip no longer exists (at least not in its previous form). Not
only that, there are MUCH better cards available for PCI and AGP that
perform
On Tue, 4 Mar 2003, Philip Brown wrote:
Does this thunking happen at the native OS level, or in the linux drm
code itself?
Each user has to thunk on its own, since nobody else even knows what the
ioctl stuctures are.
Moral of the story: avoid ioctl's. _Especially_ avoid ioctl's with
On Tue, 2003-03-04 at 18:12, Philip Brown wrote:
All numeric fields passed through the ioctls, should have fixed,
identifiable sizes.
I guess you do need a typedef then so you can support solaris without
trashing the other 99.999% of the userbase. In the Linux world the
ioctl32 handlers munge
On Tue, 4 Mar 2003, Ian Romanick wrote:
Is anyone interested in developing OpenGL DRI drivers for this
card? If anyone is, I would be willing to pay for drivers -
on the condition that they are Open Sourced. Please contact me
for further information or questions.
Is there any reason why you
On Tue, Mar 04, 2003 at 11:02:10PM +, Alan Cox wrote:
On Tue, 2003-03-04 at 18:12, Philip Brown wrote:
All numeric fields passed through the ioctls, should have fixed,
identifiable sizes.
I guess you do need a typedef then so you can support solaris without
trashing the other 99.999%
On Tue, 4 Mar 2003, Carlos Noguera wrote:
Is there any reason why you have to have support for that card? AFAIK,
there is no documentation available for that card, and the company that
made the chip no longer exists (at least not in its previous form). Not
only that, there are MUCH better cards
On Tue, Mar 04, 2003 at 09:18:40PM +0100, Benjamin Herrenschmidt wrote:
The purpose of this barrier isn not to ensure sequential access on
either the MMIO mapping (card registers) nor the actual ring buffer
memory mapping (could be IOs, or just real memory with PCI GART).
It's here to
On Tue, 2003-03-04 at 22:15, Philip Brown wrote:
I believe DaveM's DRM for the sparc64 linux is quite happy with
mixed 32/64 user space.
Probably it has the same size for unsigned long in both 32 and 64 bit
modes.
I don't think so. I think the DRM ioctls get munged properly
It works is
Carlos Noguera wrote:
Is there any reason why you have to have support for that card? AFAIK,
there is no documentation available for that card, and the company that
made the chip no longer exists (at least not in its previous form). Not
only that, there are MUCH better cards available for PCI
People have been mentioning the Voodoo specs are available but I've
googled for them and found nothing, anybody know where they are???
Tom
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code.
On 4 Mar 2003, Tom Hosiawa wrote:
People have been mentioning the Voodoo specs are available but I've
googled for them and found nothing, anybody know where they are???
http://www.medex.hu/~danthe/tdfx
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86
On Tue, 4 Mar 2003, Tom Hosiawa wrote:
People have been mentioning the Voodoo specs are available but I've
googled for them and found nothing, anybody know where they are???
http://www.medex.hu/~danthe/tdfx/ is one place.
---
This SF.net
Hi
v3tv.sourceforge.net has Voodo3 docs and the TV stuff for the V3 3500TV.
Bye
Alejandro Arrieta
CS Student UTFSM
Chile
On 4 Mar 2003, Tom Hosiawa wrote:
People have been mentioning the Voodoo specs are available but I've
googled for them and found nothing, anybody know where they are???
Jens Owen wrote:
Jose,
I've been on the road for the last few days, so I haven't had a chance
to express my concern for porting the DRI to C++. Please take these
concerns with a grain of salt as I am definitely in the old fuddy duddy
class (as Keith calls it) in that I'm not fluent in C++.
35 matches
Mail list logo
