I'm just tested Debugger on Intel HD3000 just right now. If you see cyan background just maximize the window and debugger will work. If you get any other error (e.g if your Mesa old it's mossible), try to run it on LLVMPipe using: Code: LIBGL_ALWAYS_SOFTWARE=1 ./Debugger
That fixes it, thanks! I thought I had tried resizing the window, but clearly hadn't. For me, there was no indication of "ICON ATLAS" and "SPECIAL ICON ATLAS", just a number of identical links to content pages that when I clicked on showed the Webkit inspector for each. Simply clicking on each in turn eventually fixed the cursors. Now that I have a cursor, should there be any visual indication of where metal deposits are on the planetary surface? I'm not seeing any and hence need to go prospecting by waving the metal extractor wand randomly over it. Not sure if that is a bug or if I am being a newb.
Yes currently they're not named, but they was named in alpha. You can use Ctrl+N hotkey to toggle icons for metal spots. But problem that you can't see any features on planet surface as long as I understand it's because GL_EXT_gpu_shader4 not available in Mesa and it's required for shader which used for features. Might be I wrong, but I don't have enough time to find out how exactly it working. When I have a bit more free time I'll try to find out and rewrite shaders if it's possible.
Hmm, glxinfo isn't listing that extension, but Mesa commit logs suggest it should have been supported for a few years now. In any case if Mesa currently doesn't, I'd hope the PA developers won't continue using it since that basically makes the libre drivers unusable. Has the GL_EXT_gpu_shader4 incompatibility been reported in the bug tracker? I couldn't find a ticket for it.
Probably I'm wrong because actual issue a bit different: Code: 0:1(12): error: extension `GL_EXT_gpu_shader4' unsupported in vertex shader There is very much same report: https://bugs.freedesktop.org/show_bug.cgi?id=29185 As I see Ian Romanick explained really well why it's done this way. Probably somebody need to report PA error to Mesa and get some strict answer from developers. Sorry, but I can't agree with you. If games won't use those extensions they'll be never implemented in Mesa. Because Intel developers for example have higher priority for ext's which are used in real applications. Performance is everything and open source drivers it's last thing Uber need to care about, all they need it's keep compatible with GLSL standard. There is other error: Code: [13:05:25.354] ERROR Error linking /shaders/prelight_flat_batch_index.vs+/shaders/prelight_pa_unit.fs [13:05:25.354] ERROR : error: all shaders must use same shading language version And I really don't understand why it's work this way in Mesa because I tried to find such rule in GLSL specification and failed.
Yeah, good point. I was just being lazy - it's easier to update PA than Mesa. So, bugs filed on b.f.o for the above two issues: #70260 and #70261. Both look like Mesa being too strict compared to the spec. If you have any supporting arguments or documentation for either, do add them to the bugs. Thanks for your assistance!
Still now working for me =( I still have that screen on the 1/16 of the window. Resizing or maximizing window doesn't affects it. Any idea what else I can do? It's on xfce, will try other DE now.
Try to update Mesa from PPA: https://launchpad.net/~xorg-edgers/ archive/ppa Might be you met some problem which only was fixed in 9.2
Any other ppa's available? Last time I added xorg-edgers ppa it resulted in constant crashes and drivers stopping to work every week or two because of the constant updates =\
There is oibaf PPA: https://launchpad.net/~oibaf/ archive/graphics-drivers/ But for me it's make me break dependencies multiple times, because it's even more unstable Mesa than in xorg-edgers. Alternative way for this is configuring APT to ignore everything except driver updates from xorg-edgers: http://askubuntu.com/questions/170235/how-do-i-cherry-pick-packages-from-a-ppa
O Ok, I will just install everything from xorg-edgers, test it and then remove it all with ppa-purge.
Thanks you for reporting those, but I'm probably mess up a bit about versions mixing. I'm not tried to check 1.3 spec and only checked 4.0 spec instead and only find this (section 3.3, page 12): Right now I checked GLSL 1.3 spec and found this (section 3.3, page 11): Looks like you can't mix 1.1 shaders with 1.3, but but can do that with later versions. So looks like Mesa is right and PA shaders code a bit wrong. PS: So probably you need to mark #70261 resolved as invalid.
Yep, you were right, it's definitely mesa 9.1 problem. Working almost fine now. I will probably just download mesa from freedesktop and compile it myself now.
Also I'm created issue about GLSL spec violation: FS#2427 PS: Also I'm seen your post on bugtracker about non-completed EXT_gpu_shader4 implementation.
Cool, thanks for digging into the version situation. I updated fdo #70261 suggesting it's the app's problem, but left it open since they might want to consider it for compatibility's sake anyway. It's kind of annoying there's only two shaders using a different version. :/
Oh, now things are getting more interesting. Note that EXT_gpu_shader4 was defined as an extension to GL 2.0, but the only GLSL functions used from the extension (that I have seen) are texelFetch texelFetch2D. Interestingly, these seem to have GLSL 130 equivalents. So if PA switched to GLSL 130 completely, this would not only fix the version mismatch but would also let the dependency on EXT_gpu_shader4 get ditched, and hence fix all (many?) of our Mesa woes in one fell swoop. I'll try doing just that myself later tonight, but if anyone beats me to it, I'll be a happy camper.
I think open drivers are good in way they done now. e.g without anything just for compatibility. Actually it's not working on Intel HD 3000/4000 under Windows too with same error
