Did you commit some of the bugs you ficed in r5beta01 already? 'cos here the "random" drawer name doesn't show up ;-/ using my compiled/build executable.
NOTE: using my odyssey build for posting this, just for test.
@Javier There were only one real bug, and this one in repo already. I build beta1 just with new 3dparty libs, which being tested to be sure that we can use them and after we can replace them in repo.
Can you explain more about "random" issue ? My first bet anyway that you use not plain sdk 53.30, but or older one or beta one
@javier Random name drivers was fixed by Hans, we discuss it few posts above and in other thread. You also can see it was commited on github (check githubs history). Its already in beta1 of course, so dunno why you mention it :) Are you have that issue still on beta1 ? Or you simple didnt follow too close?:)
From our tests with warp3dnova/ogles/gl4es , SDL2, DOSBOX, and compositing in all our projects, the current conclusion is that compositing always faster than gl4es/nova/ogles/minigl whatever. And that not even about DMA, but just probably because OpenGL is a more massive thing and need more to initialize just for some simple things.
That depends entirely on how those projects use OpenGL and compositing. Are they using CompositeTags() to do everything that you'd otherwise do using OpenGL? Or, is rendering done in software, and then compositing is used to finally render it to screen?
Quote:
Also, have too many layers between not very helpful too. If there should be "rendering to the GPU", it should be then warp3dnova backend for Cairo, but then again no_dma.
The cairo-gl backend already exists; a Warp3DNova backend doesn't. Trying out the GL backend is way easier and faster than writing a new one from scratch. **
Quote:
Taking the same no-DMA situation, but on compositing, always faster from all the tests than non-DMA on OpenGL, which always hit 100% CPU and busy everything when uploading textures and whatever else it does internally.
Sounds like poor use of OpenGL to me... I have no idea how good or bad the Cairo GL backend is, which is why I asked if you'd tried it.
Quote:
Yes, writing compositing backend will take time sure, but it will work everywhere...
I don't think that a Compositing backend is feasible. Compositing can't do text rendering, or a whole bunch of other operations that Cairo does. Things such as gradient fills of shapes are technically possible, but would be much slower than if it were done in a shader. Partially GPU accelerating the rendering will likely increase how much data is transferred back and forth between RAM <=> VRAM, so you'll hit the lack of DMA bottleneck again.
The one thing that might work, is to use compositing to merge layers that are software rendered by Cairo with the video player's imagery. That way the javascript video controls could still be rendered on top of the video.
Hans
** Added to that, the latest WebKit no longer relies on Cairo, so we'd be better off doing the same...
** Added to that, the latest WebKit no longer relies on Cairo, so we'd be better off doing the same...
They have "WinCairo" route for windows builds, so probabaly that route can be re-used too if there will be needs in..
But for new browser it all probably will be not matter, as for new one there will be needs to build independent few components : webcore & javascriptcore , like libraries, or like classes, and then, anynyone can use them as wish in any app (like morphos devs plans to do, and that imho right way)
Let me backtrack a bit. You can use compositing for text using a "texture atlas" and vertex arrays. It's complex line and shape drawing that would be a challenge. Not sure if those features are even needed for HTML rendering, although they're probably needed for Javascript canvases.
@Hans Tried in meantime to compile an old version of Cairo used with odyssey (1.2.16), and it has GL and GLES2 backends. I only tried GL one, and at least able to compile libcairo.a with gl4es includes for GL backend.
Through in that version, they wrote that "gl backend is experimental" blabal, but what worries me most, is that all their gl-example (at least in that version) use Xwindow+glx and stuff. And Cairo have cairo_glx_device_create() function for.
I currently testing if it works at all, but, I not sure how it all will fit into an Odyssey. I mean, searching just in the whole Odysseys code, I didn't find any cairo_create_surface or cairo_device, but lots of cairo_image_surface_create(). This means that this "image surface" is used way in Odyssey. How to tell to WebKit (or to Cairo), to use by default "gl-surface over image-surface" if that possible at all, or how to tell to just use gl-surface is unknown for me, and probably all need rewriting.
See what is written on Cairo's site:
Quote:
Which steps should one usually take in order to get cairo-drawn vector-graphics into an OpenGL-rendered scene...
Setup your OpenGL-context, e.g. via SDL or gtk+/GtkGlExt.
Create your cairo-surface/context (maybe even glitz-based) you want to use as a source for later texture-map generation.
Render into the cairo-context with normal cairo-calls.
Copy the cairo-surface into an OpenGL-texture with glTexImage2D().
Use this texture to map your OpenGL-primitives with.
Rendering to the cairo-surface and copying that to the OpenGL-texture afterwards, can also be done in your rendering-loop, if you want to animate the cairo-graphics themselves from frame to frame.
For the time being disregard the idea of drawing into the same surface or texture with cairo- and OpenGL-calls. This is possible, but not in a very straight forward fashion. Also threadding-issues are not covered here at the moment. Everything happens in one thread right now.
So as far as i understand:
1). Additional code should be done inside of Odyssey 2). "copy surface into an OpenGL-texture" => fail because of no_DMA. Exactly the issues i have with any game and DosBox hitting 100% of cpu when texture uploading to the GPU and busy wait everything else.
Hmm. Those OpenGL instructions sound like you still use Cairo in software mode, and then upload the end result to an OpenGL texture. That's not what we want, and yes, compositing would be faster in this case.
We want to set up an OpenGL Cairo context that uses the cairo-gl backend. That way all rendering is done on the GPU via OpenGL. I did a quick search, but couldn't find an example on how to set up a cairo-gl surface. Will need to keep looking...
EDIT: I found an example, here. Looks like the key is cairo_glx_device_create() or similar (e.g., cairo_egl_device_create() might be easier given Huno's EGL lib), and cairo_gl_surface_create_for_texture().
EDIT: I found an example, here. Looks like the key is cairo_glx_device_create() or similar (e.g., cairo_egl_device_create() might be easier given Huno's EGL lib), and cairo_gl_surface_create_for_texture().
Yeah, i find that one too, but it use cairo_glx_device_create() which mean Xwindow (at least from the Cairo's code i can see it use all sort of glx + xwindow calls) , and anything for EGL is out as well, as Huno's EGL library are work in progress and pretty beta-aplha, as well as its not just "egl", but some combo of everything inside called egl-library (and it based on gl4es, which based on ogles2, which based on warp3dnova, so surely no go for a browser).
Besides, the problem remain that it need Odyssey rewrite in terms of cairo code to support it all.
Realisticaly we need to write out own warp3dnova-cairo backend, and after that rewrite Cairo code in ODyssey. But that again users without radeonHD/RX out of luck. And something make me thing its all not worth of hassle. I mean, too much time and resources should be spend on, and better in this case start with new browser from scratch and don't use Cairo at all anymore.
Yeah, i find that one too, but it use cairo_glx_device_create() which mean Xwindow (at least from the Cairo's code i can see it use all sort of glx + xwindow calls) , and anything for EGL is out as well, as Huno's EGL library are work in progress and pretty beta-aplha, as well as its not just "egl", but some combo of everything inside called egl-library (and it based on gl4es, which based on ogles2, which based on warp3dnova, so surely no go for a browser).
Besides, the problem remain that it need Odyssey rewrite in terms of cairo code to support it all.
We'd basically need a cairo_agl_device_create() for AmigaOS, and then we'd need to change Odyssey to use it. It won't be a complete rewrite. Changes would be needed where the Cairo context is setup, copied to screen, and destroyed.
Quote:
Realisticaly we need to write out own warp3dnova-cairo backend, and after that rewrite Cairo code in ODyssey. But that again users without radeonHD/RX out of luck. And something make me thing its all not worth of hassle. I mean, too much time and resources should be spend on, and better in this case start with new browser from scratch and don't use Cairo at all anymore.
Agreed. If we're going to write a new backend, then we're better off writing it for WebKit directly. Basically, it would turn HTML+CSS into a set of textures, vertex arrays, constants, and render operations that then get passed on to Warp3D Nova.
@kas1e Hello, For information the EGL rendering natively uses opengles and not gl4es Only SDLEGL and GLUES combined with EGL use GL4es Yes it is in beta but I can add functions which are not yet supported for your work if you wish PS: Gl4es is initialized at each start of EGL_ wrapper but not used in native EGL
@Huno Thanks, but it's for sure not me who will write that all code, as I have no skills and basically see no sense to move everything to GPU rendering. Because it will mean all users who can't use RAdeonHD/RX out of luck.
Besides, I understand how much of new bugs it will spawn in all the involved libs: and in EGL, and in Ogles and in Warp3dNova, and I do not have energy to waiting for bugfixes and cry for them for years as it was lately :) It can be ok to take some amiga-works at base other work on it if only bugs immediately fixes, but it's not the case with 3d libs involved.
@All Basically I think all those talks about the new surface for Cairo and move-to-GPU-rendering are just a cheap-talks, because who will do so? It will take a lot of time and no one knows which issues will arise with our 3d stuff in the process.
What is need it right now, it's:
1. fix bugs in media player and made MediaPlayer use compositing for playing (so works everywhere). 2. fix crash on exit in javascript's freeblock() when we run on debug-kernel 3. update core as much as possible
Yes, let's shelve the graphics backend talk for now, and focus on bug-fixing. Fixing those is more pressing, and easier to get done.
@all If someone does want to take on GPU acceleration, the first step is to get the cairo-gl backend working outside of Odyssey (e.g., using Cairo examples or test code). How well or poorly that works will tell us if it's worth the effort of updating Odyssey to use it.
Do remember that, going forward, we'll want to update WebKit and bypass Cairo altogether (either through it's OpenGL Backend, or a custom AmigaOS one). That's a longer term project, though...
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
