Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#13610 closed bug (fixed)

GLTeapot requires mesa-swpipe

Reported by: vidrep Owned by: kallisti5
Priority: normal Milestone: Unscheduled
Component: Kits/OpenGL Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86-64

Description

hrev51289 x86_64 Fresh install of hrev51288 with pkgman update to hrev51289 GLTeapot opens with error message "No OpenGL renderer available!" Note that one CPU core is pegged while the demo is active See attached GLTeapot.png

Installing mesa_swpipe from HaikuDepot fixes the issue This package should be included in the nightly-anyboot.iso

Attachments (1)

GLTeapot.png (68.8 KB ) - added by vidrep 2 years ago.

Download all attachments as: .zip

Change History (9)

by vidrep, 2 years ago

Attachment: GLTeapot.png added

comment:1 by vidrep, 2 years ago

Has a Patch: set

comment:2 by pulkomandy, 2 years ago

Has a Patch: unset

comment:3 by pulkomandy, 2 years ago

Has a Patch: unset

mesa core should depend on this package, as now there is a single renderer. Possibly we could even stop packaging it separately from mesa.

comment:4 by vidrep, 2 years ago

Has a Patch: unset

I believe this ticket was addressed with the following commit:

https://cgit.haiku-os.org/haiku/tag/?h=hrev51339

comment:5 by pulkomandy, 2 years ago

Resolution: fixed
Status: newclosed

As far as Haiku is concerned, yes. Would be nice if the mesa package had proper dependencies, however.

comment:6 by kallisti5, 2 years ago

The mesa package does have proper dependencies. You don't *have* to install a software renderer. (although one should be provided in the default image)

comment:7 by pulkomandy, 2 years ago

It's useless without one, and now there is only a single one available, so I don't really see the point.

It should at least meta-depend on "needs a renderer, any one will do" or something?

comment:8 by kallisti5, 2 years ago

Requiring any renderer isn't a bad idea. As part of development however it was handy to have "no" renderers installed, then throwing your compiled renderer add-on under test in ~/config/non-packaged/add-ons/opengl/. Sometimes you can run into weird issues with the one you place in non-packaged silently not getting loaded and the OpenGL kit falling back on the packaged on... however I think I only saw that when I was first doing "weird stuff" generating the add-ons directly from Mesa vs our fork.

Note: See TracTickets for help on using tickets.