Hello, GSoC community-bonding period is coming to a close. In lieu of this, the following is my list of current (and tentative) plans for GEGL GPU-support: 1. gegl_init & gegl_exit: Implement OpenGL initialization and finalization. Some OpenGL extension checks should also be included to insure the presence of essential OpenGL features we need. 2. GeglTile: Expose a mechanism to specify if a given tile should store its internal pixel data in main memory (RAM) or GPU memory. 3. GeglTile: Modify the existing CPU/RAM-based accessor methods to map OpenGL textures (using PBOs) to virtual memory when the tile's internal pixel data is stored in GPU memory. 4. GeglTile: Expose methods that set and get GPU-based pixel data as OpenGL textures. These methods will upload/download pixel data to/from the GPU when the tile's internal pixel data is stored in RAM. 5. Introduce a new GEGL class: GeglTileFactory. Objects of this class will consistently create GPU-based tiles only or CPU-based tiles only. 6. GeglTileSource: Include a tile factory in GeglTileSource. This insures that all tile sources are decoupled from the creation of the tiles they use. 7. Modify some tile sources to create tiles using their tile factories. The following is a list of current tile source classes that create tiles directly: GeglTileBackendRam GeglTileBackendFile GeglTileBackendTiledir (?) GeglTileHandlerEmpty GeglTileHandlerZoom GeglTileHandlerCache 8. GeglBuffer: Provide a mechanism (at construction-time?) to specify whether or not all cached GeglBuffer tiles are GPU-based. A GPU-based buffer will instantiate a tile factory that will create GPU-based tiles only. All sources (i.e. all sources in the buffer hierarchy) should inherit this tile factory. The same is also true for CPU/RAM-based buffers. 9. GeglBuffer: Provide GPU-based pixel data accessors. As per GeglTile, all CPU/RAM-based access on a GPU-based buffer will map the internal OpenGL textures to virtual memory. And all GPU-based access on a CPU/RAM-based buffer will upload/download pixel data to/from GPU memory. 10. Introduce a new GEGL class: GeglGpuBufferIterator. Objects of this class will use GeglBuffer's GPU-based pixel data accessors to iterate over the buffer's contents. 11. GeglNode: Detect if a GPU-based buffer should be used given the following constraints: a. OpenGL is supported in the host machine. b. All required OpenGL extensions are supported in the host machine. c. The GeglOperation attached to the GeglNode publishes GPU-support. 12. Implement GPU-support for some GeglOperations. I should probably start with point filter and point composer operations (as suggested by Øyvind) as they are the easiest to implement in OpenGL. I still have some issues to sort out. Particularly nasty is the problem of what texture formats we should use to store the pixel data. The problem is that not all texture formats are supported as render targets (shader outputs) for some GPU vendors. For example, we may be able to store RGBA pixels with 32-bit floating point channels (scRGB) but we can't really use that same format as output for our shaders (at least, for some GPU vendors). I still haven't investigated this thoroughly. The reference I'm using is slightly outdated (circa 2005). I'm still looking for further references and assurance. Perhaps, someone in this list could offer some help? As I've said, these are tentative. I'm still waiting for feedback from both the GEGL & OpenGL experts. If you have anything to say, please do. Your help is both needed and appreciated. As for the project's schedule, I will probably spend most of my time prototyping, implementing and testing items #1-#10 above. As such, the weeks before the mid-term will be used to code against GEGL's current buffer architecture. After the mid-term, I expect to implement #11-#12 above, benchmark some implemented GeglOperations and provide groundwork for GPU-support to other operations and resamplers. Kind regards, Daerd P.S. Please keep the criticisms constructive. :) _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer