All of lore.kernel.org
 help / color / mirror / Atom feed
* [kirkstone] mesa compilation failures when setting PREFERRED_PROVIDER for virtual/gpudriver = "ti-sgx-ddk-km"
       [not found] <mail.64133faf.3771.17352b0439bf0805@storage.wm.amazon.com>
@ 2023-03-16 16:11 ` danny
  2023-03-16 16:28   ` [meta-ti] " Ryan Eatmon
  0 siblings, 1 reply; 5+ messages in thread
From: danny @ 2023-03-16 16:11 UTC (permalink / raw)
  To: meta-ti

[-- Attachment #1: Type: text/plain, Size: 3812 bytes --]

Hi all! I am trying to make sure my opengl-backed GUI application is leveraging the most optimal graphics drivers on the beaglebone black device and am running into yocto build failures.

 
Based on what I can tell from the changes in 56be461 (https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&id=56be4618abdde45649f0f92d383d5f44e5ec6efb), <https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&amp;id=56be4618abdde45649f0f92d383d5f44e5ec6efb),>  I should be able to have mesa compiled using the drivers provided from the `ti-sgx-ddk-km` recipe by setting my preferred provider for the `virtual/gpudriver` as such:

 
```

PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km"

```

 
I'm not sure if this is the correct way to go about what I am trying to do, or if it is even necessary to ensure my application is using the best hardware it can (which is ultimately the goal). Either way, with the variable mentioned above set to `ti-sgx-ddk-km`, the mesa.do_compile step fails with what I believe are linker errors. This is an example of what I am seeing in my logs:

 
```

/<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function `PVRDRIReleaseBuffer':

2023-03-15T19:19:43.7831698Z | /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1055: undefined reference to `PVRDRIBufferDestroy'
2023-03-15T19:19:43.7832402Z | /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function `PVRDRIAllocateBuffer':
2023-03-15T19:19:43.7833062Z | /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1027: undefined reference to `PVRDRIBufferCreate'
2023-03-15T19:19:43.7833813Z | /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1037: undefined reference to `PVRDRIBufferGetName'

```

 
The full(-ish, I might be missing some) list of these missing functions is:
 
- PVREGLDrawableDestroy
- PVREGLDrawableCreate

- PVRDRIPixFmtGetBlockSize

- PVRDRIEGLMarkRendersurfaceInvalid

- PVREGLDrawableRecreate

- PVRDRIBufferDestroy

- PVRDRIGetAPIFunc

- PVRDRIEGLGetLibHandle

- PVRDRIDepthStencilBitArraySize

- PVRDRIMSAABitArraySize

- PVRDRIDepthBitsArray

- PVRDRIEGLImageCreate

- PVRDRIMesaFormatSupported

- PVRDRIMaxPBufferWidth

- PVRDRIMaxPBufferHeight

- PVRDRIBufferCreateFromNames

- PVRDRIEGLImageCreateFromBuffer

- PVRDRIEGLFlushBuffers

- PVRDRIBufferCreate

- PVRDRICreateDrawableImpl

- PVRDRIMakeCurrentGC

- PVRDRIGetDeviceTypeFromFd

- PVRDRIEGLImageGetAttribs

- PVRDRI2ReleaseTexImage

 
I'm a bit out of my element here, but it looks like I might be missing some dynamically linked library that provides functions like PVRDRIBufferGetName which gallium depends on? It seems likely I am missing a recipe or configuration value, but I'm not sure where to look.

 
Any help here would be appreciated. I'd be happy to provide more logs and/or configuration information as necessary.

 
Thanks!

- Danny


[-- Attachment #2: Type: text/html, Size: 10275 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [meta-ti] [kirkstone] mesa compilation failures when setting PREFERRED_PROVIDER for virtual/gpudriver = "ti-sgx-ddk-km"
  2023-03-16 16:11 ` [kirkstone] mesa compilation failures when setting PREFERRED_PROVIDER for virtual/gpudriver = "ti-sgx-ddk-km" danny
@ 2023-03-16 16:28   ` Ryan Eatmon
  2023-03-16 16:34     ` Denys Dmytriyenko
  0 siblings, 1 reply; 5+ messages in thread
From: Ryan Eatmon @ 2023-03-16 16:28 UTC (permalink / raw)
  To: danny, meta-ti, Randolph Sapp


The idea behind that patch series is to rework how we incorporate the 
GPU drivers with the various software pacakges.  So, yes, that will be 
how you will include the SGX stuff.

But...  There was another patch that rolled back the SGX support to just 
software rendering because we have not had the time to complete the work 
on fxiing the SGX drivers to work with the new integration methodology.

So what you are trying to do, will not currently work in 
kirkstone/master until we finish the work to update the SGX code.

The only real option if you require the SGX GPU to work is to fallback 
to dunfell.


On 3/16/2023 11:11, Danny Hadley via lists.yoctoproject.org wrote:
> Hi all! I am trying to make sure my opengl-backed GUI application is 
> leveraging the most optimal graphics drivers on the beaglebone black 
> device and am running into yocto build failures.
> 
> Based on what I can tell from the changes in 
> 56be461 (https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&id=56be4618abdde45649f0f92d383d5f44e5ec6efb), <https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&id=56be4618abdde45649f0f92d383d5f44e5ec6efb),> I should be able to have mesa compiled using the drivers provided from the `ti-sgx-ddk-km` recipe by setting my preferred provider for the `virtual/gpudriver` as such:
> 
> ```
> 
> PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km"
> 
> ```
> 
> I'm not sure if this is the correct way to go about what I am trying to 
> do, or if it is even necessary to ensure my application is using 
> the best hardware it can (which is ultimately the goal). Either way, 
> with the variable mentioned above set to `ti-sgx-ddk-km`, the 
> mesa.do_compile step fails with what I believe are linker errors. This 
> is an example of what I am seeing in my logs:
> 
> ```
> 
> /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function `PVRDRIReleaseBuffer':
> 2023-03-15T19:19:43.7831698Z | 
> /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1055: undefined reference to `PVRDRIBufferDestroy'
> 2023-03-15T19:19:43.7832402Z | 
> /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function `PVRDRIAllocateBuffer':
> 2023-03-15T19:19:43.7833062Z | 
> /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1027: undefined reference to `PVRDRIBufferCreate'
> 2023-03-15T19:19:43.7833813Z | 
> /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1037: undefined reference to `PVRDRIBufferGetName'
> 
> ```
> 
> The full(-ish, I might be missing some) list of these missing functions is:
> 
> - PVREGLDrawableDestroy
> - PVREGLDrawableCreate
> 
> - PVRDRIPixFmtGetBlockSize
> 
> - PVRDRIEGLMarkRendersurfaceInvalid
> 
> - PVREGLDrawableRecreate
> 
> - PVRDRIBufferDestroy
> 
> - PVRDRIGetAPIFunc
> 
> - PVRDRIEGLGetLibHandle
> 
> - PVRDRIDepthStencilBitArraySize
> 
> - PVRDRIMSAABitArraySize
> 
> - PVRDRIDepthBitsArray
> 
> - PVRDRIEGLImageCreate
> 
> - PVRDRIMesaFormatSupported
> 
> - PVRDRIMaxPBufferWidth
> 
> - PVRDRIMaxPBufferHeight
> 
> - PVRDRIBufferCreateFromNames
> 
> - PVRDRIEGLImageCreateFromBuffer
> 
> - PVRDRIEGLFlushBuffers
> 
> - PVRDRIBufferCreate
> 
> - PVRDRICreateDrawableImpl
> 
> - PVRDRIMakeCurrentGC
> 
> - PVRDRIGetDeviceTypeFromFd
> 
> - PVRDRIEGLImageGetAttribs
> 
> - PVRDRI2ReleaseTexImage
> 
> I'm a bit out of my element here, but it looks like I might be missing 
> some dynamically linked library that provides functions like 
> PVRDRIBufferGetName which gallium depends on? It seems likely I am 
> missing a recipe or configuration value, but I'm not sure where to look.
> 
> Any help here would be appreciated. I'd be happy to provide more logs 
> and/or configuration information as necessary.
> 
> Thanks!
> 
> - Danny
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#15988): https://lists.yoctoproject.org/g/meta-ti/message/15988
> Mute This Topic: https://lists.yoctoproject.org/mt/97653905/6551054
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [reatmon@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

-- 
Ryan Eatmon                reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc.  -  LCPD  -  MGTS


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [meta-ti] [kirkstone] mesa compilation failures when setting PREFERRED_PROVIDER for virtual/gpudriver = "ti-sgx-ddk-km"
  2023-03-16 16:28   ` [meta-ti] " Ryan Eatmon
@ 2023-03-16 16:34     ` Denys Dmytriyenko
  2023-03-16 16:43       ` Danny
  0 siblings, 1 reply; 5+ messages in thread
From: Denys Dmytriyenko @ 2023-03-16 16:34 UTC (permalink / raw)
  To: reatmon; +Cc: danny, meta-ti, Randolph Sapp

On Thu, Mar 16, 2023 at 11:28:47AM -0500, Ryan Eatmon via lists.yoctoproject.org wrote:
> 
> The idea behind that patch series is to rework how we incorporate
> the GPU drivers with the various software pacakges.  So, yes, that
> will be how you will include the SGX stuff.
> 
> But...  There was another patch that rolled back the SGX support to
> just software rendering because we have not had the time to complete
> the work on fxiing the SGX drivers to work with the new integration
> methodology.

https://git.yoctoproject.org/meta-ti/commit/?id=d859c8c0916c8eb4b88ca8e0db7f9e5a846ba869


> So what you are trying to do, will not currently work in
> kirkstone/master until we finish the work to update the SGX code.
> 
> The only real option if you require the SGX GPU to work is to
> fallback to dunfell.
> 
> 
> On 3/16/2023 11:11, Danny Hadley via lists.yoctoproject.org wrote:
> >Hi all! I am trying to make sure my opengl-backed GUI application
> >is leveraging the most optimal graphics drivers on the beaglebone
> >black device and am running into yocto build failures.
> >
> >Based on what I can tell from the changes in 56be461 (https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&id=56be4618abdde45649f0f92d383d5f44e5ec6efb), <https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&id=56be4618abdde45649f0f92d383d5f44e5ec6efb),> I
> >should be able to have mesa compiled using the drivers provided
> >from the `ti-sgx-ddk-km` recipe by setting my preferred provider
> >for the `virtual/gpudriver` as such:
> >
> >```
> >
> >PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km"
> >
> >```
> >
> >I'm not sure if this is the correct way to go about what I am
> >trying to do, or if it is even necessary to ensure my application
> >is using the best hardware it can (which is ultimately the goal).
> >Either way, with the variable mentioned above set to
> >`ti-sgx-ddk-km`, the mesa.do_compile step fails with what I
> >believe are linker errors. This is an example of what I am seeing
> >in my logs:
> >
> >```
> >
> >/<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function `PVRDRIReleaseBuffer':
> >2023-03-15T19:19:43.7831698Z | /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1055:
> >undefined reference to `PVRDRIBufferDestroy'
> >2023-03-15T19:19:43.7832402Z | /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld:
> >src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function
> >`PVRDRIAllocateBuffer':
> >2023-03-15T19:19:43.7833062Z | /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1027:
> >undefined reference to `PVRDRIBufferCreate'
> >2023-03-15T19:19:43.7833813Z | /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1037:
> >undefined reference to `PVRDRIBufferGetName'


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [meta-ti] [kirkstone] mesa compilation failures when setting PREFERRED_PROVIDER for virtual/gpudriver = "ti-sgx-ddk-km"
  2023-03-16 16:34     ` Denys Dmytriyenko
@ 2023-03-16 16:43       ` Danny
  2023-03-16 16:50         ` [EXTERNAL] " Sapp, Randolph
  0 siblings, 1 reply; 5+ messages in thread
From: Danny @ 2023-03-16 16:43 UTC (permalink / raw)
  To: Denys Dmytriyenko; +Cc: reatmon, danny, meta-ti, Randolph Sapp

[-- Attachment #1: Type: text/plain, Size: 4318 bytes --]

Understood, thank you both for the speedy replies!

On Thu, Mar 16, 2023 at 12:35 PM Denys Dmytriyenko <denis@denix.org> wrote:

> On Thu, Mar 16, 2023 at 11:28:47AM -0500, Ryan Eatmon via
> lists.yoctoproject.org wrote:
> >
> > The idea behind that patch series is to rework how we incorporate
> > the GPU drivers with the various software pacakges.  So, yes, that
> > will be how you will include the SGX stuff.
> >
> > But...  There was another patch that rolled back the SGX support to
> > just software rendering because we have not had the time to complete
> > the work on fxiing the SGX drivers to work with the new integration
> > methodology.
>
>
> https://git.yoctoproject.org/meta-ti/commit/?id=d859c8c0916c8eb4b88ca8e0db7f9e5a846ba869
>
>
> > So what you are trying to do, will not currently work in
> > kirkstone/master until we finish the work to update the SGX code.
> >
> > The only real option if you require the SGX GPU to work is to
> > fallback to dunfell.
> >
> >
> > On 3/16/2023 11:11, Danny Hadley via lists.yoctoproject.org wrote:
> > >Hi all! I am trying to make sure my opengl-backed GUI application
> > >is leveraging the most optimal graphics drivers on the beaglebone
> > >black device and am running into yocto build failures.
> > >
> > >Based on what I can tell from the changes in 56be461 (
> https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&id=56be4618abdde45649f0f92d383d5f44e5ec6efb),
> <
> https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&id=56be4618abdde45649f0f92d383d5f44e5ec6efb
> ),> I
> > >should be able to have mesa compiled using the drivers provided
> > >from the `ti-sgx-ddk-km` recipe by setting my preferred provider
> > >for the `virtual/gpudriver` as such:
> > >
> > >```
> > >
> > >PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km"
> > >
> > >```
> > >
> > >I'm not sure if this is the correct way to go about what I am
> > >trying to do, or if it is even necessary to ensure my application
> > >is using the best hardware it can (which is ultimately the goal).
> > >Either way, with the variable mentioned above set to
> > >`ti-sgx-ddk-km`, the mesa.do_compile step fails with what I
> > >believe are linker errors. This is an example of what I am seeing
> > >in my logs:
> > >
> > >```
> > >
> >
> >/<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld:
> src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function
> `PVRDRIReleaseBuffer':
> > >2023-03-15T19:19:43.7831698Z |
> /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1055:
> > >undefined reference to `PVRDRIBufferDestroy'
> > >2023-03-15T19:19:43.7832402Z |
> /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld:
> > >src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function
> > >`PVRDRIAllocateBuffer':
> > >2023-03-15T19:19:43.7833062Z |
> /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1027:
> > >undefined reference to `PVRDRIBufferCreate'
> > >2023-03-15T19:19:43.7833813Z |
> /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld:
> /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1037:
> > >undefined reference to `PVRDRIBufferGetName'
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#15990):
> https://lists.yoctoproject.org/g/meta-ti/message/15990
> Mute This Topic: https://lists.yoctoproject.org/mt/97653905/7450809
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe:
> https://lists.yoctoproject.org/g/meta-ti/leave/12019981/7450809/1464620367/xyzzy
> [dadleyy@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 6191 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [EXTERNAL] Re: [meta-ti] [kirkstone] mesa compilation failures when setting PREFERRED_PROVIDER for virtual/gpudriver = "ti-sgx-ddk-km"
  2023-03-16 16:43       ` Danny
@ 2023-03-16 16:50         ` Sapp, Randolph
  0 siblings, 0 replies; 5+ messages in thread
From: Sapp, Randolph @ 2023-03-16 16:50 UTC (permalink / raw)
  To: Danny, Denys Dmytriyenko; +Cc: Eatmon, Ryan, danny, meta-ti

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Yeah,


In hindsight we should have started with no graphics recipes (software rendering) and slowly incorporated drivers as they are verified on this new branch. Would have been clearer what we were doing and prevent any suggestions of feature regression in the utilities themselves, but unfortunately I only came into this situation after the decision to clone everything was made.


I'm still working on fixing SGX and hopefully with the way I'm integrating it, we can cut down on future maintenance delays in the future. Unfortunately that means a little more upfront delay with hints in the layers incorrectly informing people that the driver is still operational. Sorry about that.


Regards,

Randolph Sapp

[-- Attachment #2: Type: text/html, Size: 1164 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-03-16 16:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mail.64133faf.3771.17352b0439bf0805@storage.wm.amazon.com>
2023-03-16 16:11 ` [kirkstone] mesa compilation failures when setting PREFERRED_PROVIDER for virtual/gpudriver = "ti-sgx-ddk-km" danny
2023-03-16 16:28   ` [meta-ti] " Ryan Eatmon
2023-03-16 16:34     ` Denys Dmytriyenko
2023-03-16 16:43       ` Danny
2023-03-16 16:50         ` [EXTERNAL] " Sapp, Randolph

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.