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