Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #32416 > unrolled thread

question: in order to use java on/in a graphics card

Back to article view | Back to comp.lang.java.programmer

Contents

  question: in order to use java on/in a graphics card gdotone@gmail.com - 2015-08-23 08:18 -0700
    Re: question: in order to use java on/in a graphics card Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-08-23 13:43 -0400
      Re: question: in order to use java on/in a graphics card gdotone@gmail.com - 2015-08-23 10:58 -0700
        Re: question: in order to use java on/in a graphics card Thomas Richter <thor@math.tu-berlin.de> - 2015-08-23 20:05 +0200
          Re: question: in order to use java on/in a graphics card "g.g." <gdotone@gmail.com> - 2015-08-23 11:19 -0700
            Re: question: in order to use java on/in a graphics card Thomas Richter <thor@math.tu-berlin.de> - 2015-08-24 09:15 +0200
              Re: question: in order to use java on/in a graphics card Haddock <ffm2002@web.de> - 2015-08-25 02:30 -0700
                Re: question: in order to use java on/in a graphics card gdotone@gmail.com - 2015-08-25 13:02 -0700
                  Re: question: in order to use java on/in a graphics card gdotone@gmail.com - 2015-08-25 13:03 -0700
        Re: question: in order to use java on/in a graphics card Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-08-23 16:03 -0400
    Re: question: in order to use java on/in a graphics card Eternal Hope <laughingspam99@gmail.com> - 2015-08-23 21:26 +0100
      Re: question: in order to use java on/in a graphics card Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-23 21:38 +0000

#32416 — question: in order to use java on/in a graphics card

question: in order to use java on/in a graphics card, where java is directly producing the action of the card, the card must have a JVM to produce byte code the the graphics processor can deal with?  

[toc] | [next] | [standalone]

#32417

On 8/23/2015 11:18 AM, gdotone@gmail.com wrote:
> question: in order to use java on/in a graphics card, where java is directly producing the action of the card, the card must have a JVM to produce byte code the the graphics processor can deal with?

     What do you mean by "use java on/in," and by "directly producing
the action?"

     Java applications can draw graphics via a number of libraries
and layers: AWT, Swing, SWT, JavaFX, and perhaps more ... but I
suspect that's not what you're asking about.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32418

On Sunday, August 23, 2015 at 1:43:50 PM UTC-4, Eric Sosman wrote:
> On 8/23/2015 11:18 AM, gdotone@gmail.com wrote:
> > question: in order to use java on/in a graphics card, where java is directly producing the action of the card, the card must have a JVM to produce byte code the the graphics processor can deal with?
> 

> 
>      Java applications can draw graphics via a number of libraries
> and layers: AWT, Swing, SWT, JavaFX, and perhaps more ... but I
> suspect that's not what you're asking about.

you are right, that's not what i'm asking. amd and nvidia produce drivers for their cards. those drivers appear to be written in c, to get close to the hardware. they may even use an assembly language for part of the code to control them.

in order to create drivers for those cards using java, would a jvm need to be created for the processors and cards.

the idea here is to eliminate the use of c.

[toc] | [prev] | [next] | [standalone]

#32419

Am 23.08.2015 um 19:58 schrieb gdotone@gmail.com:

> the idea here is to eliminate the use of c.

An why exactly do you want to do that? If you want to program the 
graphics card, you do not "push bytes onto the hardware". That is the 
job of the graphics card driver and the hardware, and it is written in 
whatever the vendor choose to write it in. If you want to program 3D 
effects, I would suggest to look into a java to openGL abstraction 
library, probably jogl.

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#32420

On Sunday, August 23, 2015 at 2:05:52 PM UTC-4, Thomas Richter wrote:

 
> > the idea here is to eliminate the use of c.
> 
> An why exactly do you want to do that? 

i don't understand your question.

[toc] | [prev] | [next] | [standalone]

#32426

On 23.08.2015 20:19, g.g. wrote:
> On Sunday, August 23, 2015 at 2:05:52 PM UTC-4, Thomas Richter wrote:
> 
>  
>>> the idea here is to eliminate the use of c.
>>
>> An why exactly do you want to do that? 
> 
> i don't understand your question.

Quite simple: "What is the problem you want to solve?". Quite frankly,
Java is not the right language for low-level hardware interfaces, but if
you want to program GPUs, there are probably interfaces available that
allow you to bridge to java.

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#32427

Am Montag, 24. August 2015 09:15:33 UTC+2 schrieb Thomas Richter:
> Java is not the right language for low-level hardware interfaces, but if
> you want to program GPUs, there are probably interfaces available that

JDK9/JDK10 are intended to have support for accessing GPUs, see http://openjdk.java.net/projects/sumatra/

[toc] | [prev] | [next] | [standalone]

#32429

On Tuesday, August 25, 2015 at 5:30:16 AM UTC-4, Haddock wrote:
> Am Montag, 24. August 2015 09:15:33 UTC+2 schrieb Thomas Richter:
> > Java is not the right language for low-level hardware interfaces, but if
> > you want to program GPUs, there are probably interfaces available that
> 
> JDK9/JDK10 are intended to have support for accessing GPUs, see http://openjdk.java.net/projects/sumatra/

thanks Montag, this may be great.

[toc] | [prev] | [next] | [standalone]

#32430

On Tuesday, August 25, 2015 at 4:02:32 PM UTC-4, gdo...@gmail.com wrote:
> On Tuesday, August 25, 2015 at 5:30:16 AM UTC-4, Haddock wrote:
> > Am Montag, 24. August 2015 09:15:33 UTC+2 schrieb Thomas Richter:
> > > Java is not the right language for low-level hardware interfaces, but if
> > > you want to program GPUs, there are probably interfaces available that
> > 
> > JDK9/JDK10 are intended to have support for accessing GPUs, see http://openjdk.java.net/projects/sumatra/
> 
> thanks Montag, this may be great.

I mean thanks Haddock... 

sorry.

[toc] | [prev] | [next] | [standalone]

#32421

On 8/23/2015 1:58 PM, gdotone@gmail.com wrote:
> On Sunday, August 23, 2015 at 1:43:50 PM UTC-4, Eric Sosman wrote:
>> On 8/23/2015 11:18 AM, gdotone@gmail.com wrote:
>>> question: in order to use java on/in a graphics card, where java is directly producing the action of the card, the card must have a JVM to produce byte code the the graphics processor can deal with?
>>
>
>>
>>       Java applications can draw graphics via a number of libraries
>> and layers: AWT, Swing, SWT, JavaFX, and perhaps more ... but I
>> suspect that's not what you're asking about.
>
> you are right, that's not what i'm asking. amd and nvidia produce drivers for their cards. those drivers appear to be written in c, to get close to the hardware. they may even use an assembly language for part of the code to control them.

     Although I have no specific knowledge of the particular cards that
interest you, your outline seems plausible.  The card will most likely
have some on-board firmware, a hookup with the host's I/O mechanisms,
and probably some kind of sub rosa hookup to the (or "a") memory bus.
The driver for a specific card+host+O/S combination will take care of
mediating between an application-level graphics framework and the low-
level on-card and near-card operations, and of keeping the O/S informed
about what's going on.

> in order to create drivers for those cards using java, would a jvm need to be created for the processors and cards.

     Probably not.  A driver written in Java would presumably run on the
host processor, not on the graphics card.  It would still have the job
of translating "shade this polygon with that texture" into whatever the
card understands, and the possibly more intricate job of passing data
back and forth between the card and the O/S' structures.  Interrupts,
if the card uses them, could be REALLY tricky to handle in Java, where
the garbage collector might launch at any moment.

     By the way, the details of driver/card interaction are not always
readily available: The makers of the cards often regard such matters
as proprietary, and will not document them for you.  That means you
may well need to reverse-engineer the vendor's driver just to find out
what a substitute driver must do.  Even if you figure out what the
vendor's driver is doing, there may still be requirements you're not
aware of: For example, it might be necessary to respond to such-and-
such an event within so-and-so many nanoseconds, and the fact that
the vendor's driver just happens to do so won't reveal the need.
Finally, reverse-engineering somebody's proprietary driver is the
sort of thing that a typical EULA frowns on, and that a sufficiently
vindictive card maker might take exception to.

     ... but, hey, no worries: Intel and AMD never sue anyone, right?

> the idea here is to eliminate the use of c.

     The driver will surely need to do some low-level things unaided
Java cannot, like "tickle the I/O register at such-and-such address"
or "arrange to be the recipient of thus-and-such interrupt" or "lock
Semaphore So-And-So while fiddling with an O/S-internal queue."
Since unaided Java can't do it, you'll need to write a considerable
amount of JNI code -- and what do you plan to write it in, eh?  COBOL?

     Then there's the JVM itself, which is a very large pile of C++
(with assorted admixtures).  C++ is not C, but still ...  And what
do you suppose the O/S itself is written in?  And the on-card firmware?

     What benefit do you expect to derive from eliminating C, if it's
even possible at all?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32423

On 23/08/2015 16:18, gdotone@gmail.com wrote:
> question: in order to use java on/in a graphics card, where java is directly producing the action of the card, the card must have a JVM to produce byte code the the graphics processor can deal with?
>

Interesting question

Imagine a grossly oversimplified computer with 3 layer architecture, 
there is software at each layer. We also ignore VM optimisations like 
JIT compilation etc.

Top layer is the application layer, this is where the programs you use 
day to day exist.

Middle layer is the driver layer, a driver is the (bi directional)
software interface between the application layer and the hardware 
device. (we are ignoring the operating system but who needs one of those 
anyway :-))

The hardware layer contains software that drives the device, usually 
stored in some kind of ROM, sometimes a PLA sometimes flashable etc

Java is an interpreted language, bytecode is directly executed by a 
virtual machine, when a VM sees a bytecode instruction, it 'looks up' 
the relevant machine instruction for the underlying platform it is 
currrently running on and this is what gets executed by the hardware. 
Java bytecode is not directly executed by the hardware on the hardware 
device

So, presumably you want to write the ROM resident code in Java. I can't 
see how this would work as sooner or later something is going to have to 
translate the bytecode into directly executable code and this something 
would have to produce the 'binary' bytes that is directly executable by 
the hardware. Java doesn't do this so you would 'probably' use C or 
assembler to produce the 1s and 0s (if you like) that will cause the 
device to actually do it's thing.

So, no, I don't think it's possible to expunge all traces of C and/or 
assembler, or rather the executable output thereof from the device.

As always, I await correction and chastisement


-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]

#32424

On Sun, 23 Aug 2015 21:26:59 +0100, Eternal Hope wrote:

> 
> As always, I await correction and chastisement
>
I seem to remember one or two chips that claimed to run Java directly.

One of them was the Parallax Javelin. I never used it or saw one or its 
manual.  Outside of its manuals  but there seems to be next to no 
information about how its JVM was implemented (silicon or firmware?), 
what version of Java it was equivalent to, or what subsection of the 
standard class library it supported apart from the fact that it had no 
network support.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web