[Libre-soc-bugs] [Bug 472] tutorial and dev page needed for mesa driver

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=472

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cole Poirier from comment #5)
> (In reply to Luke Kenneth Casson Leighton from comment #4)

> 
> Luke, that's *incredibly* unhelpful. To be explicit, it feels like you're
> not providing help, simply calling me stupid.

sorry.  it was really late night.  

> The build logs from what exactly? From mesa? I'm trying to configure mesa,
> it configures and installs properly without the option
> `-Dvulkan-drivers=libre-soc`.

whilst i do not know the build process in detail, this is asking to not build
the libresoc vulkan driver.

> Where would these libre-soc vulkan drivers be generated?

an accurate answer to that is: in the build tree, followed by installation in
the directory specified at configure time.

if this is not specified it defaults to /usr/local usually.

remember though what i said, don't install in /usr/local (not on the main
system that is) specify --prefix=/opt/local or ~/libresocmesa


> Doesn't vulkan
> itself need to be installed and configured for this to work?

vulkan is an API. you don't "install a vulkan", you configure mesa to generate
a library that is compatible *with* the vulkan API.

> In that case,
> as I stated above, I need vivek to tell me how he configured this.
> 
> Using the above vulkan-drivers option whether with libre-soc, or with the
> path that I've installed the drm drivers to
> `-Dvulkan-drivers=~/opt/lsoc-mesa` fails with the *exact* same error
> 
> ```../meson.build:21:0: ERROR: Options "~/opt/lsoc_mesa" are not in allowed
> choices: "auto, amd, freedreno, intel, swrast"```

*click*.  i know what it is.  did you use the master branch or the libresocdev
branch?  (not exact name, you need to look it up, git branch -R i think)

find and check out the right branch and libresoc will be in the list.

> Is this task, which is in its earliest stages and has a *year* if not more
> of leeway, *really* a higher priority than those *HDL* tasks which have mere
> weeks to be finished *and* tested? Do we not want to be able to run linux on
> our Oct 31 2020 tapeout chip?

very good point.

-- 
You are receiving this mail because:
You are on the CC list for the bug.