How to learn the identity of the graphics card?

[Chien Yang]

I see. You just want to be able to detect the GPU on a system to 
determine which rendering techniques to use your application.
Take a look at D3DPipeline.findDefaultResourceFactory() and 
ES2Pipeline.findDefaultResourceFactory(). You should be able make the 
needed change to pass the GPU information (in printDriverInformation())  
back to your application. You can follow the pattern of is3DSupported() 
in the class.

If you like you might want to file a JIRA for this enhancement request 
so that you don't have to make similar patch for future JavaFX releases.

- Chien


On 8/6/2014 12:32 PM, Mike Hearn wrote:
> I want to use it for rendering :) I just want to fall back to e.g. a 
> color adjust instead of a GaussianBlur.
>
>
> On Wed, Aug 6, 2014 at 8:17 PM, Chien Yang <chien.yang at oracle.com 
> <mailto:chien.yang at oracle.com>> wrote:
>
>     Yes, we know that it is a perfectly fine entry level GPU capable
>     of supporting JavaFX graphics requirements. I shouldn't use the
>     word "bad" card. What I'm saying is that you will have to add it
>     to your blacklist if you don't want JavaFX to use it for rendering
>     due to poor framerate.
>
>     - Chien
>
>
>     On 8/6/2014 9:57 AM, Mike Hearn wrote:
>>     The card isn't bad per se, it's just the HD4000 integrated
>>     graphics chip that older MacBook's ship with. It's just that I'm
>>     very picky about my framerates :)
>>
>>
>>     On Wed, Aug 6, 2014 at 6:49 PM, Chien Yang <chien.yang at oracle.com
>>     <mailto:chien.yang at oracle.com>> wrote:
>>
>>         There isn't a public Java API support for what you want to
>>         do. However if you are willing to patch JavaFX in your own
>>         build, you can add the bad card to the GLGPUInfo blackList[]
>>         in the GLFactory class of the specific platform if you are
>>         using the es2 pipe. You will need to dig down into the native
>>         C++ code if you need to support Windows d3d pipe. This will
>>         be a little more work see D3DBadHardware.h for the entries.
>>         Hope this helps.
>>
>>         - Chien
>>
>>
>>         On 8/5/2014 11:39 PM, Peter Penzov wrote:
>>
>>             Hi All,
>>                 I'm interested how I can get the model of the GPU
>>             card using Java. Can
>>             you show me some basic example?
>>
>>             BR,
>>             Peter
>>
>>
>>             On Wed, Aug 6, 2014 at 3:02 AM, Jim Graham
>>             <james.graham at oracle.com
>>             <mailto:james.graham at oracle.com>> wrote:
>>
>>                 If there is a card that can't keep up with what we
>>                 want it to do then we
>>                 should probably be dealing with that on our end as
>>                 well, whether by
>>                 disabling 3D on that card or by black listing it and
>>                 just falling back to
>>                 sw pipeline.  We already do that with a number of
>>                 embedded GPUs...
>>
>>                                          ...jim
>>
>>                 On 8/1/14 2:27 AM, Mike Hearn wrote:
>>
>>                         Scott is correct about the determining of the
>>                         SW pipeline. To add to
>>                         that,
>>                         if knowing whether you are running on SW is
>>                         sufficient
>>
>>
>>                     Unfortunately for the Intel HD4000 card that some
>>                     older laptops have, it
>>                     technically supports 3D but struggles to do basic
>>                     shader effects at 60fps
>>                     when running at high pixel densities. I think I
>>                     posted about this problem
>>                     before. Simpler animations work better (just) but
>>                     I'd prefer to only fall
>>                     back to that when necessary.
>>
>>
>>                       I think the suggestion about starting out
>>                     assuming that animation will be
>>
>>                         OK and then backing off is a good one, if it
>>                         is practical for your
>>                         application.
>>
>>
>>                     Given that I'll be bundling a JVM with the app
>>                     anyway I think it'd be
>>                     easier and give a better UX to just patch JavaFX
>>                     to expose this data using
>>                     an API specific to my app. It obviously has it
>>                     because when running with
>>                     Prism debug logging the info is printed.
>>
>>
>>
>>
>
>