Bug 24453 - [G33] Most scalers (GLSL) in openmsx fail or produce broken results
Summary: [G33] Most scalers (GLSL) in openmsx fail or produce broken results
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Eric Anholt
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-10 15:21 UTC by Sean Young
Modified: 2019-09-18 19:32 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Output of glxinfo on G33 (16.27 KB, text/plain)
2009-10-11 14:02 UTC, Sean Young
Details

Description Sean Young 2009-10-10 15:21:49 UTC
Ubuntu 9.10 Beta (x86-64) with xorg-edgers apt source
DG33TL motherboard

Steps to reproduce:
1) Install openmsx (0.7.0 will do, early will most likely fail too
2) Run and press F10 to open console
3) First command:
set renderer SDLGL-PP

Now there are various scalers (using GLSL) which can be selected using

set scale_algorithm name

name is one of: RGBtriplet SaI ScaleNx TV hq hqlite simple

RGBtriplet
work correctly

SaI
Incorrect results

ScaleNx 
i915_program_error: Unsupported opcode: IF

TV
i915_program_error: Exceeded max instructions

hq
incorrect results

hqlite
incorrect results

simple
works correctly (no shader)

The correct results should be visible by selecting non-GL renderer:

set renderer SDL
Comment 1 Eric Anholt 2009-10-10 21:10:06 UTC
did you enable the GLSL fragment shader option in driconf or something?
Comment 2 Sean Young 2009-10-11 05:01:16 UTC
(In reply to comment #1)
> did you enable the GLSL fragment shader option in driconf or something?
> 

There is no $HOME/.drirc or /etc/drirc. It made no difference when I did enable GLSL fragment shader in driconf, or any other of the options I tried for that matter.
Comment 3 Eric Anholt 2009-10-11 12:00:53 UTC
There's some pretty bogus-looking shader handling in openmsx.  Can't quite figure out how you'd make it to fragment shader compile, though.

What does glxinfo say about your GL version?
Comment 4 Sean Young 2009-10-11 14:01:55 UTC
(In reply to comment #3)
> There's some pretty bogus-looking shader handling in openmsx.  Can't quite
> figure out how you'd make it to fragment shader compile, though.
> 
> What does glxinfo say about your GL version?
> 

This shader handling in openmsx does work with ATI and NVidia hardware. In what way is the shader handling bogus in openmsx?

What do you mean by "Can't quite figure out how you'd make it to fragment shader compile, though."? Do you mean how to make openmsx use it's shaders? 

1) Start openmsx (type openmsx with no arguments in a terminal)
2) Press F10 key
3) type the following two lines in the openmsx console which appears:
set renderer SDLGL-PP
set scale_algorithm hq

Replace hq with any of the options above.
Comment 5 Sean Young 2009-10-11 14:02:35 UTC
Created attachment 30274 [details]
Output of glxinfo on G33
Comment 6 Eric Anholt 2009-10-23 15:07:48 UTC
No, I mean how openmsx would have managed to feed the driver a GLSL fragment shader and have GL compile the shader and hand it to the driver, when the extension isn't reported as being supported.
Comment 7 Elizabeth 2017-10-26 22:57:29 UTC
Hello Erick, Sean. This case is quite old, is this still valid with latest software?? Thank you.
Comment 8 GitLab Migration User 2019-09-18 19:32:42 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/676.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.