[haiku-development] Re: Hardware Accelerated 3D graphics

  • From: Paul Davey <plmdvy@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 20 May 2014 18:32:15 +1200

On Tue, May 20, 2014 at 1:27 AM, Stephan Aßmus <superstippi@xxxxxx> wrote:
> Am 19.05.2014 08:51, schrieb Paul Davey:
>
> Working on hardware accelerated compositing and rendering is a pretty
> substantial task. I think both of your questions are the smallest of
> worries. Changing the way it is decided which add-on to use should be
> trivial. And its not impossible to force the architecture of a Haiku
> component to x86 (GCC4). We do that for WebPositive for example. Indeed,
> applications are not affected, they communicate with app_server via a port,
> they don't link against it.

Indeed these don't factor much into initial discovery and of course I
will begin with prototyping first.

> Haiku has APIs for cloning the accelerant add-on of a graphics driver into
> the application. This affects app_server and applications alike. But the
> question is, what exactly will be the accelerant? It could also be a thin
> bridge to the component doing the real work. This already happens sort of,
> since the accelerant is a bridge to the kernel driver, handling the
> communication via ioctls and perhaps other means.

I am thinking atleast in the prototype of using the actual accelerant,
some amount of hardware specific interface is needed though so one
generic set of callbacks is not sufficient, though a way to fetch
another set of hooks that are known by the thing using that specific
accelerant could be used.

It is somewhat surprising for the intel accelerant and the radeon_hd
accelerant how much is handled in the accelerant, they seem to be more
like microkernel drivers where only what absolutely has to be in the
driver (doing the actual reads and writes and memory allocation) is in
the kernel and most of the work is done by the accelerant with some
low level interfaces provided by the driver.

> IMHO, porting Gallium shouldn't be focused on getting it to compile and
> inserted somewhere, I would research exactly where Gallium should live in
> the end, how everything should fit together, what the problems are at each
> level and I would prototype it first, without trying to port anything, yet.
> Making decisions greatly affects what is possible with the design later on.

I will be first of all trying to get atleast one gallium driver
working on haiku in some capacity, just to tell how much work is
needed to get hardware acceleration, after doing this I am sure that
much of this will have been learned to some extent.  I agree that
there should be provisions for future expansion to minimise the impact
of such changes.

> In MacOS, I understand almost any drawing function is implemented in
> hardware - text rendering, pretty much everything. However, there will
> always be some case which requires software rendering. And there will be
> cases where the application uses regular 2D drawing commands mixed with 3D
> OpenGL commands.

For a first goal I will try only to get OpenGL working, this is easy
to test and already has some applications.

> I would not try to make only the smallest necessary changes in
> an existing large code base and hope to tick off "hardware 3D" on the TODO
> list.

I don't want to try and hack this into haiku, the first iteration will
probably be somewhat hacky and mostly be about determining driver
improvements required, I will begin with the i915 family of intel
cards as I have hardware for testing.

> I hope I don't come across as rude or anything, it's just that my impression
> with any previous effort and from talking to people on IRC, it seems like
> everyone is trying to get gallium to compile and get away with minimal
> changes to the infrastructure of how app_server works right now. I am not
> convinced it can work this way.

Don't worry I understand, and this may result in some major rework of
the app_server internals but for now I will prototype first.

Regards,
Paul Davey

Other related posts: