开发者故事—王石 VK-GL-CTS测试套件适配与经验分享
发布时间：2023-02-18 12:30:55 所属栏目：系统 来源：互联网
导读：近期，深圳开鸿数字产业发展有限公司（以下简称深开鸿）VK-GL-CTS测试套件适配正式合入OpenAtom OpenHarmony（以下简称OpenHarmony）社区主干。作为将VK-GL-CTS测试套件合入OpenHarmony主干的代码提交者，我将与大家一起分享我们团队在适配与移植过程中的故
|
近期，深圳开鸿数字产业发展有限公司（以下简称“深开鸿”）VK-GL-CTS测试套件适配正式合入OpenAtom OpenHarmony（以下简称“OpenHarmony”）社区主干。作为将VK-GL-CTS测试套件合入OpenHarmony主干的代码提交者，我将与大家一起分享我们团队在适配与移植过程中的故事和经验，希望能给广大开发者一些参考。 我和我的团队 在我的团队里有OpenGL的专家，负责OpenHarmony图形接口适配；有兼容性专家，负责开源三方库的移植和与OpenHarmony系统的适配；有系统服务移植与版本构建的专家，负责版本构建与系统服务的稳定性移植与调试；有测试领域的专家，负责兼容性、稳定性、安全性测试等工作。团队成员在适配与移植工作中不断攻坚克难、通力合作，使得相关问题均得到闭环处理，最终顺利完成了这一项目。 VK-GL-CTS是Khronos开发的一套开源GPU测试套件，可用于开放标准OpenGL ES，EGL和Vulkan的测试，也是验证GPU驱动API的实现是否支持的官方标准。VK-GL-CTS的引入是对OpenHarmony生态共建的强有力的保护，补齐了OpenHarmony兼容性测试套件在GPU方向上的缺失，为社区之后能更好地看护OpenHarmony应用兼容性、API兼容性提供完备的保证，同时也为OpenHarmony兼容性测评提供助力。 困难与挑战 首先是对图形框架的移植挑战，OpenHarmony的图形框架不同于现在业界其他的图形框架，移植的初始就需要我们快速了解和分析OpenHarmony图形框架的模块组成和应用API；同时由于OpenHarmony的迅速发展，主线变更频繁，这就需要我们不但要了解图形框架的架构，而且要理解图形框架的设计原理，抽丝剥茧地抓住图形框架的主脉络。 其次是对OpenHarmony兼容性测试框架的理解和适配。VK-GL-CTS的全代码量有200多万行，100多万条测试项，为了适配OpenHarmony的XTS（X Test Suite）子系统，并且在后期能方便更新维护，我们运用了分层设计理念，开发出两个测试套件的适配层将两个测试框架进行解耦，并通过编译脚本，测试脚本等辅助工具对测试结果进行收集，分析形成报告。 最后是对标准建立的挑战。在VK-GL-CTS测试套件运行的测试结果，我们进行了多重对比和验证，对标业内成熟产品的数据，同时参考主流嵌入式硬件产品的测试数据，通过校准配置、测试数据及测试项目以及和社区开发者、硬件厂商的讨论初步建立OpenHarmony在GPU接口和功能方面的兼容性测评标准。 经验与总结 VK-GL-CTS测试套件适配覆盖图形框架、GPU驱动、编译框架、日志框架、兼容性测试框架等，涉及OpenHarmony的众多方面。在适配过程中，我们团队也在社区众多专家的帮助下克服了重重困难。如最初碰到的问题是signal11报错，OpenHarmony提供了faultlog，可以在开发版路径/data/log/faultlog里查看；然后又遇到测试报错问题，由于我们仿照rosen采用了线性扫描，但对测试用例来说线性扫描会导致某些情况下的色偏，于是我们改用GPU的默认设置；又因为开源合规问题我们引入OAT规则。 作为深开鸿的一名OS框架开发工程师，我很幸运能从事自己喜欢的职业，并且很荣幸能够加入OpenHarmony项目。未来，我将与团队伙伴们继续坚持技术研发，探索开源生态发展之路，并将提炼、沉淀出来的场景、技术贡献给OpenHarmony社区，真正践行“从开源中来到开源中去”的理念。我们坚信，未来以OpenHarmony为基础的智慧创新之路必将赋能千行百业，促进万物互联。 （编辑：娄底站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
