Following the discussions on CAN Stack thread, I’ve decided to shift my focus to more accessible at the moment project due to my current hardware limitations. I’m interested in porting PortableGL implementation of OpenGL to RTEMS. I’m particularly hooked by the join of embedded systems and graphics, both areas I’m passionate about. My background includes some work with graphics and computational geometry.
If I understand correctly, PortableGL does provide some practical subset for embedded and the i386/pc386 on QEMU is the target BSP for dev/test.
I’ll update this message as them [updates] occur.
Also opening the topic it to serve as a thread for the work on the issue
Great! With any porting effot there are usually a few common considerations for planning the proposal.
Can you build the software at all?
Can you run the software on anything?
Can you build the software with RTEMS?
Can you run the software with RTEMS?
Answering these questions will help you to frame the proposal and to plan the work. Once you know how to do #1-4, then you can consider what is the best way to integrate the software with RTEMS. Here again there are a few choices:
as the issue mentioned that mesa will be the ideal implementation, I wonder why you chose PortableGL instead of Mesa. Did you face any problems with mesa?
I’m aware that Mesa3D is more preferable and priority option mentioned in the issue. But the reason I’ve chosen PortableGL over Mesa is mostly the scope. Since it’s a self-contained, single-header library, it makes it more realistic to deliver it within GSoC timeframe, while the codebase of Mesa is significantly larger and more complex, I understand it’s the ideal long-term goal though.
I have now completed the initial porting of PortableGL to RTEMS and am preparing to start writing the proposal. I would like to ask what the final deliverable and expected demonstration outcome will be.
Yes, PortableGL apps compile and run on my machine.
I’ve tested that the default hello app with PGL headers build and run on i386/pc386, compiles and runs successfully. No rendering (expected).
I’ve also adopted, built and ran hello_triangle app from PGL repo testing pool. Here the triangle is rendered on the screen.
Both can be found in repo here and tested.
Regarding the question of choice: contrib or RSB recipe. After reading the topic I’m inclined to think that the second option (RSB build recipe) is a better choice, since the library is optional and not everyone requires graphics, the library isn’t legacy as well and is updated regularly. What are your considerations upon this?
I was just wondering, does implementing double buffering make any sense in the matter of porting PGL or not. So the main question is whether any animation stuff should have better support or the main goal is making PGL simply work on RTEMS fb?
Sorry for not posting progress updates recently. Based on your earlier suggestions, I’ve now clarified what the final deliverables should look like.
Among the three options in the project, Mesa3D is the most capable in terms of functionality, but it also requires an LLVM toolchain and is by far the most complex to port. Between the remaining two options—PortableGL and TinyGL—PortableGL is relatively feature-complete, and it is implemented as a single-header library (all functions are contained in portablegl.h). In practice, I only need to replace its SDL backend with an RTEMS framebuffer backend to achieve rendering on RTEMS. I’ve already completed an initial port of PortableGL to RTEMS and successfully rendered images on RTEMS.
Given this progress, I’ve become interested in the Mesa3D approach as well, and I’ve recently been exploring whether it might be feasible to port parts of Mesa3D to RTEMS.
With that in mind, I’d like to ask: for this “Porting OpenGL to RTEMS” project, is it expected that we port only one of Mesa3D, PortableGL, and TinyGL, or is it acceptable to select and port more than one of them?
I agree that an RSB recipe seems the most suitable solution here. Indeed, we have several graphics related packages in RSB already. I would suggest that you focus only on porting PGL on RTEMS fb as the primary goal, while you can certainly define additional stretch goals to work toward.
It is acceptable to select/scope multiple possible routes. Since this particular topic is on PortableGL, if you’d like to discuss the others then you could open a new topic for each as you see fit.
I’m working currently on a bset for PortableGL. I’ve created a working .cfg and .bset, which download the repo and place the header file to includes, but I have a couple of questions regarding maybe the better way of doing this.
PortableGL provides a generate_gl_h.py script to generate the final header. Is it ok to call python3 during the %build stage, since RSB itself is python-based? Or is it preferred to just use the pre-generated header already provided in the upstream repo?
I found many .cfg files include the %patch setup line even if no patches are applied. Well, I did the same, but should I keep it or should I remove?
I’m currently installing the header into %{_includedir}. Is it preferred to place it in a subdir (something like %{_includedir}/portablegl/) or it’s ok?
And regarding today’s situation with graphics in RTEMS. Do I understand it properly, that the current graphics support in RTEMS includes basic image decoding (libpng, libjpeg), Microwindows/Nano-X and decade-old RTEMS Graphics Toolkit, if not count the framebuffer driver?
At this stage, I think these are good questions to explore within your proposal. It sounds like going from a work-in-progress to a production-ready recipe should be pretty quick, so in terms of project scope you’re going to need to identify what else can be done.
Testing comprehensively across a few architectures and with a few graphics packages can also be a good thing. You might look into what other architectures you might be able to test with beyond i386, although any real boards would also require to have a compatible display and io driver supported.
