On Thu, 16 May 2019 at 10:59, Jean Hertel <jean.her...@hotmail.com> wrote:
>
> On 8th May you Wrote:
> >Hi Emil,
> >
> >>This is the tricky part - wish I could find my notes they have better
> >>brain-dump.
> >>It's OK to have the library as both front (config tool) and backend
> >>(used by mesa) although:
> >> - special care on splitting and annotating the API is needed
> >> - handling this "extra" dependency would be fiddly for slower moving
> >> distros
> >>
> >I'm not sure I get the whole picture of what you are suggesting, so I put
> >some ideas on how I think such API would work [here][1].
> >
> >>> What about the current configuration files? Do you think there is a
> >>> better way to handle them?
> >>> They are for in a xml format, which is far from optimal.
> >>>
> >>What seems to be the problem with XML? The files are meant to be
> >>read/written to $app.
> >>
> >
> >I dislike XML because it is too ugly. Something more natural and easy to
> >read/write would be more interesting.
> >Like a YML format. Ideally I would like to use JSON, but then it becomes a
> >lot harder for people to write this by hand in case the GUI tools don't
> >offer >the options they want/need.
> >Of course this is just my point of view, and not necessarily a real issue.
> >
> >Kind Regards,
> >Jean Hertel
> >
> >[1]: https://github.com/jlHertel/libdriconfig/blob/master/USAGE.md
>
> Hey Emil,
> Did you get a chance to look in my proposed way of building this new API?
>
> Some comments would be welcome.
> Also, CC'ing Rob, as I think he would also have interest in this.
>
Had a quick look and noticed a few architectural nits.
I am a bit split between opaque structs vs not - slightly leaning
towards the former.
Reason being is that doing internal re-design becomes much easier and
we're baking less ABI into the users.
The following seems reasonable flow:
- enumerate devices
- query specifics - pci id/platform, memory, driver (kernel and/or
mesa), supported APIs (GLX,EGL,GBM, GL,GLES, NINE, VDPAU/OMX? Vulkan)
- set specifics - mesa driver at least (think amdgpu vs amdgpu-pro
on same kernel module)
[backend specific]
- create device - sets the details ... APIs will be a bit fiddly
- delete device - do we really need it? figure out the details
- enumerate_apps/profiles (device) - there's special handle for the
global/default profile
- query - name, executable, options
- set
[not backend specific]
- create/delete
- create_from_{global,other_profile)
- enumerate_options(device, API_MASK /* say GL_THREAD is GLX|EGL */, profile )
- query_option - type/value
- set_option - type(?)/value
[backend specific]
- create/delete
The tricky part wrt the fronend/backend mentioned earlier is that we
don't want !misc application to say "hey device/driver X can support
feature Y, on API Z".
Only the backend (mesa) is allowed to do that ;-)
HTH
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
