Open ar-visions opened 1 year ago
ar-visions
commented
1 year ago Looks like we would need to handle the blending ops for clip inside of fragment otherwise? This is just my best guess at the moment. Not quite sure if I can get it working without this. For each feature, I'm enabling based on device feature support and storing it for using alternate routines at runtime.
Would a fragment shader approach be much slower for the blending ops? We could support more devices.
ar-visions
commented
1 year ago VK_CHECK_RESULT(vkCreateGraphicsPipelines(dev->vkDev, dev->pipelineCache, 1, &pipelineCreateInfo, NULL, &dev->pipelinePolyFill)); // <-- i think it would be best to convert the topology rather than avoid painting the polygons lol.
When I get this working would you like a patch for Apple use-case? Appreciate it!
I think the logic Ops will be far more difficult for me to patch up with performance in mind on this hardware. But I really want to get it working. Topology conversion is nothing. On Apple hardware, basically 70-80% of it we are looking at no primitives for fans which is annoying but not hard to patch. The logic ops used in drawing system is the elephant in the room I think. Probably will use a different shader for that approach. At the same time I will attempt to render circles faster than skia.
jpbruyere
commented
1 year ago validation layer: VK_ERROR_FEATURE_NOT_PRESENT: vkCreateDevice(): Requested physical device feature specified by the 9th flag in VkPhysicalDeviceFeatures is not available on this device.
deviceFeatures.logicOp = VK_TRUE; // <- 9th member on struct
I notice vkvg uses this. what does this break? how do you implement an alternate technique for what breaks?
This is a m2 mac mini pro
vkvg use it for the clear operator.
Looks like we would need to handle the blending ops for clip inside of fragment otherwise? This is just my best guess at the moment. Not quite sure if I can get it working without this. For each feature, I'm enabling based on device feature support and storing it for using alternate routines at runtime.
Would a fragment shader approach be much slower for the blending ops? We could support more devices.
The problem with in shader blending operations is that you need the current fragment color to compute resulting color. Vulkan introduced a new extension that gives to the hardware the opportunity to implement a fast path to do so. You may test it. I don't have the name of the extension in mind, I should look onto my work laptop, but I have a very strict non disclosure contract, so I hope you'll find that by yourself...There are older extensions in gl, maybe availaible to vulkan that allow reading the current fragment value, but they are known to be slow... Vulkan logic_op with extended operations would allows to cover the full classic 2d compositing operations. I'm not hurry on that point hoping drivers will one day support the full range of operators with the best hardware side optimizations....
VK_CHECK_RESULT(vkCreateGraphicsPipelines(dev->vkDev, dev->pipelineCache, 1, &pipelineCreateInfo, NULL, &dev->pipelinePolyFill)); // <-- i think it would be best to convert the topology rather than avoid painting the polygons lol.
When I get this working would you like a patch for Apple use-case? Appreciate it!
I think the logic Ops will be far more difficult for me to patch up with performance in mind on this hardware. But I really want to get it working. Topology conversion is nothing. On Apple hardware, basically 70-80% of it we are looking at no primitives for fans which is annoying but not hard to patch. The logic ops used in drawing system is the elephant in the room I think. Probably will use a different shader for that approach. At the same time I will attempt to render circles faster than skia.
Having no support for Fan for apple, I've disabled the pipeline creation, but yes, that's half the solution. The best quick solution is to emit triangle indices in the existing but not binded Index buffer of the context and draw triangle list with the same vertex buffer. You may provide the patch, I'll be happy to merge it.
Thank you for your report.
validation layer: VK_ERROR_FEATURE_NOT_PRESENT: vkCreateDevice(): Requested physical device feature specified by the 9th flag in VkPhysicalDeviceFeatures is not available on this device.
deviceFeatures.logicOp = VK_TRUE; // <- 9th member on struct
I notice vkvg uses this. what does this break? how do you implement an alternate technique for what breaks?
This is a m2 mac mini pro