@gvx64 said in Citra-Nightly-2104 on Pi5 (screen issue) - Nintendo 3DS:

I actually built your version of Citra and ran Etrian Odyssey Untold The Millennium Girl and using an existing save file. Using Vulkan, it handled the menu system really well but the screen went black as soon as I entered a dungeon (where there is rendering of 3d polys). Please let me know if you have a different experience here.

Yes but I didn't play with the API setups. We don't have this problem with Vulkan on Microsoft Windows. I always compare the game performance on both systems and I agree with you, the development of this emulator on Linux/Mesa (Pi5) with Vulkan is not at the same level than the one on Microsoft Windows.

I'm looking forward to seeing if someone with the skills will take this on with the Borked3DS project. It's one of the only new projects alive that continues where Citra left off.

Thanks again for your comments!

OK so this worked:

I added the following to runcommand-onlaunch.sh

rm /opt/retropie/configs/ps2/Config/cache/vulkan_pipelines.bin && rm /opt/retropie/configs/ps2/Config/cache/vulkan_shaders.bin && rm /opt/retropie/configs/ps2/Config/cache/vulkan_shaders.idx

It did not appear to like them on separate lines. Now when a game launches, it deletes those three files, and if I'm loading a PS2 game with AetherSX2 it re-creates them once the game loads, but then deletes them before the next game.

So this way those files never get bloated and not hog down any other games.

Anyone have any suggestions on how I can get the Vulkan drivers back on the latest update of Retroarch?

@TPR I think that's this option:-

[Video_Hacks] DisableCopyToVRAM = False

you'll need to check the options they have documented on retroarch's wiki:-

https://docs.libretro.com/library/dolphin/

Although they're not named the same as regular dolphin so you might need to trial and error a bit

@sugarfree said in Using Vulkan with RetroPie:

@TPR

It's not merged yet, but I'm sure it will be when the time comes. See: https://github.com/RetroPie/RetroPie-Setup/pull/3785.

To answer your previous question: yes, the Vulkan driver provides noticeble better performance with the Flycast, Dolphin, and PPSSPP emulators. The extent of the improvement depends on the game.

OK thanks. Those are the emulators I've been using it on.

@retropieuser555 said in MKDD Tint Issue RPI5:

@gvx64 said in MKDD Tint Issue RPI5:

Instructions for Building from Source

cd /home/pi sudo mkdir ./dolphin-rpi/ sudo git clone https://github.com/gvx64/dolphin-rpi cd ./dolphin-rpi sudo git submodule update --init --recursive

I wouldn't use sudo to make the dolphin-rpi directory, you can just git clone straight away. Otherwise it'll mess up all the permissions. Or later in your code the user probably won't be allowed to make the build directory

cd ~ git clone https://github.com/gvx64/dolphin-rpi cd ./dolphin-rpi git submodule update --init --recursive

Thanks, I agree with this. I will modify Post 42 to remove the unnecessary directory creation from the instruction set when I have some time.

@giandeejay said in is it possibile to install vulkan on retropie ?:

But where in the code ? What line?

! isPlatform "x11" && params+=(--disable-vulkan --disable-wayland)

hello, good morning, I have no personal interest, I had read about it improving graphic performance, but I don't feel urgently, when the version with debian 11 is ready, I'll try it with pleasure, thanks to both of you for your answers

@gandalth23 said in Wii emulation performance using Vulkan on Pi4:

I confirm the behavior for Mario Kart Double Dash.

In your other thread you seem to have found a solution for Mario Kart Double Dash. What exactly is the fix? Using that fork of dolphin or the Gecko codes you provided?

Best,
gandalth

The solution to get rid of the blue fog screen is to install the Ishiiruka version of dolphin....

Very exciting! Does this mean anything for retropie?

retroarch supports it as a graphics driver but it's used for simple blitting to the screen, so no perceivable advantage in 2d emulators. another side effect is that the usual GLSL shaders we use will not work with vulkan - you have to use SLANG ones.

3d cores and standalone emulators may have vulkan implementations, which would take advantage of the new speed/features. lr-parallel would be a fun experiment (though i expect not viable at all). duckstation, beetle-psx, flycast, ppsspp, and dolphin are potentially viable ones that i can think of.

another issue is, does the vulkan driver still need X? that's not ideal.

There's been recent work to include Vulkan support in Mesa for Pi. Here are some hopefully helpful links:

https://www.raspberrypi.org/blog/vulkan-update-merged-to-mesa/ https://blogs.igalia.com/apinheiro/2020/06/v3dv-quick-guide-to-build-and-run-some-demos/ https://www.raspberrypi.org/forums/viewtopic.php?t=277125

Most of the links go over similar steps for compiling, installing, and testing Vulkan and its demos. Some additional notes:

The older posts point to a developer's fork of Mesa. Now that Vulkan has been merged into Mesa, whereever you see a git clone you'll want to make sure that you're pointing to Mesa's repository (https://gitlab.freedesktop.org/mesa/mesa/) You'll be able to get Vulkan from the master branch of of the Mesa repository. It doesn't look like it's been tagged to a release yet, so there's likely more work to be done and your mileage may vary. You can actually have different versions of Mesa installed on your system simultaneously, as long as you put them in different directories. In order to ensure stability of my Pi systems, I do this, so I can test and play around while not worrying about everything else. Though Mesa is pretty self contained so it's not too hard to get things back to normal if you overwrite the original drivers. If you have compiled Mesa for installation in another directory, then you'll need to add the following line to your launch scripts or your bash profile in order to point programs to your special installation. You do that with the following line: export VK_ICD_FILENAMES=[YOUR INSTALLATION PATH]/share/vulkan/icd.d/broadcom_icd.armv7l.json I've found that Raspbian/Raspberry Pi OS (which is what RetroPie is built on) actually uses NVIDIA's Vendor Neutral Dispatch version of Mesa (which uses code from Mesa), and not Mesa's version of Mesa. I have no idea if that will be changing or not, but it at least indicates that there will be more work to do before we see Vulkan drivers as part of Raspbian/Raspberry Pi OS/RetroPie as a default.

I've been playing around with Vulkan and so far it's looking pretty good. I have high hopes that as programs begin to adopt Vulkan we'll be seeing some really awesome performance increases. I have not tried Dolphin though. The only thing I've found regarding Dolphin and Vulkan was someone testing it out on a Jetson Nano, which is a different hardware platform. He did compare Vulkan vs. OpenGL and found that Zelda: Wind Walker ran very well with Vulkan where it was choppy on OpenGL. The post is on Facebook (https://www.facebook.com/groups/retropieofficial/permalink/1387063751494192/).

I created a scriptmodule for my own purposes to automate building / installation of Mesa with Vulkan. I may create a separate post for that.

I hope this info helps out.

- George

@coldspark29 said in How to install the Vulkan driver for Retroarch?:

Can you tell me how I would need to modify the install script?

Which install script ? If you're referring to RetroArch, then try adding --enable-vulkan instead of --disable-vulkan in the build script to see if it works.

Updating this thread for informational purposes:

If you want to run the latest MESA git, there are several patches that are needed based on the 20.3.5 diff file from the RPiOS repository: (I kept the relevant changes that are not already upstreamed)

Without it, I ran into some display issues which I presume are the modifiers utilized in the newer libdrm pkgs.

Note: you must compile libdrm, libglvnd, and mesa for it to work.

diff --git a/src/gallium/drivers/v3d/driinfo_v3d.h b/src/gallium/drivers/v3d/driinfo_v3d.h index 147ad0b49bd..a524a03e7e5 100644 --- a/src/gallium/drivers/v3d/driinfo_v3d.h +++ b/src/gallium/drivers/v3d/driinfo_v3d.h @@ -2,4 +2,6 @@ DRI_CONF_SECTION_MISCELLANEOUS DRI_CONF_V3D_NONMSAA_TEXTURE_SIZE_LIMIT(false) + DRI_CONF_V3D_MAINTAIN_IGNORABLE_SCANOUT(false) + DRI_CONF_V3D_IGNORE_SCANOUT_USAGES_WITH_MODIFIERS(false) DRI_CONF_SECTION_END diff --git a/src/gallium/drivers/v3d/meson.build b/src/gallium/drivers/v3d/meson.build index b760ca5c025..1a537637b03 100644 --- a/src/gallium/drivers/v3d/meson.build +++ b/src/gallium/drivers/v3d/meson.build @@ -59,6 +59,16 @@ endif v3d_versions = ['33', '41'] +v3d_deps = [dep_v3dv3, dep_libdrm, dep_valgrind, idep_nir_headers] + +if with_platform_x11 + v3d_deps += dep_xcb +endif + +if with_platform_wayland + v3d_deps += dep_wayland_client +endif + per_version_libs = [] foreach ver : v3d_versions per_version_libs += static_library( @@ -70,7 +80,7 @@ foreach ver : v3d_versions ], c_args : [v3d_args, '-DV3D_VERSION=' + ver], gnu_symbol_visibility : 'hidden', - dependencies : [dep_v3dv3, dep_libdrm, dep_valgrind, idep_nir_headers], + dependencies : v3d_deps, ) endforeach @@ -93,7 +103,7 @@ libv3d = static_library( c_args : [v3d_args], cpp_args : [v3d_args], gnu_symbol_visibility : 'hidden', - dependencies : [dep_v3dv3, dep_libdrm, dep_valgrind, idep_nir_headers], + dependencies : v3d_deps, link_with: [per_version_libs], ) diff --git a/src/gallium/drivers/v3d/v3d_resource.c b/src/gallium/drivers/v3d/v3d_resource.c index 0885a2cb80f..36b6ab34d71 100644 --- a/src/gallium/drivers/v3d/v3d_resource.c +++ b/src/gallium/drivers/v3d/v3d_resource.c @@ -436,7 +436,7 @@ v3d_resource_get_handle(struct pipe_screen *pscreen, case WINSYS_HANDLE_TYPE_SHARED: return v3d_bo_flink(bo, &whandle->handle); case WINSYS_HANDLE_TYPE_KMS: - if (screen->ro) { + if (screen->ro && rsc->scanout) { if (renderonly_get_handle(rsc->scanout, whandle)) { whandle->stride = rsc->slices[0].stride; return true; @@ -750,6 +750,30 @@ v3d_resource_setup(struct pipe_screen *pscreen, return rsc; } +static bool +v3d_resource_should_scanout(struct pipe_screen *pscreen, + const struct pipe_resource *tmpl, + const uint64_t *modifiers, + int count) +{ + struct v3d_screen *screen = v3d_screen(pscreen); + + if (tmpl->bind & PIPE_BIND_SCANOUT) { + if (screen->maintain_ignorable_scanout) + return true; + if (screen->has_x_session && screen->ignore_scanout_usages) + return false; + return true; + } + + if (tmpl->bind & PIPE_BIND_SHARED) { + if (screen->ignore_scanout_usages_with_modifiers) + return false; + return true; + } + return false; +} + static struct pipe_resource * v3d_resource_create_with_modifiers(struct pipe_screen *pscreen, const struct pipe_resource *tmpl, @@ -763,6 +787,8 @@ v3d_resource_create_with_modifiers(struct pipe_screen *pscreen, struct pipe_resource *prsc = &rsc->base; /* Use a tiled layout if we can, for better 3D performance. */ bool should_tile = true; + bool should_scanout = v3d_resource_should_scanout(pscreen, tmpl, + modifiers, count); /* VBOs/PBOs are untiled (and 1 height). */ if (tmpl->target == PIPE_BUFFER) @@ -788,8 +814,8 @@ v3d_resource_create_with_modifiers(struct pipe_screen *pscreen, /* If using the old-school SCANOUT flag, we don't know what the screen * might support other than linear. Just force linear. */ - if (tmpl->bind & PIPE_BIND_SCANOUT) - should_tile = false; + if ((tmpl->bind & PIPE_BIND_SCANOUT) && should_scanout) + should_tile = false; /* No user-specified modifier; determine our own. */ if (count == 1 && modifiers[0] == DRM_FORMAT_MOD_INVALID) { @@ -818,8 +844,8 @@ v3d_resource_create_with_modifiers(struct pipe_screen *pscreen, * We always allocate this way for SHARED, because get_handle will * need a resource on the display fd. */ - if (screen->ro && (tmpl->bind & (PIPE_BIND_SCANOUT | - PIPE_BIND_SHARED))) { + + if (screen->ro && should_scanout) { struct winsys_handle handle; struct pipe_resource scanout_tmpl = { .target = prsc->target, @@ -949,7 +975,7 @@ v3d_resource_from_handle(struct pipe_screen *pscreen, } } - if (screen->ro) { + if (screen->ro && !rsc->tiled) { /* Make sure that renderonly has a handle to our buffer in the * display's fd, so that a later renderonly_get_handle() * returns correct handles or GEM names. @@ -995,7 +1021,9 @@ v3d_update_shadow_texture(struct pipe_context *pctx, assert(view->texture != pview->texture); - if (shadow->writes == orig->writes && orig->bo->private) + if (shadow->writes == orig->writes && + orig->base.sync_status == 0 && + (orig->bo->private || orig->base.sync_condition)) return; perf_debug("Updating %dx%d@%d shadow for linear texture\n", @@ -1038,6 +1066,7 @@ v3d_update_shadow_texture(struct pipe_context *pctx, } shadow->writes = orig->writes; + orig->base.sync_status = 0; } static struct pipe_surface * diff --git a/src/gallium/drivers/v3d/v3d_screen.c b/src/gallium/drivers/v3d/v3d_screen.c index 1c72dc4af0d..1ac9e8fc1d9 100644 --- a/src/gallium/drivers/v3d/v3d_screen.c +++ b/src/gallium/drivers/v3d/v3d_screen.c @@ -47,6 +47,42 @@ #include "compiler/v3d_compiler.h" #include "drm-uapi/drm_fourcc.h" +#ifdef HAVE_WAYLAND_PLATFORM +#include <wayland-client.h> +#endif + +#ifdef HAVE_X11_PLATFORM +#include <xcb/xcb.h> +#endif + +static bool +check_x_session() +{ + bool xcb_connection = false; + +#ifdef HAVE_WAYLAND_PLATFORM + struct wl_display *display; + + display = wl_display_connect(NULL); + + if (display) { + wl_display_disconnect(display); + return xcb_connection; + } +#endif + +#ifdef HAVE_X11_PLATFORM + xcb_connection_t *conn; + + conn = xcb_connect(NULL, NULL); + + if (!xcb_connection_has_error(conn)) + xcb_connection = true; + xcb_disconnect(conn); +#endif + return xcb_connection; +} + static const char * v3d_screen_get_name(struct pipe_screen *pscreen) { @@ -828,6 +864,28 @@ v3d_screen_create(int fd, const struct pipe_screen_config *config, screen->has_cache_flush = v3d_has_feature(screen, DRM_V3D_PARAM_SUPPORTS_CACHE_FLUSH); screen->has_perfmon = v3d_has_feature(screen, DRM_V3D_PARAM_SUPPORTS_PERFMON); + + screen->has_x_session = check_x_session(); + + screen->ignore_scanout_usages = getenv("V3D_IGNORE_SCANOUT_USAGES"); + + const char *ignore_scanout_usages_with_modifiers_name = + "v3d_ignore_scanout_usages_with_modifiers"; + screen->ignore_scanout_usages_with_modifiers = + driCheckOption(config->options, + ignore_scanout_usages_with_modifiers_name, + DRI_BOOL) && + driQueryOptionb(config->options, + ignore_scanout_usages_with_modifiers_name); + + const char *maintain_ignorable_scanout_name = + "v3d_maintain_ignorable_scanout"; + screen->maintain_ignorable_scanout = + driCheckOption(config->options, + maintain_ignorable_scanout_name, + DRI_BOOL) && + driQueryOptionb(config->options, + maintain_ignorable_scanout_name); v3d_fence_init(screen); diff --git a/src/gallium/drivers/v3d/v3d_screen.h b/src/gallium/drivers/v3d/v3d_screen.h index 9bf2a065487..afdce3f3c73 100644 --- a/src/gallium/drivers/v3d/v3d_screen.h +++ b/src/gallium/drivers/v3d/v3d_screen.h @@ -82,6 +82,12 @@ struct v3d_screen { bool has_cache_flush; bool has_perfmon; bool nonmsaa_texture_size_limit; + bool ignore_scanout_usages; + bool ignore_scanout_usages_with_modifiers; + bool maintain_ignorable_scanout; + + /* Are we running in an X session? */ + bool has_x_session; struct v3d_simulator_file *sim_file; }; diff --git a/src/gallium/include/pipe/p_state.h b/src/gallium/include/pipe/p_state.h index c96a387bab8..708bb2fad4f 100644 --- a/src/gallium/include/pipe/p_state.h +++ b/src/gallium/include/pipe/p_state.h @@ -572,6 +572,10 @@ struct pipe_resource unsigned usage:8; /**< PIPE_USAGE_x (not a bitmask) */ unsigned bind; /**< bitmask of PIPE_BIND_x */ unsigned flags; /**< bitmask of PIPE_RESOURCE_FLAG_x */ + + /* Hack for avoiding sync on v3d */ + unsigned sync_condition; + unsigned sync_status; /** * For planar images, ie. YUV EGLImage external, etc, pointer to the diff --git a/src/glx/dri_common.h b/src/glx/dri_common.h index 455e8541ed8..1fe78e73b75 100644 --- a/src/glx/dri_common.h +++ b/src/glx/dri_common.h @@ -56,6 +56,10 @@ extern struct glx_config *driConvertConfigs(const __DRIcoreExtension * core, const __DRIconfig ** configs); extern void driDestroyConfigs(const __DRIconfig **configs); + +#ifndef __GLXDRIdrawable +typedef struct __GLXDRIdrawableRec __GLXDRIdrawable; +#endif extern __GLXDRIdrawable * driFetchDrawable(struct glx_context *gc, GLXDrawable glxDrawable); diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 6de28f39112..ece789148d8 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -1021,6 +1021,9 @@ struct gl_texture_object /** GL_ARB_bindless_texture */ struct util_dynarray SamplerHandles; struct util_dynarray ImageHandles; + + /* Hack for avoiding sync on v3d */ + GLboolean SyncCondition; }; diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c index 3a3ea8aae94..eb1cb561012 100644 --- a/src/mesa/main/texparam.c +++ b/src/mesa/main/texparam.c @@ -275,6 +275,13 @@ set_tex_parameteri(struct gl_context *ctx, } switch (pname) { + case GL_SYNC_CONDITION: + if (!!texObj->SyncCondition == !!params[0]) + return GL_FALSE; + texObj->SyncCondition = !!params[0]; + return GL_TRUE; + case GL_SYNC_STATUS: + return GL_TRUE; case GL_TEXTURE_MIN_FILTER: if (!_mesa_target_allows_setting_sampler_parameters(texObj->Target)) goto invalid_dsa; diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c index 599d2099d6f..9fbab50c1d7 100644 --- a/src/mesa/state_tracker/st_cb_texture.c +++ b/src/mesa/state_tracker/st_cb_texture.c @@ -3620,6 +3620,12 @@ st_TexParameter(struct gl_context *ctx, */ st_texture_release_all_sampler_views(st, stObj); break; + case GL_SYNC_CONDITION: + stObj->pt->sync_condition = texObj->SyncCondition; + break; + case GL_SYNC_STATUS: + stObj->pt->sync_status = 1; + break; default: ; /* nothing */ } diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index 7e155d3e690..f0f3cadfb02 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -625,6 +625,7 @@ TODO: document the other workarounds. <application name="mutter" executable="mutter"> <option name="adaptive_sync" value="false" /> <option name="v3d_nonmsaa_texture_size_limit" value="true" /> + <option name="v3d_maintain_ignorable_scanout" value="true" /> </application> <application name="muffin" executable="muffin"> <option name="adaptive_sync" value="false" /> @@ -676,6 +677,7 @@ TODO: document the other workarounds. </application> <application name="Xorg" executable="Xorg"> <option name="v3d_nonmsaa_texture_size_limit" value="true" /> + <option name="v3d_ignore_scanout_usages_with_modifiers" value="true" /> </application> <application name="gfxbench" executable="testfw_app"> diff --git a/src/util/driconf.h b/src/util/driconf.h index 24726e04bd3..9f2ab7581c6 100644 --- a/src/util/driconf.h +++ b/src/util/driconf.h @@ -480,6 +480,14 @@ DRI_CONF_OPT_B(v3d_nonmsaa_texture_size_limit, def, \ "Report the non-MSAA-only texture size limit") +#define DRI_CONF_V3D_IGNORE_SCANOUT_USAGES_WITH_MODIFIERS(def) \ + DRI_CONF_OPT_B(v3d_ignore_scanout_usages_with_modifiers, def, \ + "Ignore SCANOUT usage on resource allocations with modifiers.") + +#define DRI_CONF_V3D_MAINTAIN_IGNORABLE_SCANOUT(def) \ + DRI_CONF_OPT_B(v3d_maintain_ignorable_scanout, def, \ + "Maintain SCANOUT usage on resource allocations when the environment allows ignoring SCANOUT usage.") + /** * \brief virgl specific configuration options */

Pi4's Vulkan driver has been merged into the Mesa repo. https://www.raspberrypi.org/blog/vulkan-update-merged-to-mesa/