Re: [Mesa-dev] cairo as state tracker
On Tue, Aug 9, 2016 at 8:11 AM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > On 07.08.2016 12:50, Marek Olšák wrote: > > > It would mainly be a futile task if it had to compete with their > > official Mesa driver. > > Not quite. Would give us all of gallium's capabilities also for > the intel chips, for example having lots of different state trackers. > (coming back to my original intention of cairo as a gallium st) > Gallium isn't an API you support it's a way you write your driver. Switching to gallium is a fundamental change in the way the entire driver is architected. It could be done (and recent changes in our driver are shrinking the dri portion so it's getting easier) but it's a massive pile of work with mediocre benefit. I could go on a very long rant about it but the short version is: If we were writing a new driver or if something came up that made gallium hugely benificial, we might consider it but at the moment, there's no good reason. As far as cairo goes, I'd much rather see the GL backend improved or a Vulkan backend added as those are both stable industry-supported APIs rather than running directly on gallium. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On Tue, Aug 9, 2016 at 11:11 AM, Enrico Weigelt, metux IT consult wrote: > On 07.08.2016 12:50, Marek Olšák wrote: > >> It would mainly be a futile task if it had to compete with their >> official Mesa driver. > > Not quite. Would give us all of gallium's capabilities also for > the intel chips, for example having lots of different state trackers. > (coming back to my original intention of cairo as a gallium st) > If you don't realize the complexity of a gpu driver, or the 100's of thousands of hours that have gone into i965, it's easy to say 'lets throw that all away and start from scratch with a gallium driver' ;-) There is ilo.. I suppose if someone cared enough they could add NIR support and figure out how to share the compiler back-end with i965, so it wouldn't be *completely* starting from scratch. But there is still a big delta between ilo and i965 in terms of features and supported hw gen's. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On 07.08.2016 12:50, Marek Olšák wrote: > It would mainly be a futile task if it had to compete with their > official Mesa driver. Not quite. Would give us all of gallium's capabilities also for the intel chips, for example having lots of different state trackers. (coming back to my original intention of cairo as a gallium st) --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On Sun, Aug 7, 2016 at 9:44 AM, Enrico Weigelt, metux IT consult wrote: > On 06.08.2016 19:17, Marek Olšák wrote: > >> The lack of interest from Intel is the main reason. > > And the other mesa folks also not interested ? > Would an conversion to gallium be a very complex task ? It would mainly be a futile task if it had to compete with their official Mesa driver. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On 06.08.2016 19:17, Marek Olšák wrote: > The lack of interest from Intel is the main reason. And the other mesa folks also not interested ? Would an conversion to gallium be a very complex task ? --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On 06.08.2016 19:46, Emil Velikov wrote: > You mentioned "cairo's gallium backend running again". Can you point > to the said code ? https://cgit.freedesktop.org/cairo/tree/src/drm/cairo-drm-gallium-surface.c > Can you elaborate why you're thinking against having the cairo > state-tracker in mesa ? Why not keep in within - even if that means > the occasional rebase, onto newer mesa. IIRC, cairo surface backends are internal to cairo (same as gallium w/ mesa). Optimally, I would prefer having it as an completely separate package, but than we'd have that problem on both sides. --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On 6 August 2016 at 15:59, Enrico Weigelt, metux IT consult wrote: > On 06.08.2016 13:16, Nicolai Hähnle wrote: > >> Well, in your first mail it sounded like you wanted to stabilize the >> Gallium API itself. > > Not actually stabilizing, but making it semi-public. (at dist level in > an separate package). Of course, external state trackers need to built > to the right gallium versions, but that can be handled at dist level. > Regardless of the naming - the intent and (mesa-dev) answer is clear. You mentioned "cairo's gallium backend running again". Can you point to the said code ? >> So to clarify, if you add a state tracker whose code lives in the Mesa >> repository, > > I do not. I intent to build an cairo device backend directly ontop of > gallium. And yes: I know that the API is in flux therefore the cairo > backend needs to be kept up-to-date. > Can you elaborate why you're thinking against having the cairo state-tracker in mesa ? Why not keep in within - even if that means the occasional rebase, onto newer mesa. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On Sat, Aug 6, 2016 at 5:03 PM, Enrico Weigelt, metux IT consult wrote: > On 06.08.2016 15:23, Marek Olšák wrote: > >> I'd recommend moving the cairo rendering code into Mesa and have Mesa >> implement and export some kind of a low-level cairo library. > > That would essentially create a circular dependency - and cairo's > surface backend API is also private. > >> Please note that Gallium doesn't support Intel GPUs, which may be a >> significant part of your user base. > > Not so much the intended userbase, but myself - working on an notebook > w/ i915. > > Is there any special reason why gallium doesnt support Intel GPUs > (besides that maybe just nobody cared yet) ? The lack of interest from Intel is the main reason. There are some Gallium drivers for Intel, but one of them is for ancient hardware and the other one was never intended to be a real driver. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On 06.08.2016 15:23, Marek Olšák wrote: > I'd recommend moving the cairo rendering code into Mesa and have Mesa > implement and export some kind of a low-level cairo library. That would essentially create a circular dependency - and cairo's surface backend API is also private. > Please note that Gallium doesn't support Intel GPUs, which may be a > significant part of your user base. Not so much the intended userbase, but myself - working on an notebook w/ i915. Is there any special reason why gallium doesnt support Intel GPUs (besides that maybe just nobody cared yet) ? --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On 06.08.2016 13:16, Nicolai Hähnle wrote: > Well, in your first mail it sounded like you wanted to stabilize the > Gallium API itself. Not actually stabilizing, but making it semi-public. (at dist level in an separate package). Of course, external state trackers need to built to the right gallium versions, but that can be handled at dist level. > So to clarify, if you add a state tracker whose code lives in the Mesa > repository, I do not. I intent to build an cairo device backend directly ontop of gallium. And yes: I know that the API is in flux therefore the cairo backend needs to be kept up-to-date. --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On Fri, Aug 5, 2016 at 6:48 AM, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > > I'd like to get the cairo's gallium backend running again (hasn't been > maintained for a long time and doesn't fit at all to recent mesa). > > The main problem I've got here is that gallium API is mesa-internal, > so I'd like to do some steps on making it (semi-)public. I'm aware that > it's still in flux, so we'll have an strict version dependency for > quite some time - but I can live with that for now. I'd recommend moving the cairo rendering code into Mesa and have Mesa implement and export some kind of a low-level cairo library. Please note that Gallium doesn't support Intel GPUs, which may be a significant part of your user base. A cairo GL backend is probably going to be your best choice if you want hardware support everywhere. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On 06.08.2016 10:49, Enrico Weigelt, metux IT consult wrote: On 05.08.2016 17:36, Ilia Mirkin wrote: The idea is that gallium is an unstable unversioned API, and if you want something else, then you make a state tracker which exposes a stable API. That's exactly what I intend: cario. Well, in your first mail it sounded like you wanted to stabilize the Gallium API itself. So to clarify, if you add a state tracker whose code lives in the Mesa repository, and this state tracker is a thin layer that exposes a stable API which is then consumed by Cairo, then I think people will be fine with that. Cheers, Nicolai --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On 05.08.2016 17:36, Ilia Mirkin wrote: > The idea is that gallium is an unstable unversioned API, and if you want > something else, then you make a state tracker which exposes a stable > API. That's exactly what I intend: cario. --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
The idea is that gallium is an unstable unversioned API, and if you want something else, then you make a state tracker which exposes a stable API. This can be an API for which there is a preexisting standard, like va-api or vdpau, or it can be one of your own creation which is consumed by some other project. I don't think that you will find much support for stabilizing and exporting the gallium API directly. On Aug 4, 2016 23:48, "Enrico Weigelt, metux IT consult" < enrico.weig...@gr13.net> wrote: > Hi folks, > > > I'd like to get the cairo's gallium backend running again (hasn't been > maintained for a long time and doesn't fit at all to recent mesa). > > The main problem I've got here is that gallium API is mesa-internal, > so I'd like to do some steps on making it (semi-)public. I'm aware that > it's still in flux, so we'll have an strict version dependency for > quite some time - but I can live with that for now. > > I haven't yet understood, how to the different pieces work together, > so any help is greatly appreciated. > > Let's start w/ a simple DRM usecase (no X involved). The big steps > would IMHO be: > #1: open the DRM device, setup fb and crtc > #2: map a framebuffer (in the first steps I'd like to use cairo's > image surface - IOW: softraster - and later move to gallium > operations step by step) > #2: initialize the GPU driver > #3: start sending some render commands to the GPU. > > Maybe someone could give me some hints on how these things actually > could look like ? > > > --mtx > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cairo as state tracker
On 05.08.2016 06:48, Enrico Weigelt, metux IT consult wrote: ... replying to myself... ;-o > Let's start w/ a simple DRM usecase (no X involved). The big steps > would IMHO be: > #1: open the DRM device, setup fb and crtc If I'm correct, the first thing to do is to get a proper winsys, right ? So, in my DRM case I would open the drm device and probe for the actual hardware and instanciate the corresponding winsys, eg. i915_drm_winsys. Then create a proper pipe for that device. Or just use the appropriate helpers in from drm-helper.h ? Is there some function that does all that, including the probing, together at once ? (some pipe_drm_create_screen(int fd) ...) > #2: map a framebuffer (in the first steps I'd like to use cairo's > image surface - IOW: softraster - and later move to gallium > operations step by step) Is that already done by the _*create_screen() step ? By the way: what exactly does struct pipe_screen represent ? An pipe and screen (for certain hw) together ? Is that the centerpiece of all further operations, similar to cairo's cairo_device_t ? --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] cairo as state tracker
Hi folks, I'd like to get the cairo's gallium backend running again (hasn't been maintained for a long time and doesn't fit at all to recent mesa). The main problem I've got here is that gallium API is mesa-internal, so I'd like to do some steps on making it (semi-)public. I'm aware that it's still in flux, so we'll have an strict version dependency for quite some time - but I can live with that for now. I haven't yet understood, how to the different pieces work together, so any help is greatly appreciated. Let's start w/ a simple DRM usecase (no X involved). The big steps would IMHO be: #1: open the DRM device, setup fb and crtc #2: map a framebuffer (in the first steps I'd like to use cairo's image surface - IOW: softraster - and later move to gallium operations step by step) #2: initialize the GPU driver #3: start sending some render commands to the GPU. Maybe someone could give me some hints on how these things actually could look like ? --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
