Update on 3D accelerated boards

What is the latest on supporting 3D accelerated hardware boards? Previously,
the Voodoo card was the one QSSL had in mind supporting, but 3dfx went out
of business. Last year, I asked and got the reply that the next version of
Photon would support hardware accelerated 3d.
Is QSSL still persuing this direction?
Thanks
Markus

I don’t think 3dfx was ever was the only one on their mind. It simply
was the only one with open-sourced 3D hardware acceleration code (Glide)
which was simply too easy to port.

As for other boards, they probably will support ATI, Matrox and Nvidia
with next major Photon release. What is interesting though is what are
their plans for software 3D rendering (perhaps accelerated through MMX
or such)? Currently there is a lot of conceptual inconsistency in video
support, in a sense that there’s no unified ‘capabilities model’ mapped
into either hardware or software methods. Some features are only
supported by those drivers and other features are only supported by
other drivers…

  • igor

Markus Loffler wrote:

What is the latest on supporting 3D accelerated hardware boards? Previously,
the Voodoo card was the one QSSL had in mind supporting, but 3dfx went out
of business. Last year, I asked and got the reply that the next version of
Photon would support hardware accelerated 3d.
Is QSSL still persuing this direction?
Thanks
Markus

with next major Photon release. What is interesting though is what are

Is this just a “feeling” or do you know anything for sure?
I’d like to hear somebody from QSSL about that.

their plans for software 3D rendering (perhaps accelerated through MMX
or such)? Currently there is a lot of conceptual inconsistency in video

Would that be useful? I’m using software 3D rendering currently and it is
very slow.
I don’t know how much MMX or such would help.

support, in a sense that there’s no unified ‘capabilities model’ mapped
into either hardware or software methods. Some features are only
supported by those drivers and other features are only supported by
other drivers…

That doesn’t sound like a good thing… Is there anything in progress to
provide some capability model?

Thanks
Markus


  • igor

Markus Loffler wrote:

What is the latest on supporting 3D accelerated hardware boards?
Previously,
the Voodoo card was the one QSSL had in mind supporting, but 3dfx went
out
of business. Last year, I asked and got the reply that the next version
of
Photon would support hardware accelerated 3d.
Is QSSL still persuing this direction?
Thanks
Markus

Markus Loffler <loffler@ces.clemson.edu> wrote:

support, in a sense that there’s no unified ‘capabilities model’ mapped
into either hardware or software methods. Some features are only
supported by those drivers and other features are only supported by
other drivers…

That doesn’t sound like a good thing… Is there anything in progress to
provide some capability model?

There is a `capability model’. An application can find out what features are
supported and which are not on a given card. We don’t attempt to simulate
features that the hardware doesn’t support like video overlay, and that’s
intentional.

<pete@qnx.com> wrote in message news:98lq4e$cc1$1@nntp.qnx.com

Markus Loffler <> loffler@ces.clemson.edu> > wrote:

support, in a sense that there’s no unified ‘capabilities model’ mapped
into either hardware or software methods. Some features are only
supported by those drivers and other features are only supported by
other drivers…

That doesn’t sound like a good thing… Is there anything in progress to
provide some capability model?

There is a `capability model’. An application can find out what features
are
supported and which are not on a given card. We don’t attempt to simulate
features that the hardware doesn’t support like video overlay, and that’s
intentional.

Then it would not hurt to have some ‘capabilities matrix’ in docs, so we
know what features are part of the model. And for that matter it would not
hurt to have devg-xxx drivers documented at all.

Oh well, they are (on the ‘supported hardware’ page) but that is not really
documentation, just some terse notes. And features are mentioned in rather
chaotic manner which makes it hard to see the whole picture.

As for querying system for supported capabilities, the docs I have (patch B)
mention only one function for that - PhQuerySystemInfo. Its description say
you can query ‘capabilities’ and refers to ‘System Information’ in ‘Regions’
chapter of ‘Programming Guide’. One hardly could find more obscure place to
document that stuff. Anyway, when you get there, you learn that there is
PhGeneralSysInfo_t structure containing ‘capabilities’ member but it is ‘not
in use’. LOL!

Road to hell is paved by good intentions.

  • igor

Igor Kovalenko <kovalenko@home.com> wrote:

Then it would not hurt to have some ‘capabilities matrix’ in docs, so we
know what features are part of the model. And for that matter it would not
hurt to have devg-xxx drivers documented at all.

Noted. I doubt if we would commit the capabilities matrix to paper though
since it can change as we have time to implement deeper support for some
chipsets.

As for querying system for supported capabilities, the docs I have (patch B)
mention only one function for that - PhQuerySystemInfo. Its description say
you can query ‘capabilities’ and refers to ‘System Information’ in ‘Regions’
chapter of ‘Programming Guide’. One hardly could find more obscure place to
document that stuff. Anyway, when you get there, you learn that there is
PhGeneralSysInfo_t structure containing ‘capabilities’ member but it is ‘not
in use’. LOL!

Ha ha. Yes, that’s very funny… especially since you are looking in the
wrong place.

Try PgGetGraphicsHWCaps and PgGetVideoModeInfo .

Road to hell is paved by good intentions.

I figure the road to hell isn’t paved at all. I bet there isn’t even a road.

Previously, Mario Charest wrote in qdn.public.qnxrtp.photon:

pete@qnx.com> > wrote in message news:98lvgk$fv5$> 1@nntp.qnx.com> …
Igor Kovalenko <> kovalenko@home.com> > wrote:

Road to hell is paved by good intentions.

I figure the road to hell isn’t paved at all. I bet there isn’t even a
road.

I bet there isn’t even a hell

Oh, there is. I used to work there.

<pete@qnx.com> wrote in message news:98lvgk$fv5$1@nntp.qnx.com

Igor Kovalenko <> kovalenko@home.com> > wrote:

Then it would not hurt to have some ‘capabilities matrix’ in docs, so we
know what features are part of the model. And for that matter it would
not
hurt to have devg-xxx drivers documented at all.

Noted. I doubt if we would commit the capabilities matrix to paper though
since it can change as we have time to implement deeper support for some
chipsets.

As for querying system for supported capabilities, the docs I have
(patch B)
mention only one function for that - PhQuerySystemInfo. Its description
say
you can query ‘capabilities’ and refers to ‘System Information’ in
‘Regions’
chapter of ‘Programming Guide’. One hardly could find more obscure place
to
document that stuff. Anyway, when you get there, you learn that there is
PhGeneralSysInfo_t structure containing ‘capabilities’ member but it is
‘not
in use’. LOL!

Ha ha. Yes, that’s very funny… especially since you are looking in the
wrong place.

Try PgGetGraphicsHWCaps and PgGetVideoModeInfo .

Road to hell is paved by good intentions.

I figure the road to hell isn’t paved at all. I bet there isn’t even a
road.

I bet there isn’t even a hell

Previously, Andrew Thomas wrote in qdn.public.qnxrtp.photon:

Oh, there is. I used to work there.

So tell us, is it exothermic?

Mitchell Schoenbrun --------- maschoen@pobox.com

Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.photon:

Previously, Andrew Thomas wrote in qdn.public.qnxrtp.photon:

Oh, there is. I used to work there.

So tell us, is it exothermic?

It was hard to tell. Too far north for any generated heat to be
trapped and measured. Come to think of it, we spent a lot of effort
on heat production, so I’m going to say endothermic. I know this is
opposed to a rather good proof I read somewhere, but dammit, I’m
sticking to it.

Andrew

Mario Charest <mcharest@void_zinformatic.com> wrote in message
news:98mko3$rro$1@nntp.qnx.com

pete@qnx.com> > wrote in message news:98lvgk$fv5$> 1@nntp.qnx.com> …
Igor Kovalenko <> kovalenko@home.com> > wrote:

Then it would not hurt to have some ‘capabilities matrix’ in docs, so
we
know what features are part of the model. And for that matter it would
not
hurt to have devg-xxx drivers documented at all.

Noted. I doubt if we would commit the capabilities matrix to paper
though
since it can change as we have time to implement deeper support for some
chipsets.

As for querying system for supported capabilities, the docs I have
(patch B)
mention only one function for that - PhQuerySystemInfo. Its
description
say
you can query ‘capabilities’ and refers to ‘System Information’ in
‘Regions’
chapter of ‘Programming Guide’. One hardly could find more obscure
place
to
document that stuff. Anyway, when you get there, you learn that there
is
PhGeneralSysInfo_t structure containing ‘capabilities’ member but it
is
‘not
in use’. LOL!

Ha ha. Yes, that’s very funny… especially since you are looking in the
wrong place.

Try PgGetGraphicsHWCaps and PgGetVideoModeInfo .

Road to hell is paved by good intentions.

I figure the road to hell isn’t paved at all. I bet there isn’t even a
road.

I bet there isn’t even a hell

How big is your bet?? :slight_smile: