Re: Porting / AMIGA / PiStorm32 / developer needed - Back to the roots

[Luke A. Guest]

Hi,

Some progress, on building, not testing:

$ find . -name 'lib*.a'
./src/compiler/isaspec/libisaspec.a
./src/util/libmesa_util_sse41.a
./src/util/blake3/libblake3.a
./src/gallium/frontends/osmesa/libosmesa_st.a
./src/gallium/drivers/softpipe/libsoftpipe.a

So, maybe it might just be possible.

Re: Porting / AMIGA / PiStorm32 / developer needed - Back to the roots

[Luke A. Guest]

The build could be worked to get a gles1 lib, which isn't optimal given 
the power of the pi's gpu.


On 18/04/2024 11:57, Luke A. Guest wrote:

On 18/04/2024 11:23, Luke A. Guest wrote:
I took a look at this over the last few days with the plan to use 
fs-uae to get the following built:


1. Static lib build.
2. Aim for GL 1.5.
3. swrast (softpipe) and osmesa.


I just disabled the compiler directory and found that libmesa depends on 
headers from glsl, and I cannot find anywhere where it's possible to 
restrict the built version of GL, so maybe it's not possible to build a 
restricted version?

Re: Porting / AMIGA / PiStorm32 / developer needed - Back to the roots

[Luke A. Guest]

On 18/04/2024 11:23, Luke A. Guest wrote:
I took a look at this over the last few days with the plan to use fs-uae 
to get the following built:


1. Static lib build.
2. Aim for GL 1.5.
3. swrast (softpipe) and osmesa.


I just disabled the compiler directory and found that libmesa depends on 
headers from glsl, and I cannot find anywhere where it's possible to 
restrict the built version of GL, so maybe it's not possible to build a 
restricted version?

Re: Porting / AMIGA / PiStorm32 / developer needed - Back to the roots

[Luke A. Guest]

On 12/04/2023 16:39, Brian Paul wrote:

On 4/12/23 02:30, Ignacio Soriano Hernandez wrote:

>

To use Brian Paul’s words:

The core library was originally (started in 1993) written on an Amiga 
using the DCC compiler. Later, development was moved to an SGI 
workstation.  Current development is done on PC/Linux systems.


Hard to believe it's been 30 years!

[snip]


I took a look at this over the last few days with the plan to use fs-uae 
to get the following built:


1. Static lib build.
2. Aim for GL 1.5.
3. swrast (softpipe) and osmesa.

I'm not familiar with PiStorm32/Emu68 but the first big issue may be 
that Mesa makes pervasive use of 64-bit datatypes (int64_t, uint64_t). 
Just from its name, PiStorm32/Emu68 sounds like a 32-bit environment. So 
unless your compiler has good support for emulating 64-bit types with 
32-bit operations, you may be out of luck.


That's not the biggest issue. The biggest issue seems to be the 
pervasive pthreading throughout the library, which may be switching to 
C11 threading in future, I don't know, I dropped C and C++ (for good 
reasons) back in 2005 and haven't followed either so don't know what is 
planned for C11 thread support.


It seems that is there is patchy support for pthreads, this has always 
been in case even bitd when I was using Amiga's daily.


I really don't know whether the OS can even support a full pthreads 
implementation, I've seen people say it cannot.


But there are issues with the toolchain, bebbo's gcc install raises 
false positives in the setup stage, i.e. clib2 installs:


/opt/amiga-gcc/m68k-amigaos/clib2/include/dlfcn.h

with no library backing it up.

AmigaOS 3.x has a libdl on Aminet which works to some degree, I've not 
tested it thoroughly to see what it can and cannot handle.


Latest zlib builds and installs with the command from the older zlib on 
Aminet.


Even expat built, but the benchmark program would refuse to execute 
under AmigaOS with the OS saying it wasn't executable when it was. A 
simple hello world test program ran fine though, so the compiler does work.


Luke.

Re: [Mesa-dev] Trying to build a opencl dev env

[Luke A. Guest]

How do you run the opencl-cts tests on this?

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Trying to build a opencl dev env

[Luke A. Guest]

On 27/04/2021 08:00, Pierre Moreau wrote:

Hello Luke,

If you set `PKG_CONFIG_PATH=$PATH_TO_LIBCLC_INSTALL/share/pkgconfig` when
running meson, it should pick that version instead of the system one.

I run it as `PKG_CONFIG_PATH=[…] meson setup […]`; it might also be possible to
pass it as an argument instead, I do not know.


Thanks for that. It's because I had that var set to 
/lib/pkg-config, libclc installs to /share/pkg-config 
for some unknown reason.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Trying to build a opencl dev env

[Luke A. Guest]

Hi,

So, I've built a generic LLVM tree for mesa and other projects and 
installed it alongside SPIRV-LLVM-Translator into 
$HOME/opt/llvm-dev-reldebug.


I have installed libclc there too, although it wouldn't build as part of 
llvm and make install wouldn't install to the same llvm dir for some reason.


Now onto mesa, I cannot get this thing to build. It fails right at the 
start with the following error:


ninja: Entering directory `../builds/mesa-reldebug/'
ninja: error: '/usr/share/clc/spirv-mesa3d-.spv', needed by 
'src/compiler/nir/spirv-mesa3d-.spv.zstd', missing and no known rule to 
make it


It's looking int he wrong place for the clc files, which are in the 
above llvm dir. How do you specify where they are with this meson thing?


Thanks,
Luke.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] egl: add linux-dmabuf-unstable-v1-protocol.c to "nodist"

[Luke A. Guest]

master currently fails when enabling egl because
drivers/dri2/linux-dmabuf-unstable-v1-protocol.c doesn't exist, should it?

Luke.


On 19/07/17 23:44, Andres Gomez wrote:
> This fixes `make distcheck`
>
>> make[3]: *** No rule to make target 
>> 'drivers/dri2/linux-dmabuf-unstable-v1-protocol.c', needed by 'distdir'.  
>> Stop.
>> make[3]: Entering directory '/home/local/mesa/src/egl'
>> make[3]: Leaving directory '/home/local/mesa/src/egl'
>> make[2]: *** [distdir] Error 1
>> make[1]: *** [distdir] Error 1
>> make: *** [dist] Error 2
> Fixes: 02cc359372 ("egl/wayland: Use linux-dmabuf interface for buffers")
> Cc: Emil Velikov 
> Signed-off-by: Andres Gomez 
> ---
>  src/egl/Makefile.am | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> index 7c1a4929b8..6ee1fb9be8 100644
> --- a/src/egl/Makefile.am
> +++ b/src/egl/Makefile.am
> @@ -44,10 +44,13 @@ noinst_LTLIBRARIES = libEGL_common.la
>  libEGL_common_la_SOURCES = \
>   $(LIBEGL_C_FILES)
>  
> +nodist_libEGL_common_la_SOURCES =
> +
>  libEGL_common_la_LIBADD = \
>   $(EGL_LIB_DEPS)
>  
>  dri2_backend_FILES =
> +nodist_dri2_backend_FILES =
>  dri3_backend_FILES =
>  
>  if HAVE_PLATFORM_X11
> @@ -84,8 +87,8 @@ libEGL_common_la_LIBADD += $(WAYLAND_LIBS)
>  libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
>  libEGL_common_la_LIBADD += 
> $(top_builddir)/src/egl/wayland/wayland-drm/libwayland-drm.la
>  libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
> -dri2_backend_FILES += drivers/dri2/platform_wayland.c\
> - drivers/dri2/linux-dmabuf-unstable-v1-protocol.c
> +dri2_backend_FILES += drivers/dri2/platform_wayland.c
> +nodist_dri2_backend_FILES += drivers/dri2/linux-dmabuf-unstable-v1-protocol.c
>  endif
>  
>  if HAVE_PLATFORM_DRM
> @@ -119,6 +122,9 @@ libEGL_common_la_SOURCES += \
>   $(dri2_backend_FILES) \
>   $(dri3_backend_FILES)
>  
> +nodist_libEGL_common_la_SOURCES += \
> + $(nodist_dri2_backend_FILES)
> +
>  libEGL_common_la_LIBADD += $(top_builddir)/src/loader/libloader.la
>  libEGL_common_la_LIBADD += $(DLOPEN_LIBS) $(LIBDRM_LIBS) $(CLOCK_LIB)
>  

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] radv: Use the KHR dedicated alloc for the WSI.

[Luke A. Guest]

can confirm this fixes the current radv rendering rubbish.

Luke.



On 15/07/17 18:56, Bas Nieuwenhuizen wrote:
> NV isn't valid for external images anymore.
>
> Signed-off-by: Bas Nieuwenhuizen 
> Fixes: 6ddc64b93ea "radv: Add support for VK_KHR_dedicated_allocation."
> ---
>  src/amd/vulkan/radv_wsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
> index cdb04ca9628..ab3dcd67d5f 100644
> --- a/src/amd/vulkan/radv_wsi.c
> +++ b/src/amd/vulkan/radv_wsi.c
> @@ -185,8 +185,8 @@ radv_wsi_image_create(VkDevice device_h,
>  
>   VkDeviceMemory memory_h;
>  
> - const VkDedicatedAllocationMemoryAllocateInfoNV ded_alloc = {
> - .sType = 
> VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV,
> + const VkMemoryDedicatedAllocateInfoKHR ded_alloc = {
> + .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR,
>   .pNext = NULL,
>   .buffer = VK_NULL_HANDLE,
>   .image = image_h

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of Clover (AMDGPU)

[Luke A. Guest]

> I'd suggest that you check out the recently-open-sourced OpenCL
> conformance test suite [0] or my slightly-more-linux-build-friendly
> fork [1] and give it a run on top of mesa/clover. It'll give you a
> good list of things to work on.
Thanks, I took a quick look. Yeah, shame they didn't put in a proper
build system or provide a doc stating what the tests are or a main app
that runs them all in a correct order and outputs a report.

>
> I ran the integer_ops sub-tests last night, and besides the missing CL
> 1.2 popcount() function, that entire sub-suite succeeds. Feel free to
> attempt to implement that built-in function in the libclc[2] library
> to get your feet wet.
>
> There are also issues with buffer copies (using host-pointers,
> copySubRect), and there are a subset of the floating-point math
> built-ins which are either missing or fail some test scenarios. Some
> atomic operations seem to be incorrect, and that's about as far as
> I've managed to get so far in looking at the results. I'm sure plenty
> of other things need work/polish. Note that many of these things are
> gpu-independent and can be implemented either in the clover
> state-tracker, or in the generic (non-GPU-specific) portion of libclc.
>
> I've been looking into implementing the
> clCreateCommandQueueWithProperties API function as well, since there
> seem to be a bunch of CL programs that just blindly assume the API
> function exists for all platforms when using the ocl-icd loader, and
> segfault as a result.
>
> One big missing piece is image support. It's an optional feature of
> OpenCL, but there are a good number of programs used by a certain
> benchmarking site that depend on it.
>
Phoronix?

Yeah, it's on the todo list to see if I can get anywhere with it. My
immediate aim is to get Blender cycles with opensubdiv working, so
that's gonna need a lot of work with images.

Thanks,
Luke.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of Clover (AMDGPU)

[Luke A. Guest]

> Nobody has worked on RadeonSI OpenCL for quite some time. Even the
> main developer of R600 and RadeonSI OpenCL (Tom Stellard) was mostly
> working on ROCm when he was at AMD.
>
>> So far I've found that gl sharing is missing as are some entry points in
>> dispatch.cpp.
> ROCm OpenCL has interop support with RadeonSI OpenGL. We committed it
> into Mesa when ROCm OpenCL was still closed source. I think it can
> also be used to pass VDPAU surfaces through OpenGL into OpenCL that
> way. It's pretty flexible.
I'm not sure my machine can handle ROCm due to the PCIe intrisics.
>
>> 1) Would it be worth continuting and if so would we be allowed to shared
>> clc files from ROCm to Mesa?
>>
>> 2) If not, is it worth considering porting Beignet instead, that at
>> least gives OpenCL 2.0.
> Clover and its driver backends are unmaintained and there is no
> production quality Mesa OpenCL driver. If you are interested in
> working on it, feel free, but if you upgrade to a ROCm-capable
> machine, you might lose interest.
>
I'm not going to upgrading for another year, I want to wait it out.

Who are the best people to ask for help?

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of Clover (AMDGPU)

[Luke A. Guest]

Forgot to mention I would be testing on R9 390 and R9 380 cards.

Thanks,
Luke.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Status of Clover (AMDGPU)

[Luke A. Guest]

Hi,

I've just reinstalled Gentoo on my machine and I no longer have
AMDGPU-Pro on it due to it using ancient libs. My machine is an FX-8350
one, so it's PCIe-2.0. Clover is currently lacking in CL compliance at
this time.

So, I'm wondering if anyone is actually working on it now that AMD have
abandoned it in favour of ROCm? Does anyone know the actual status, i.e.
what is and isn't done? I think it's worth getting OpenCL support
working for older hw, ROCm has a PCIe-3.0 intrinsics requirement, so for
older hardware this isn't an option. 

So far I've found that gl sharing is missing as are some entry points in
dispatch.cpp.

1) Would it be worth continuting and if so would we be allowed to shared
clc files from ROCm to Mesa?

2) If not, is it worth considering porting Beignet instead, that at
least gives OpenCL 2.0.

Thoughts?

Thanks,

Luke A. Guest.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] precursor patches to trying to merge radv

[Luke A. Guest]

On 05/09/16 23:49, Marek Olšák wrote:
> On Mon, Sep 5, 2016 at 11:32 PM, Luke A. Guest <lagu...@archeia.com> wrote:
>>
>> On 05/09/16 18:41, Marek Olšák wrote:
>>> On Mon, Sep 5, 2016 at 3:03 AM, Dave Airlie <airl...@gmail.com> wrote:
>>>> So currently out-of-tree radv, reuses addrlib (by copying the all
>>>> the files), and at least wants to share the register and family
>>>> header files.
>>>>
>>>> This is a set of patches to just move those into a shared directory,
>>>> in advance of proposing that radv goes into mainline at all.
>>> While I'm not against merging radv, I'd like our (closed) Vulkan
>>> driver to be considered the main and default driver after we open
>>> source it.
>>>
>> When's that likely to be though?
> I wish I knew that too.
>
Ok, but if the radv driver ends up getting there first, you cannot
expect the developers to just wipe it when AMD finally bother to open
their driver just so it can be considered the default? Seems strange.

Luke.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] precursor patches to trying to merge radv

[Luke A. Guest]

On 05/09/16 18:41, Marek Olšák wrote:
> On Mon, Sep 5, 2016 at 3:03 AM, Dave Airlie  wrote:
>> So currently out-of-tree radv, reuses addrlib (by copying the all
>> the files), and at least wants to share the register and family
>> header files.
>>
>> This is a set of patches to just move those into a shared directory,
>> in advance of proposing that radv goes into mainline at all.
> While I'm not against merging radv, I'd like our (closed) Vulkan
> driver to be considered the main and default driver after we open
> source it.
>
When's that likely to be though?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev