headers
César Catrián C. | 3 Feb 2006 01:46

Hardware acceleration to future

Hi.

Recently I started switching from i386 to the amd64 arch. That implies new 
hardware and options. I've been using NetBSD since five years, for desktop and 
server use, and I would like to ask about an estimate for the release of a 
hardware acceleration technology. For example, which would be supported 
first on NetBSD: NVIDIA or the graphics cards that work with DRI.

Please don't answer to this with "I don't know". I only want some estimate
date (from now to ... let's say... two or three years, which technology will be
supported first). Please take the answer without any responsibility =)

Thanks and regards

--
César Catrián Carreño
http://mioficina.cjc.cl/
Permalink | Reply | 2 comments |
headers
Damien Touraine | 3 Feb 2006 20:52
Favicon

DRI ...

Hello,

I downloaded the patch proposed by Tonnerre last june. I use a recent 
kernel (cvs update 25th January 2006).

I had to modify several things inside the driver (mainly : struct proc 
-> stuct lwp and comment "typedef drm_device_t *device_t;").

When I modload the lkm, the kernel says :
info: [drm] Found ATI Radeon Lf R250 Mobility 9000 M9 on the street
info: [drm] Attaching ATI Radeon Lf R250 Mobility 9000 M9
[drm:radeon_init]
[drm:radeon_agp_init] agp_available = 1
info: [drm] AGP at 0xe8000000 64MB
[drm:radeon_ctxbitmap_next] drm_ctxbitmap_next bit : 0
[drm:radeon_ctxbitmap_init] drm_ctxbitmap_init : 0
info: [drm] Initialized radeon 1.11.0 20020828 on minor 0

However, when I run X-window (xorg 6.9.0), the kernel says : "error: 
[drm:radeon_open] *ERROR* No such device: radeon0".

It seems that the DRM(cd) is not intialized and the size of the cd_devs 
array is nul. In other words, the cfdriver struct is not initialized 
with the right  parameters.

Is there any significant change inside the kernel and kernel modules 
since june ? Where could I find such kind of information ? Where could I 
find the documentation on how to implement a driver ?

I know that DRI is i386 specific, but why don't you integrate it inside
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tonnerre LOMBARD | 3 Feb 2006 21:18

Re: DRI ...

Salut,

On Fri, Feb 03, 2006 at 08:52:05PM +0100, Damien Touraine wrote:
> I had to modify several things inside the driver (mainly : struct proc 
> -> stuct lwp and comment "typedef drm_device_t *device_t;").

Please don't bother wasting time on the DRM code on my website, it is
the old outdated multicore DRM. What needs to be done is a full port of
the bsd-core DRM. However, I am still largely occupied with trying to
move things in European Parliament and on the swiss national level, as
well as with building communication between people...

I hope to be able to invest time in this project by the end of this
month, but that may be illusionary.

				Tonnerre
Permalink | Reply | 0 comments |
headers
Matthias Scheler | 5 Feb 2006 13:11
Picon
Favicon

Re: Hardware acceleration to future

In article <20060202214616.36f7a087.ccatrian <at> eml.cc>,
	"=?UTF-8?Q?C=C3=A9sar_Catri=C3=A1n?= C." <ccatrian <at> eml.cc> writes:
> ... and I would like to ask about an estimate for the release of a 
> hardware acceleration technology. 

No estimates at the moment. I'm not sure whether anybody is working on
this at all at the moment.

> ...For example, which would be supported first on NetBSD: NVIDIA or
> the graphics cards that work with DRI.

I'm sorry but that question doesn't make any sense. NVIDIA is a vendor for
graphics card. DRI is a kernel software interface (in Linux, FreeBSD or
both, not sure) which allows hardware acceleration which works AFAIK
with NVIDIA cards and drivers, too.

	Kind regards

--

-- 
Matthias Scheler                                  http://scheler.de/~matthias/
Permalink | Reply | 1 comment |
headers
Martin Husemann | 5 Feb 2006 16:57
Picon

Re: Hardware acceleration to future

On Sun, Feb 05, 2006 at 12:11:20PM +0000, Matthias Scheler wrote:
>  NVIDIA is a vendor for
> graphics card. DRI is a kernel software interface (in Linux, FreeBSD or
> both, not sure) which allows hardware acceleration which works AFAIK
> with NVIDIA cards and drivers, too.

DRI is not able to express the nice features of modern graphic cards - so
vendor provided binary only drivers like the nvidia one "work around" it.

DRI can, of course, be expanded to cope, but you'd need to convice vendors
like nvidia to "fix" their drivers then.

Neither of this works on NetBSD, and for DRI that would not be very hard
to fix. For the binary only nvidia driver, I don't think *we* can fix it
reasonably at all. (Yes, there exist ... uhm, let's say ... evil hacks
that could be used for the latter, but the basic point is: DRI is much
more likely to become officialy supported any time soon)

Martin
Permalink | Reply | 0 comments |
headers
Jukka Salmi | 24 Feb 2006 14:02
Picon

X Error of failed request: BadAtom (invalid Atom parameter)

Hi,

after connecting to a remote system using ssh -X, starting e.g.
xclock(1) works fine, but starting nedit(1) (pkgsrc/editors/nedit)
fails:

$ nedit
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Atom id in failed request:  0x62
  Serial number of failed request:  20
  Current serial number in output stream:  20

Both systems run NetBSD current. Any hints?

TIA, Jukka

--

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Permalink | Reply | 2 comments |
headers
Martin S. Weber | 24 Feb 2006 14:17
Picon

Re: X Error of failed request: BadAtom (invalid Atom parameter)

On Fri, Feb 24, 2006 at 02:02:10PM +0100, Jukka Salmi wrote:
> Hi,
> 
> after connecting to a remote system using ssh -X, starting e.g.
> xclock(1) works fine, but starting nedit(1) (pkgsrc/editors/nedit)
> fails:
> 
> $ nedit
> X Error of failed request:  BadAtom (invalid Atom parameter)
>   Major opcode of failed request:  20 (X_GetProperty)
>   Atom id in failed request:  0x62
>   Serial number of failed request:  20
>   Current serial number in output stream:  20
> 
> Both systems run NetBSD current. Any hints?
> 

Try ForwardX11Trusted=yes in your config or adding -Y to the ssh cmd
line (see man ssh_config /ForwardX11Trusted and its implications)

hth,

-Martin
Permalink | Reply | 1 comment |
headers
Jukka Salmi | 24 Feb 2006 15:12
Picon

Re: X Error of failed request: BadAtom (invalid Atom parameter)

Martin S. Weber --> tech-x11 (2006-02-24 14:17:10 +0100):
> On Fri, Feb 24, 2006 at 02:02:10PM +0100, Jukka Salmi wrote:
> > Hi,
> > 
> > after connecting to a remote system using ssh -X, starting e.g.
> > xclock(1) works fine, but starting nedit(1) (pkgsrc/editors/nedit)
> > fails:
> > 
> > $ nedit
> > X Error of failed request:  BadAtom (invalid Atom parameter)
> >   Major opcode of failed request:  20 (X_GetProperty)
> >   Atom id in failed request:  0x62
> >   Serial number of failed request:  20
> >   Current serial number in output stream:  20
> > 
> > Both systems run NetBSD current. Any hints?
> > 
> 
> Try ForwardX11Trusted=yes in your config or adding -Y to the ssh cmd
> line (see man ssh_config /ForwardX11Trusted and its implications)
> 
> hth,

It does, thanks!

Jukka

--

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
(Continue reading)

Permalink | Reply | 0 comments |

Gmane