Hi,
Will there be drivers Vulkan for mali t6xxx?
but if you run a subset of the API vulkan, it normally should work vulkan. The more that it is the driver that runs
I don't know how much clearer I can be ....
>>> There is no Vulkan driver for Mali-T620 <<<
Kind regards,
Pete
I understand that there is no
My only question is why is not ? if the driver is (even if the test)
annoy nothing will not help:)
As per the presentation you linked the prototype we mentioned is nowhere near a complete Vulkan implementation - it was only a bare bones prototype to prove the speed of the common code paths (e.g. cost of draw construction and issue). You can't actually use it to render anything real - it's a test bench, not a production quality driver.
Also, a full conformant Vulkan implementation requires additional hardware support which is only present in Mali-T760 onwards.
ie on the basis of the test driver can not build a "normal" driver? why? still base is.
the architecture is still the same as in mali t760 - midgard. If you can create a driver for mali t760 (midgard) it is possible create for mali t620 (midgard)
Hi kubuzz,
Forgive me if I am wrong, these are simply examples of the things APIs tend to bump.. texture sizes and mapping types and compression formats, shader language support for particular features and precisions (and don't forget the implicit OpenCL requirement which is related), and the ability to do a lot of things which weren't even envisioned as necessary or even possible in graphics technologies when older GPUs were in the design stages.
Several APIs have dictated features and extensions which are required to claim a certain level of conformity - the first implementations of GPUs do not have hardware support for those features, although they may implement SOME extensions to APIs which map to later revisions of those APIs. OpenGL tends to be defined from the point of view of making particular extensions from a previous version a standard so that all users of the API can guarantee their existence. Let's go back in time to the early 1990's and recall that you can rely on multitexturing support in OpenGL 1.2, but it used to be an extension before that - it was uncommon to see hardware that didn't support it, but it did exist. While the newer implementations of hardware, since they were designed with those new levels of conformity in mind or supported the extension, then could advertise OpenGL 1.2 support, for older hardware the mimicry of such a feature was a phenomenal amount of work in software - to manually blend many layers of texture together in pure software or by cleverly performing several manual passes in hardware, and then use single-texturing for the result (this is actually more difficult than it sounds as we didn't have access to the result of each pass as easily as we do these days with shaders and buffer objects )
For OpenCL, as another more modern example, one of the bigger differences between OpenCL 1.1 and OpenCL 1.2 was a requirement for full IEEE 754 compliance - both in precision and rounding modes, and accuracy of particular primitives like square root. Some processor (and GPU..) architectures implement what is called a reciprocal square root estimate, combined with an iterative refinement (Newton, Taylor or what have you), which requires that the initial estimate be somewhere close enough, and that the several approximation iterations to gain precision - you loop until you're even closer to the actual value (but you'll never get there..). It's possible to provide the same level of accuracy as non-reciprocal-estimate methods, but does it at the cost of having to take longer to do so. As a thought experiment, consider the instructions to generate the reciprocal and then the iterative refinement to be 1 cycle each, and requiring 8 iterations (=9 cycles total) to get within 90% of the precision of a 12 cycle square root instruction. If you want to get to 95% of the true square root, then you might have to add 3 more iterations, and if you want 96% you may need to add 3 more. At this point you're taking 3 cycles longer to be only within 4% of the required value. If you don't need the high precision you can use fewer rounds of approximation, and get the work done faster. If you rely on that result to calculate lighting or shadow, and it is inaccurate, then you get some distracting visual effects.
The only way to wrap older GPUs around newer specifications is implement software fallbacks (worst case) or somehow convert the features to ones you do support - this might be decompressing textures in software, then either re-compressing textures on the fly, or using uncompressed textures to preserve quality, vastly increasing the bandwidth requirements. It could be emulating primitives in hardware by using complex combinations of different primitives. The theme tends to be that to support any feature which isn't present, you have to submit significant amounts of extra work and processing to the system to achieve it.
It would not benefit the Mali ecosystem to provide the Vulkan API, and run Vulkan applications which expect a certain level of conformity and features, and also be forced to guarantee to provide the lower framerates, higher bandwidth requirements and less efficient CPU and GPU usage as a result of mapping these requirements to hardware which does not meet the specifications of the Vulkan standard. This is the antithesis of what Vulkan was designed to solve, and is definitely not a good method of convincing people on the benefits of a particular GPU or a particular graphics API.
So it doesn't exist, and won't exist.
Ta,
Matt