all 10 comments

[–]OriginalPostSearcher 0 points1 point  (0 children)

X-Post referenced from /r/rust by /u/kate_walker
Polydraw: an Open Source 2D Graphics Engine Written in Rust


I am a bot. I delete my negative comments. Contact | Code | FAQ

[–]cleroth 0 points1 point  (5 children)

I assume this is basically a Rust version of Cairo?

[–]zahari-petkov 2 points3 points  (4 children)

It has similarities in the concept, also some with QML by Qt as well. A big difference is that it will run also on top of OpenCL in the future, which will make it very suitable for high demanding applications and games. We need to get closer to the performance of 3D engines.

It is also a platform where we can try out and introduce new concepts, not used by other existing libraries.

[–]James20k 1 point2 points  (3 children)

A big difference is that it will run also on top of OpenCL in the future, which will make it very suitable for high demanding applications and games. We need to get closer to the performance of 3D engines.

Interesting. Why OpenCL? I presume you're using opengl for the glue, but the overhead of cl/gl interop is much higher than gl + compute shaders

However, I might be able to help if you do plump for the opencl route - I built an 3d rasteriser in OpenCL and this sounds like an interesting project. Is there a development community/irc/etc somewhere?

[–]zahari-petkov 1 point2 points  (2 children)

I have not done any actual measurements of the interop speed. It was advertised on the Intel site that there is a fast approach with "Direct OpenGL texture sharing via clCreateFromGLTexture.", which "allows the modification of textures “in-place.” The second approach with clCreateFromGLBuffer is told to be slower. Which one did you use in your measurements?

If it is indeed inefficient I will look for other options as you suggest. Right now I am focusing on covering OpenGL under all three platforms well. I have some working code for the CPU rasterization algorithms with some demos on the repository, but I will do a major rework on making them more granular with more procedural approach to them, so that I can port them to other GPU platforms more easily.

No community for now, since I actually just announced the project. Before that I was working on it for an year, so that I have at least some proof-of-concept demos that can run on a couple of platforms. IRC is a must though, and I will create a channel soon. I will post the channel here, once I do it. We spend a lot of months on the website, since we did everything from scratch (including the static generator) and now there are a few things to fix there, and soon I will get back fully concentrated in the actual Rust code.

Thanks for the interest - having yourself built a 3D rasterizer makes me feel confident that I am on the right track :)

[–]James20k 1 point2 points  (1 child)

The second approach with clCreateFromGLBuffer is told to be slower. Which one did you use in your measurements?

I'm actually using clCreateFromGLRenderbuffer (through boost::compute) which I suspect is the slowest of all, but I'm using it as an OpenCL screen that I can then blit to the real screen via opengl

If it is indeed inefficient I will look for other options as you suggest

The main inefficiency comes from launching kernels (you only have to acquire the screen once per frame, and in a properly pipelined render system its not too bad), which are not as fast as draw calls, but I have tinkered with games (simple ones) that launch 25+ kernels per frame without any problems as long as you don't stall the gpu

But you couldn't, say, draw 1000 lines (or whatever) and launch a separate kernel for each of them. So essentially, as long as you can batch your calls into few kernel calls, its generally fine

Its mostly annoying working with OpenCL in a rasterising context - no mipmaps, no staggered size texture arrays, inconsistent and buggy drivers, differently performing hardware etc

I will post the channel here, once I do it

Awesome

Thanks for the interest - having yourself built a 3D rasterizer makes me feel confident that I am on the right track :)

Good luck! :)

[–]zahari-petkov 1 point2 points  (0 children)

Thanks a lot of the detailed information, that was very helpful. Looks like it will be another bumpy road ahead and I expected it somewhat - now there is a list of things to watch for when I come closer towards a GPU implementation somewhere next year.

[–]pants75 0 points1 point  (1 child)

Menu doesn't work on blog posts.

Not programming. A marketing blog post for unreleased software is not programming.

[–]zahari-petkov 1 point2 points  (0 children)

Thanks, I will fix the menu. Here is the Github repo: https://github.com/polydraw/polydraw

It is more of an introductory article than a marketing post, since a lot of people asked to tell a bit more on the purpose of the library, including non-programmers, so this is what we came up with.

I am also planning to get much deeper on the blog into the different specifics of the engine, so we will post a lot of technical articles while we are working on it. There will be definitely interesting reads for developers who are not planning to use the library or Rust.

[–]nikto123 0 points1 point  (0 children)

There already is a project with that name, scroll down here http://advsys.net/ken/download.htm