Mesa currently includes several drivers for embedded systems that mostly focus on (or can only do) OpenGL ES (GLES) (e.g. lima, panfrost, etnaviv, freedreno). It would be rather useful to add GLES into docs/features.txt in order to be able to track the status of these drivers. For instance, getting to know the current status of the GLES implementation on Lima would be useful for the Replicant project. Unfortunately the Lima devs cannot had it to features.txt (check https://gitlab.freedesktop.org/lima/mesa/issues/102 )
> It would be rather useful to add GLES into docs/features.txt in order to be able to track the status of these drivers. https://gitlab.freedesktop.org/mesa/mesa/blob/3a7e92dac538e1ad76b42590beeaada28e79bb07/docs/features.txt#L243 https://mesamatrix.net As I can see GLES3.1 and GLES3.2 is already there. Freedreno and etnaviv supported features is already filled. So what missing is GLES2.0, GLES3.0, Panfrost and Lima, right?
Yes indeed. GLES 1.1
Yes indeed. GLES 1.0/1.1 would also be useful because that's probably where Lima it at right now. I have now updated the bug title to make it more precise. I'll make sure to ask Lima and Panfrost devs to add in their status as soon as the required fields for GLES 2.0 and 1.0/1.1 are available on features.txt
(In reply to dllud from comment #2) > Yes indeed. GLES 1.1 (In reply to russianneuromancer from comment #1) > > It would be rather useful to add GLES into docs/features.txt in order to be able to track the status of these drivers. > > https://gitlab.freedesktop.org/mesa/mesa/blob/ > 3a7e92dac538e1ad76b42590beeaada28e79bb07/docs/features.txt#L243 > > https://mesamatrix.net > > As I can see GLES3.1 and GLES3.2 is already there. Freedreno and etnaviv > supported features is already filled. > > So what missing is GLES2.0, GLES3.0, Panfrost and Lima, right? Is it really possible to advertise anything less than gles2? gallium (mesa state tracker) implements fixed function gl1/gles1 in terms of programmable pipeline. There isn't much in the way of features that gles1 has that doesn't exist in gles2 (maybe user-clip-planes, and there is a lowering pass to support that for hw that doesn't support it natively.. since a lot of modern hw dropped support for that). So I think the only thing to do is just add panfrost and lima. And now that we are using drm_shim to run shader-db in CI for a few drivers (freedreno and vc4), I'm secretly hoping someone comes up w/ a way to generate features.txt (at least for drivers w/ drm_shim support) by running glxinfo in CI, since features.txt requires that developers remember to actually update it.
(In reply to Rob Clark from comment #4) > > Is it really possible to advertise anything less than gles2? ok, to answer my own question, I guess it is. But from a quick look at the code, (AFAICT) panfrost is only ARB_texture_cube_map away from gles2, so not sure that adding gles1/gles2 section is that useful
(In reply to Rob Clark from comment #4) > And now that we are using drm_shim to run shader-db in CI for a few drivers > (freedreno and vc4), I'm secretly hoping someone comes up w/ a way to > generate features.txt (at least for drivers w/ drm_shim support) by running > glxinfo in CI, since features.txt requires that developers remember to > actually update it. I took a look at drm_shim [1] and it seems that this tool helps faking the driver at the kernel level, is that it? If it is, what I'm not so sure is how that tool works. Looking at the readme, I don't understand the backend options. I was hoping to see the same drivers as the ones listed in features.txt. So.. apparently I'm missing something.. Could you explain it to me? (you can PM me if you'd rather not go too off topic on this thread). [1] https://gitlab.freedesktop.org/anholt/drm-shim
(In reply to Creak from comment #6) > (In reply to Rob Clark from comment #4) > > And now that we are using drm_shim to run shader-db in CI for a few drivers > > (freedreno and vc4), I'm secretly hoping someone comes up w/ a way to > > generate features.txt (at least for drivers w/ drm_shim support) by running > > glxinfo in CI, since features.txt requires that developers remember to > > actually update it. > > I took a look at drm_shim [1] and it seems that this tool helps faking the > driver at the kernel level, is that it? If it is, what I'm not so sure is > how that tool works. Looking at the readme, I don't understand the backend > options. I was hoping to see the same drivers as the ones listed in > features.txt. So.. apparently I'm missing something.. Could you explain it > to me? (you can PM me if you'd rather not go too off topic on this thread). > > [1] https://gitlab.freedesktop.org/anholt/drm-shim hmm, [1] looks like an older iteration of drm-shim.. have a look at: ./src/freedreno/drm-shim ./src/broadcom/drm-shim in the mesa src tree. They are an $LD_PRELOAD'd thing to spoof enough of the kernel uabi to "run" the driver. Ie. you can't actually do drawing, but it is enough to run shader-db. And so I think it should be pretty much enough to run glxinfo.
(In reply to Rob Clark from comment #7) > hmm, [1] looks like an older iteration of drm-shim.. have a look at: > > ./src/freedreno/drm-shim > ./src/broadcom/drm-shim > > in the mesa src tree. They are an $LD_PRELOAD'd thing to spoof enough of > the kernel uabi to "run" the driver. Ie. you can't actually do drawing, but > it is enough to run shader-db. And so I think it should be pretty much > enough to run glxinfo. Thanks! Are broadcom and freedreno the only two drivers having drm-shim? Because in order to generate entirely features.txt, I guess all the drivers should have it, right?
(In reply to Creak from comment #8) > (In reply to Rob Clark from comment #7) > > hmm, [1] looks like an older iteration of drm-shim.. have a look at: > > > > ./src/freedreno/drm-shim > > ./src/broadcom/drm-shim > > > > in the mesa src tree. They are an $LD_PRELOAD'd thing to spoof enough of > > the kernel uabi to "run" the driver. Ie. you can't actually do drawing, but > > it is enough to run shader-db. And so I think it should be pretty much > > enough to run glxinfo. > > Thanks! Are broadcom and freedreno the only two drivers having drm-shim? > Because in order to generate entirely features.txt, I guess all the drivers > should have it, right? currently yes perhaps mesamatrix.net could pull data from a different sources for drivers that run glxinfo in CI?
Maybe if you're going down that route we could use the information to update https://people.freedesktop.org/~imirkin/glxinfo/ too
(In reply to Rob Clark from comment #9) > perhaps mesamatrix.net could pull data from a different sources for drivers > that run glxinfo in CI? I was thinking of generating features.txt by scrapping the mesa C code as explained in this issue: https://github.com/MightyCreak/mesamatrix/issues/150 But I don't know if it's doable yet, and if it is, it's a pretty huge undertaking. (In reply to Mike Lothian from comment #10) > Maybe if you're going down that route we could use the information to update > https://people.freedesktop.org/~imirkin/glxinfo/ too I linked Ilia's webpage on the about page in mesamatrix, it is not really tracking the same data as mesamatrix though. If I were to use Ilia's data, I would probably end up with the exact same information, but just presented differently, which would not be very useful. Mesamatrix's goal is simply to have a graphical representation of features.txt.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/949.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.